views:

403

answers:

2

Like most programmers, I am not an expert on cryptography but I understand the basics. However, a little knowledge can be a dangerous thing, as noted in Jeff's blog post. With that in mind, I understand the purpose of a salt value but I need a little help understanding how to use salt values.

I've read in the other posts on this subject that it is best to use a random salt value for each password to be encrypted. If this is the case, how do I reproduce that random salt value when I attempt to authenticate a user? In this scenario I would encrypt the plaintext password supplied by the user, encrypt it, and compare it to what is stored in the database. Do I store the random salt value on the user record along with the encrypted password when the password is created? Does this then make the salt value useless if a hacker has the complete user record?

+1  A: 

I usually store my salts in the same table as the user data - if a hacker gets direct access to your db they will crack your passwords anyway, a salt is only a method for delaying it. It will somewhat prevent them from using rainbow tables.

Torandi
Large enough salts make rainbow tables completely irrelevant, forcing a brute force search for each password. Also, if a hacker gets direct access to your DB, you've got bigger problems, IMO.
jkf
+4  A: 

The primary purpose of a salt is to prevent the usage of rainbow tables when cracking password hashes - without the usage of a salt, one could simply use a pre-generated reverse-lookup table to find the hash and immediately know what password likely generated it.

With a salt, the rainbow table approach is defeated because the mapping of hashes to passwords is completely different for that particular salt - and thus one would have to generate rainbow tables individually for every salt value (and the time it takes to generate rainbow tables is proportional to the time it would take to brute force the hash without the assistance of the rainbow table in the first place).

Since the salt serves its purpose in not allowing the usage of a pre-generated rainbow table regardless of whether the attacker knows the specific salt for a given user's entry or not, there's no real reason to store it separately, as long as you're using unique salts for each entry.

Amber