Databases and security continuedCMSC 461Michael 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 https://

www.pcisecuritystandards.org/security_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!