Maybe I'm missing something, but if my salt and hashed/salted password are stored in the same place, how is salting any more secure than just hashing? Does this just rely on attackers not knowing how the salt is incorporated into the hash?
$\begingroup$
$\endgroup$
7
-
3$\begingroup$ I recommend this answer $\endgroup$– CryptographeurFeb 10, 2014 at 17:41
-
$\begingroup$ @figlesquidge since that answer is not directed at my exact question, can you please summarize into something like this so I can mark your answer as accepted: "It doesn't help much with the security of a single password, but if salts are unique it prevents the attacker from being able to check hashes against a large list of hashed passwords at a time. The attacker would only be able to check against one password at a time." $\endgroup$– Clint PowellFeb 10, 2014 at 17:52
-
1$\begingroup$ Question (probably for meta); this question really isn't the same as the "Use of salt to hash a password" (as that question really focused on salt length), however that answer is spot on. Should we dup this question to that question? $\endgroup$– ponchoFeb 10, 2014 at 17:57
-
1$\begingroup$ I agree, the questions are different. @figlesquidge Maybe simply quoting that other question's answer (and attributing it with a cross-link) would be an option? $\endgroup$– e-sushiFeb 10, 2014 at 18:08
-
1$\begingroup$ @figlesquidge Hmmm… this question comes pretty close too. (Your canonical "Salt et al." idea surely seems to make sense.) $\endgroup$– e-sushiFeb 10, 2014 at 18:11
|
Show 2 more comments
2 Answers
$\begingroup$
$\endgroup$
2
The resume of that other answer could be:
When you have a password hashed, it's hard (very hard) to find out what was the original password: you have to try all combinations, until you find the hash. That's brute-force.
Someone can speed up a bit this process, by pre-computing many passwords: he'll store all those passwords / hashes, and will try to find it when he needs.
Someone can also see that two hashes are the same, and then he'll know that both passwords are the same.
To avoid these weakness, you use salt: it's a not-secret value, unique to each login/password pair. That way, the 1st problem (pre-computed hashes) won't work anymore, because he should have generated those pre-computed tables (called rainbow tables) including the salt.
The 2nd problem is also addressed: since each login will have it's salt, even if the same password was used, the hash will be different, since (salt1 + password) is different from (salt2 + password).
And there is also some marginal benefit: the password ends up being longer, since it'll have the salt + password. Of course, it's not any help if you think that the salt isn't secret and the password will be brute-forced. The attacker will simply compute all the combinations appending the salt. But it's a benefit if you think that the salt, alone, has 8 characters (for example): then any pre-computed table with 8 or less characters is useless, because (salt + password) will be longer than 8 characters.
-
$\begingroup$ TLDR, salts increase the difficulty of cracking a database of passwords from $O(n)$ to $O(n * m)$ where $n$ is the number of password guesses and $m$ is the number of entries in the database. $\endgroup$ Feb 10, 2014 at 22:00
-
1$\begingroup$ What happens if you use no salt can be seen here: xkcd.com/1286 $\endgroup$– tyloFeb 12, 2014 at 15:06
$\begingroup$
$\endgroup$
If the salt value is not secret and may be generated at random and stored with the password hash, a large salt value prevents precomputation attacks, including rainbow tables, by ensuring that each user's password is hashed uniquely. This means that two users with the same password will have different password hashes (assuming different salts are used). In order to succeed, an attacker needs to precompute tables for each possible salt value. The salt however must be large enough, otherwise an attacker can make a table for each salt value.
Also please go through this.
