The purpose of a cryptographic salt is to make the same input (password) hash to different values in different instances, yet retain the hash function's deterministic properties. Salting accomplishes that by concatenating a random value with the password itself before hashing, and storing the value of the salt somewhere alongside the salt+password hash.

This, in turn, renders generating and storing lists of precomputed hashes impractical, because each candidate inputs list will need to be hashed separately for each salt value. If the salt value is large enough, this causes the work and storage requirements to become prohibitive, even for relatively small lists of candidate input values (passwords). This forces the attacker to compute each hash separately for the particular salt; they can't precompute hashes and then reduce finding the password to little more than a table lookup or a search.

Since the salt is chosen at random, there is a very good chance that every single user account (and every time each user changes their password) has a different salt. A large enough salt can virtually guarantee global uniqueness simply by being picked at random.

At the same time, any process that needs to verify that a given candidate input matches the hash, will by necessity require access to the salt value for the particular hash anyway.

The idea behind this is that it forces the attacker to basically do the same work as the legitimate software for each candidate user account and password combination. In the case of a legitimate user authenticating to a legitimate system, making computing the password hash take 10 or 20 or even 100 ms is largely inconsequential, and storing precomputed values is of no benefit; but making an attacker do that work for each combination of user account and candidate password greatly increases the attacker's workload compared to being able to do the work just once for each candidate password.

The fact that the salt is stored together with the hashed password does not materially change that.

Therefore, because of what a salt is intended to do and how it does that, as long as the salt is meaningfully large and selected at random, storing the salt together with the password hash should not materially decrease system security compared to storing the salt separately. As already discussed, it also likely makes it much easier to keep the two values in sync both when reading and when writing, both of which are critical to enable successful authentication by legitimate users.

There is, however, one significant exception to the above reasoning. In NIST SP 800-63B, a reference is made to a "secret salt", more commonly referred to as pepper. This is a value that acts similarly to a salt, but is stored separately and normally is (but does not need to be) the same for all accounts. The purpose of a pepper is to mitigate against the risk of an attacker obtaining a copy of both the salt and the hashed password; if the pepper is large enough, and inaccessible to the attacker (for example, by being stored and processed only within a Hardware Security Module which only exposes, say, an interface that allows hashing a single input, or even only one confirming whether or not a specific input matches a specific hash), this means that the attacker does not have access to all the information required to even confirm whether a specific password guess is correct or incorrect for a specific account given a full data dump; they also need access to the pepper.

posted over 4 years ago

CC BY-SA 4.0

4y ago

Canina‭

1489 reputation 2 23 150 31