Databases and security continued CMSC 461 Michael Wilson

Connecting to databases  There are a few pretty common ways to authenticate credentials on a database  Username/password  Pretty common way  Subject to insecurity (easy to guess user/password combo, social engineering, etc.)  System user  Have to be authenticated and logged in as a system user to even connect

System user security  When installing any server, you can configure it to run as a particular user  A good idea  Restrict the permissions that this user has  Typically done via careful crafting of initialization scripts  Oftentimes supplied with the operating system

DBMS bugs and system user security  Everything has bugs  The worst bugs allow for the execution of arbitrary code (buffer overrun)  By locking down to a specific user, you can mitigate damage to your system  Same thing for databases

Points of entry  System architecture  Topological concerns with database placement  Firewalls, exposed ports  Where should your database go?

Dependent on your application  Your database should almost NEVER be exposed to the internet at large  Classroom development aside  Behind a firewall, only a few select nodes have access to it  All about damage mitigation  Alternative applications

Mitigation  Mitigation of risk is a huge factor here  Having your database exposed to the internet at large is not a good idea  Restricting access to your database topologically helps mitigate risk  Databases typically house large amounts of customer data  Gaining access to this is oftentimes diastrous

Mitigation – data storage  That being said, people gain access to databases  Are the users of your application out of luck?  No, there are a number of precautions that we must take  Many of these options are not only good ideas, but have side effects that are beneficial to us

Password encryption and salting  Passwords should never be stored in plaintext in a database  EVER  They should be hashed and salted  Hashing – a function that is applied to the encryption that generates a hash value  Salt – random data that is concatenated to a string prior to hashing  Stored with the hashed password

Hash functions  Old hash functions ( do not use )  MD5  Still used (file verification)  Broken  SHA-1  Also broken  Newer functions: SHA-2, SHA-3  Have different levels of security  Are still viable for password hashing

Why salt?  Prevents attackers from using rainbow tables to crack user passwords en masse  Rainbow tables – precomputed tables using for reversing hash functions  Salt ensures that the hash function generated by user passwords will be unique  Even if two users have the same password, the hash will be different  Even if the salt is known, it will prevent the use of rainbow tables

A note about databases and passwords  When validating a password in the database, you hash and salt the provided password the same way and compare the stored value versus the input  Side effects:  Unlimited length passwords  Administrator does not have easy access to user passwords  Attackers do not have easy access to user passwords

Another note about passwords in databases  If you are able to click “forgot password” on a site and they can send you your plaintext password  They are storing your password in plaintext  They are insecure, and are just asking for disaster

Storing credit card info  You should be conforming to the PCI DSS security standard  ity_standards/index.php ity_standards/index.php

The gist of this  Even in the event of compromise, it should not be completely disastrous  There are many good methods in place to prevent the easy extraction of information from data stored in databases  Still a good idea to change passwords, reissue credit cards, etc.  But don’t store sensitive data without some level of security!