6

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 hashed or left as plaintext?

NOTE: I am hashing a password in SHA-256 and the Salt is a pre defined string as only one password will ever be stored at a time.

TIA

Chris (Shamballa).

Shambhala
  • 1,159
  • 3
  • 13
  • 31

5 Answers5

15

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.

Alan Geleynse
  • 24,821
  • 5
  • 46
  • 55
  • I would still recommend strongly against using a static salt. It probably defeats the purpose of having a salt, even if you only store one password at a time. – Slartibartfast Oct 25 '10 at 04:14
  • I would agree, a different salt should probably be used for each password, you just need to use the same salt each time for a given user's password. But the point here was that a salt is just something extra added in. Hashing the salt before you use it doesn't change that, it just makes it a different something extra. – Alan Geleynse Oct 25 '10 at 05:12
  • 1
    It's semantics, but you must not hash a salt. A salt must be retrievable in clear text in order to be used. Since a hash is one way, you must not hash your salt. If you want to use a hash algorithm to generate your salt, that's fine, but the resultant hash value becomes the new salt and you must still be able to retrieve it in clear text. If you truly hash your salt, you've lost your account. – Marcus Adams Jan 24 '11 at 19:45
7

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.

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
  • 1
    @aaaa bbbb, if you hash the salt before storing it, you cannot retrieve the password. If you use a hashing algorithm in your generation of the salt, that's fine. The salt is the part that is added to the clear text just prior to hashing the value. It's not a salt before that. – Marcus Adams Nov 11 '10 at 15:24
1

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

Bob
  • 3,301
  • 1
  • 16
  • 11
0

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 :-)

robob
  • 1,739
  • 4
  • 26
  • 44
  • 1
    Wrong. "It doesn't matter" is the correct answer. You can hash the salt, which in effect gives you a new salt that works. All you have to do is be consistent. – aaaa bbbb Oct 22 '10 at 21:48
  • See better what I wrote. You can has the concatenation of the PWD and the SALT but at the end you have to concatenate the clear form of SALT. Otherwise you cannot recompute the hash in the verification phase. – robob Oct 23 '10 at 07:29
0

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.)

steinar
  • 9,383
  • 1
  • 23
  • 37