Can someone explain how salts help when storing hashed passwords?

Question

I am having difficulty understanding how a salt which is appended to a hash helps improve the security when a database of passwords or other important information is compromised.

If the salt is, for example, "hello", and is appended to the password "password" then the salt and password are stored together, "hellopassword" and hashed to produce:

94e66f94517d606d5ad6d9191b980408952f2ed2 (sha1) 

with the salt then appended:

hello$94e66f94517d606d5ad6d9191b980408952f2ed2

How is this more secure? The attacker knows the salt so can now compute the passwords with little extra difficulty... right? Or am I fundamentally misunderstanding something?

Answer 1

No, not with "little extra difficulty" - with potentially significantly more difficulty.

Imagine there are two billion common passwords. It's easy to hash all of those and store the results. Then if you have an unsalted password hash, you can just check which common passwords match the given hash.

Now compare that with a salted hash... now you have two billion common passwords, but also several billion possible salts. Computing all the possible salt/password combinations will take much, much longer - hopefully becoming infeasible.

Additionally, it means that even if two people have the same password, they are very likely to have different hashes - so carelessness of one user in revealing their password doesn't risk the security of the other.

See the Wikipedia entry (if you haven't already) for more on this.

Answer 2

salt helps in 2 ways:

1) When two (or more) people use the same password, without salt you can see who uses the same password (the hashes are all the same). So in theory, if that person knows one of those person's passwords he knows everyone's passwords with the same hash. This is a minor reason.

2) The main reason is to prevent attacks commonly called dictionary attacks or rainbow attacks. In these attacks someone uses a database of pre-calculated hashes for common passwords. Often times these databases are gigs in size. But it is very easy at that point to just do a lookup for the hashes you have (the hashed password) against the list of pre-calculated hashes and see what the associated password is.

By using a salt value (typically you want this to be a random number) the hash won't match the dictionary (the chance of them pre-calculating all passwords with all possible salt values is exponentially more difficult). So even if your user uses an easily attacked password, say "Password", which is pretty much guaranteed to be any in any password dictionary/rainbow table, by pre-pending your random salt value you make the hash pretty much guaranteed to be useless to the attacker. Meanwhile for you, since the salt is just stored in cleartext, it makes it very easy for you to add it to your cleartext for your comparison of the password the user entered.

Answer 3

The salt isn't appended to the hash, its appended to the password THEN hashed. This is more secure because hackers have to know the salt and the actual password, which you should both protect heavily. :D