Should the Salt for a password Hash be “hashed” also?

Question

This I think may be a silly question, but I have become quite confused on what I should do here for the best.

When salting a password hash, should the salt also be h

Answer 1

The salt should not be hashed, as you need the original value to combine with the password before hashing it.

Answer 2

No you must not hash the salt. The salt is in clear text and it is needed to you to recompute the password and check it with the one stored in the hashed password file.

But if you need a strong salting procedure you can compute your salted password in this manner:

SaltedHashedPwd = H(H(H(H(.....H(PWD-k+SALT-k)+SALT-k)+SALT-k).....)+SALT-k+N

H is the hash function SALT-k is a k-random string you use as salt PWD-k is the k-password (every Password has a different salt) N is the iterations number you compose the H function

In the PKCS#5 standard it uses N=1000!

In this manne a Dictionary attack is not possible because for every word into the Dictionary and for every SALT into the password file, the attacker needs to compute the Hash. Too expansive in time!

I think that N=100 should be enough for your uses :-)

Answer 3

As the salt needs to be saved along with the hash (or at least must be retrievable along with the hash), an attacker could possibly get both the salt and the hashed password. In some of my applications, I've stored the salt encrypted in the database (with a key known only to the application). My reasoning was that storing the salt unencrypted along with the hashed password would make it easier to crack the passwords, as a hacker that would be able to retrieve the password table (and would know or make an assumption about the hash algorithm) would be able to find matches between hashes of well known words (dictionary attack) by hashing each word in the dictionary and then salting with the salt he also has access to. If the salt would be encrypted, such an attack wouldn't be possible unless he would also have access to the encryption key known to the application.

(If anybody sees a fault in this logic, please comment.)

Answer 4

It doesn't matter.

The purpose of a salt is to prevent pre-computation attacks.

Either way, hashing the salt or using it by itself, results in the same data being added as a salt each time. If you hash the salt, all you are effectively doing is changing the salt. By hashing it first, you convert it into a different string, which is then used as the salt. There is no reason to do this, but it will not do anything wrong if you do.

You just need to be consistent and use the same method every time or you will end up with a different password hash.

Answer 5

You must not hash the salt, since hashes are one way. You need the salt so that you can add it to the password before hashing. You could encrypt it, but it's not necessary.

The critical thing about salts is that each password should have its own salt. Ideally, each salt should be unique, but random is good too. The salt should therefore be long enough to allow it to be unique for each password.

If all salts are the same, it's obvious to the cracker (who can see your hash values), which accounts have the same password. The hash values will be the same. This means that if they crack one password, they get more than one account with no additional work. The cracker might even target those accounts.

You should assume that the cracker will gain both the salt and the hash value, so the hash algorithm must be secure.

Having any salt at all prevents using existing precomputed rainbow tables to crack your hash value, and having a unique salt for each account removes the desire for your cracker to precompute their own rainbow tables using your salt.