Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
3  
I recommend this answer –  figlesquidge Feb 10 at 17:41
1  
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? –  poncho Feb 10 at 17:57
1  
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? –  e-sushi Feb 10 at 18:08
1  
@figlesquidge Hmmm… this question comes pretty close too. (Your canonical "Salt et al." idea surely seems to make sense.) –  e-sushi Feb 10 at 18:11
1  
@e-sushi Maybe simply quoting that other question's answer (and attributing it with a cross-link) AFAIK that's the way cases like this have been handled so far (across SE not just here). –  rath Feb 11 at 9:51
show 5 more comments

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
    
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. –  Stephen Touset Feb 10 at 22:00
1  
What happens if you use no salt can be seen here: xkcd.com/1286 –  tylo Feb 12 at 15:06
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.