If you’re reading this, my hope is that you’re already aware of the standard practice for storing passwords. But if in fact that is not the case, let me direct you to the most excellent resource on the topic:
http://www.codinghorror.com/blog/archives/000953.html
The part that I’m interested in particularly is the salt. It’s easy to understand that without it, your password hash is much less secure. But there seems to be two schools of thought.
One Universal Salt, or Individual Salts?
Before we go declaring one as the best practice, why don’t we take a look at what the benefits are of each solution.
A significant difference between the two methods is the visibility. The draw to the Universal Salt method seems to be that the salt is hidden. It’s not known to anyone, stored in the code and not easy to find. The cracker would need to create a near infinite number of Rainbow tables to be able to discover crack it. Whereas it seems the Individual Salt is lacking that perk, and displays the salt in the same record as the password hash. The cracker has the salt, but still has some work ahead in finding out how the salt was incorporated into the hash.
The other gap in this comparison is the amount of damage that can be inflicted. If the Universal Salt is cracked, the cracker has a free license to crack any password hash in your database. However if each row had it’s own Individual Salt, they would only be able to crack one hash at a time. Greatly limiting the amount of damage they could do to your user base. Of course this wouldn’t prevent them from cracking the administrator account and doing their bidding, but a difficult time impersonating a great number of your users.
So it seems that they each have their strengths and weaknesses. The Universal Salt takes a lot more work up front to crack, but leaves you with a gaping hole of liability if it is cracked; and the Individual Salt is gives you the first piece of the puzzle to crack, but limits damages to just one account.
After tabulating the votes with our judges, it seems that there is one clear winner in this debate…
Use Both
If the cracker sees a table with the “salt” field listed next to the “password” field, how are they to know that you’ve also set another random string of characters in your code that you tack onto the end of the password? The resulting hash can be deemed so complicated as to be nearly impossible to crack. You’ve taken the positives from both methods, and eradicated the negatives. A Combined Salt would need a near infinite number of rainbow tables to crack just record.
With a mix like this, you can be sure to receive a written letter of apology from anyone who tried to crack your hashes.
