views:

211

answers:

5

Ok, I’m trying to understand the reason to use salt.

When a user registers I generate a unique salt for him/her that I store in DB. Then I hash it and the password with SHA1. And when he/she is logging in I re-hash it with sha1($salt.$password).

But if someone hacks my database he can see the hashed password AND the salt.

Is that harder to crack than just hashing the password with out salt? I don’t understand …

Sorry if I’m stupid …

+6  A: 

If you don't use a salt then an attacker can precompute a password<->hash database offline even before they've broken into your server. Adding a salt massively increases the size of that database, making it harder to perform such an attack.

Also, once they've broken in they can guess a commonly used password, hash it, and then check all of the passwords in the database for a match. With a different salt for each user, they can only attack one password at a time.

There's an article at Wikipedia about salts in cryptography.

Mark Byers
It's especially fun if you continually salt and re-hash a number of times. Sure, it's slower for the user to log in, but it's not feasible then even knowing the salt to try to brute force the password.
StrixVaria
@StrixVaria: How would re-concatenating the salt and re-hashing be any different than simply concatenating the salt multiple times? I don't think this would lend you any extra security.
Mike Daniels
Only because of the extra time it would take for each "guess" in the brute force attempt. If you hash x times, it takes x times longer per guess. As x gets large, the number of guesses able to be attempted decreases.
StrixVaria
All that does is increase the time needed to generate the rainbow table. Once I have the table, a lookup of hash(salt + hash(salt + password)) is no slower than a lookup of hash(salt + password).
Mike Daniels
http://en.wikipedia.org/wiki/Key_stretching
StrixVaria
damn didnt think of that, thank you
Krzysztof
+1  A: 

It's slower to crack. The salt prevents the cracker from utilizing a pre-built dictionary of hashed terms.

nullptr
A: 

Another intention behind the use of a salt is to make sure two users with the same password won't end up having the same hash in the users table (assuming their salt are not the same). However, the combination of a salt and a password may lead to the same "string" or hash in the end and the hash will be exactly the same, so make sure to use a combination of salt and password where two different combination won't lead to the same hash.

JP
A: 

If an attacker creates a giant table of hash values for plaintext passwords, using a salt prevents him from using the same table to crack more than one password. The attacker would have to generate a separate table for each salt. Note that for this to actually work propertly, your salt should be rather long. Otherwise the attacker's precomputed table is likely to contain the salt+password hash anyway.

Mike Daniels