tags:

views:

103

answers:

3

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?

+5  A: 

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.

Jon Skeet
+4  A: 

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.

Zippit
Quick question. If you hash the passwords with a different salt each time, and store the resulting value instead of the password. How do you know what is the salt to use to hash the password the user give at login if you don't store the hash anywhere ? You don't store the random salt in the database right ?
Pierre 303
If you're using random salt, you store it with the password. Otherwise, you can't recreate the hash to check the password.
cHao
That's what I wanted to read ;) Check this interesting answer (the comment of Ian in the first answer): http://stackoverflow.com/questions/615704/preferred-method-of-storing-passwords-in-database
Pierre 303
i can't understand this first reason (that everyone is talking about- sorry, im new to this salts theory). a site db will use same secret salt for all password hashses. then how will similar salted password hashes be different?
thevikas
@Vikas: They won't. If you have the same salt and the same password, you'll get back the same hash. This is why hard-coded salt is not much better than no salt at all.
cHao
+3  A: 

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

CrazyJugglerDrummer
If you want to test that "password" is the correct password, how do you do this without knowing the salt, "hello"? As far as I understand, you have to store the salt... right?
Thomas O
You have to store it, but it could be "stored" as a variable in your script. Hard-coding salts is only marginally better than not salting at all though, IMO.
cHao