Storing unencrypted salt for password hash in database

Question

When using salt in a password hash, why is it recommended to use a different salt for each password and store it unencrypted in the database?

It seems so pointless. Surely if an attacker gets access to the database and they find out the salt it's just like having no salt at all?

If they are trying to crack passwords through bruteforce and they have the plain unencrypted salt right there in the same row as the encrypted password, they could just concatenate the salt with all the words/phrases they are going to try couldn't they?

Downvote: *"this question does not show any research effort"* — deceze, Feb 15 '13 at 14:40
@deceze Does not show any research effort? Are you kidding me? — Andy, Feb 15 '13 at 14:41
See answer at [what is best possible way of salting and storing salt?](http://stackoverflow.com/questions/1753028/what-is-best-possible-way-of-salting-and-storing-salt) — deceze, Feb 15 '13 at 14:42
I've searched this site many times and Google for a good answer and there aren't any. They all explain why you should use salts etc but not why you should store plain text and how this helps security — Andy, Feb 15 '13 at 14:43
Excellent explanation: http://stackoverflow.com/a/1645190/476 — deceze, Feb 15 '13 at 14:46
@deceze I've never seen that answer before after many many searches. Thanks — Andy, Feb 15 '13 at 14:47

score 3 · Answer 1 · answered Feb 15 '13 at 14:36

The point of the salt is to prevent someone from attacking all the passwords at once. Since each password has a different salt, an attacker has to attack them individually. This greatly reduces the number of possible passwords he can try for each account.

Otherwise, an attacker could just hash a billion possible passwords and then compare each hashed password against his list.

jgroenen · Answer 2 · 2013-04-08T06:54:08.383

See http://en.wikipedia.org/wiki/Rainbow_table first.

If you use a random salt for each password, the hacker cannot make use of a rainbow table.

You need to store the salt unencrypted, to be able to hash a string to check if it matches the salted hash of the original password.

Some crypt functions concatenate the unencrypted salt (amongst other things) to the encrypted, salted password. Der php bcrypt blowfish for example.

score 0 · Answer 3 · answered Feb 15 '13 at 14:37

A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. The attacker has access to both the encrypted password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password.

http://en.wikipedia.org/wiki/Salt_%28cryptography%29

score 0 · Accepted Answer · answered Feb 15 '13 at 14:38

To bruteforce a hashed password, an attacker needs to try to hash all possible combinations of letters and symbols and compare it to the hashes he has.

If the attacker has bruteforced a plaintext > hash combination like this once, he knows the plaintext for all identical hashes.

A salt is added to a plaintext before hashing so the same plaintext hashes to a different hash, forcing an attacker to try all combinations of letters for each individual hash, slowing him down tremendously.

Argeman · Answer 5 · 2013-02-15T15:03:23.563

You need the salt to make rainbow tables and that sort of things useless.

The salt can be stored encrypted of course, making things a bit more complicated to crack a single password.

But look how it usually works: You send the salt to the client which uses it to hash the salt+password. So your client would have to decrypt the salt first, which can be done by any atacker in many cases. In cases where the attacker hasn't got the chance to observe the client-behaviour, encrypted hashes might improve security (security by obscurity).

score 0 · Answer 6 · answered Feb 15 '13 at 14:40

If someone gets a hold of your DB, you're in big, big trouble for a variety of reasons. It would be a lot easier for an attacker to get (or guess) a single salt .. in theory. If they know the only salt you use, they can brute force all passwords simultaneously. If you use a different salt for each user, the attacker has to know each individual salt to attack effectively.

As for encrypting the salt for storage .. I suppose there's nothing wrong with doing that, it's just that it is hopefully rare that an attacker will be able to dump your entire DB. If they could, they may be able to get what they were after anyway even without having to circumvent authentication.

Storing unencrypted salt for password hash in database

6 Answers6