# If attacker knows salt and hash, how is salt effective?

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?

-
I recommend this answer – figlesquidge Feb 10 '14 at 17:41
@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." – Clint Powell Feb 10 '14 at 17:52
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 '14 at 17:57
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 '14 at 18:08
@figlesquidge Hmmm… this question comes pretty close too. (Your canonical "Salt et al." idea surely seems to make sense.) – e-sushi Feb 10 '14 at 18:11

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.

-
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 '14 at 22:00
What happens if you use no salt can be seen here: xkcd.com/1286 – tylo Feb 12 '14 at 15:06

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.