Comprehensive information about hash salts

Question

There are a lot of questions about salts and best practices, however most of them simply answer very specific questions about them. I have several questions which feed into

Answer 1

1. If a hacker has access to your database system, you're fsckd. Your system has to have access to both tables to run, so the likelihood of "hiding" one from a hacker who's already compromised the system is nearly zero. Not remotely worth the extra complexity, in my opinion.

2. Having a "nonce" added (in addition) to a salt for each password is not a great help, but doesn't really hurt anything either.

3. Even 16 bits of salt is typically enough to make password cracking infeasible, if done correctly. I would probably use 64 or 128 bits, why not?

4. You should use a "good" source of randomness, but it doesn't need to be perfect. If the random values are somehow visible to an attacker, then they may be able to find a way to predict the next random value, but they would have to do this when the password is created and it would only get them that one password.

In short, you need per-user salt and a good hashing function. MD5 is terrible, and SHA-1 is no longer "good". You should be using a system like bcrypt to force an attacker to spend a considerable fraction of a second on each hash. 0.1s per password check is probably no big deal to you, but it's devastating to any kind of brute-force cracking.

This is required reading for anyone implementing a password security scheme:

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html