Understand the need to protection credentials with hashes that are expensive and to use cryptographically random salts.

What I would like to understand is why you would store the salt along side the hash in the database, does this not defeat the point of having one?

Take a SQL injection vulnerability in which I can dump the data in the User table. If I have access to the Hash as well as the salt does it not make my brute force attempt easier (as apposed to not knowing the salt?).

If storing the salt with the hash - does this not defeat the point of protection against rainbow attacks? (if an attacker has access to the database).

  • What you are discussing is called "pepper". You can read about it at security.stackexchange.com/questions/3272/… Sep 22, 2015 at 16:56
  • 1
    I'm not referring to a pepper (it is not constant for each and every record) - I'm asking about a per record salt that is not made up of a cryptographically random value - rather a concatenated value of each record such as the ID Column + username + date of birth or whatever.
    – whoami
    Sep 22, 2015 at 17:00
  • 7
    The purpose of the salt is to make the use of rainbow tables infeasible. See stackoverflow.com/questions/420843/… for more info.
    – mti2935
    Sep 22, 2015 at 17:08
  • 2
    Thaanks @mti2935 - so does storing the salt alongside the hash not defeat the point of protecting against rainbow tables - does it make it easier for an attacker to crack the password using a rainbow table if they have the salt?
    – whoami
    Sep 22, 2015 at 17:15
  • 4
    The point of a salt is to ensure that work done to crack one password cannot be reused to crack a different password. The point of a rainbow table is reuse of work through precomputation. Additionally, a static value like database ID, username, etc are not suitable for salts as new salts must be used any time a user changes their password. Sep 22, 2015 at 17:16

1 Answer 1


I can see where you're coming from, but the answer is basically "that's not what the salt is for". If I'm trying to discover a particular user's password, the salt doesn't help much if it's right beside the hash. However, it's not expected to be useful in that situation - cracking an individual user's password is difficult enough already.

The point of the salt is that it's something to add to each password before hashing such that each password is unique - if two users both have hunter2 as their password, the hashes need to be different.

Say an attacker is fishing through a database (or a whole range of databases) to find everyone whose password is letmein123. Without a salt, they can do the hash once and search for the hash.

Without a salt if an attacker spots two or more identical hashes in the database, it indicates that this is a weak password (since multiple users have chosen the same one) and can concentrate on cracking this first.

But the salt is a user-specific prefix/suffix that is added to the password before hashing, so (even with a "public" salt) an attacker has to re-calculate the hash for every user - so checking one password against 10000 users isn't any more efficient than checking 10000 passwords against one user, which is the point.

  • That makes sense. Does storing the salt alongside the hash make it easier to brute force the password?
    – whoami
    Sep 22, 2015 at 17:18
  • 3
    That's not the threat salts are designed and intended to protect against. A door lock doesn't prevent someone from opening your window. Sep 22, 2015 at 17:20
  • 1
    Great - so using a strong hashing technique will hopefully save you in this case - and storing the salt alongside the hash does not make your hash any weaker.
    – whoami
    Sep 22, 2015 at 17:22
  • 2
    Is hunter2 a reference to this bash.org's quote? ☺
    – A.L
    Sep 22, 2015 at 20:37
  • @A.L always. :)
    – cloudfeet
    Sep 22, 2015 at 20:52

Not the answer you're looking for? Browse other questions tagged .