Password databases and Salts

I responded to a question on Stack Exchange

The purpose of a per record salt is to make the task of reversing the hashes much harder. So if a password database is exposed he effort required to break the passwords is increased. So assuming that the attacker knows exactly how you perform the hash, rather than constructing a single rainbow table for the entire database they need to do this for every entry in the database.

There is a separate issue with a database wide salt. This is a sort of key, and protects against the attacker using existing rainbow tables to crack the passwords. The database wide salt should be stored separately so that if the database is compromised then it is unlikely that the attacker will get this value as well.

The last area where many fail, is that there must be a way to change these salt values. If a security incident occurs we want to be able to change the salt values easily. So the database should have a salt version and the code will use the version to identify which salts to use and in what combination. When this is changed then a background task can update the database without taking the system off-line.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: