Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
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 accomplish...
Answer
#3: Post edited
by
Canina
·
2020-11-24T08:05:04Z (about 4 years ago)
- 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.
- 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](https://en.wikipedia.org/wiki/Pepper_(cryptography)). 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.
#2: Post edited
by
Canina
·
2020-09-17T08:05:20Z (over 4 years ago)
- 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.**
- 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.
#1: Initial revision
by
Canina
·
2020-09-17T08:01:27Z (over 4 years ago)
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.**