What exactly does password hashing and salting protect against?

[eluser]bretticus[/eluser]
Having read this thread more in depth, having unique salt (even if stored in the same database record) does allow the attacker to create a rainbow table to attack just one record (by the way, you don't have to generate a whole table, you just hash the salt against a dictionary until you find a match.) However, this would slow the attacker down as he or she has to run a dictionary attack for each salt and password hash record in the database. Not a bad idea really.

[eluser]n0xie[/eluser]

However, if the hacker was only after a few rows of the db and not all of them (sensitive user perhaps), it wouldnt matter if the rainbow table couldnt be used for all the rows - with the salt he can make a rainbow table for those few rows he wants?

That is if you also know the way in which the salt is applied. If that is the case you probably have access to the script as well as the database in which case your mechanism would compromise your whole dataset. In my case it would potentially put a few accounts at risk if they use weak passwords. If they use strong passwords the chance of a rainbow table collision is minimal. Keep in mind that rainbowtables can only store a certain amount of data: the bigger the dataset, the longer it takes to find a match.

The whole principle of a rainbow table is based on the fact that many passwords are weak: strong passwords + salt makes rainbow tables unusable.

[eluser]bretticus[/eluser]
[quote author="n0xie" date="1262880736"]strong passwords + salt makes rainbow tables unusable.[/quote]

With emphasis on strong passwords since the salt can be known.

[eluser]n0xie[/eluser]

With emphasis on strong passwords since the salt can be known.

Salting does not make it impossible to mount offline attacks against a password database; rather, salting makes such attacks more costly because it forces each password to be attacked independently. That is, it raises the cost of a precomputed-dictionary attack on the entire database to the point where it exceeds a the cost of attempting to guess each password in the database individually.

Also by adding a unique salt for every user, the change that 2 users have the same password (thus the same hash) is near zero.

[eluser]Rick Jolly[/eluser]
The per-user salt is a bad idea. I'll try to explain why through scenarios:

1. Attacker doesn't have code or database access: Attacker can't use a rainbow table with either site-wide or per-user salt. Guessing the password is the only option.
2. Attacker has code and database: No difference using per-user salt or site-wide salt.
3. Attacker has code, therefore he has the database credentials. See #2.
4. Attacker has database, but not code: Attacker can't create a rainbow table unless he can guess how the salt is applied. That would be easy to do though if per-user salts were stored in the database, since as soon as the correct algorithm for applying the salt were guessed, the rainbow table would be revealed. So, site-wide salt could be combined with the per-user salt, but using just a site-wide salt alone would be just as secure since a rainbow table can't be created if you don't know the site-wide salt - see #1. So a per-user salt when combined with a site-wide salt is useless and just adds overhead.

[eluser]Chad Fulton[/eluser]

The per-user salt is a bad idea. I’ll try to explain why through scenarios:

1. Attacker doesn’t have code or database access: Attacker can’t use a rainbow table with either site-wide or per-user salt. Guessing the password is the only option.
2. Attacker has code and database: No difference using per-user salt or site-wide salt.
3. Attacker has code, therefore he has the database credentials. See #2.
4. Attacker has database, but not code: Attacker can’t create a rainbow table unless he can guess how the salt is applied. That would be easy to do though if per-user salts were stored in the database, since as soon as the correct algorithm for applying the salt were guessed, the rainbow table would be revealed. So, site-wide salt could be combined with the per-user salt, but using just a site-wide salt alone would be just as secure since a rainbow table can’t be created if you don’t know the site-wide salt - see #1. So a per-user salt when combined with a site-wide salt is useless and just adds overhead.

I think you may need to rethink your thoughts on #2 and #3. As people above have mentioned, if you have the code and the database, and the passwords have hashed in some way, then your only solution to retrieving the original passwords is to create a rainbow table. There are three cases:

1. A standard hash has been used (md5, sha, etc), in which case you can just use an existing rainbow table.
2. A standard hash has been used with a site-wide salt, in which case you need to make a single rainbow table using that salt
3. A standard hash has been used with a per-user salt, in which case you need to make one rainbow table per user using their specific salt

So, as you can see, it definitely makes a difference whether you use a per-user or site-wide salt.

-----------------------

However, here's my general thought on this security issue:

1. There is not much overhead, and some additional security added, by adding a salt (either per-user or site-wide), so why not use it?
2. People like to make a big fuss about salts, etc. the fact is that a sufficiently determined attacker will be able to do something to get the passwords he wants if he gets your database and code. Probably better to make sure that doesn't happen then to do something complex and difficult with the password hashing mechanism.
3. It's probably better to start off more secure (i.e. per-user salt) rather than less (i.e. just hashing) because you won't be able to easily change it down the road.

[eluser]Rick Jolly[/eluser]
[quote author="Chad Fulton" date="1262921186"]
I think you may need to rethink your thoughts on #2 and #3. As people above have mentioned, if you have the code and the database, and the passwords have hashed in some way, then your only solution to retrieving the original passwords is to create a rainbow table. There are three cases:

1. A standard hash has been used (md5, sha, etc), in which case you can just use an existing rainbow table.
2. A standard hash has been used with a site-wide salt, in which case you need to make a single rainbow table using that salt
3. A standard hash has been used with a per-user salt, in which case you need to make one rainbow table per user using their specific salt

So, as you can see, it definitely makes a difference whether you use a per-user or site-wide salt.
[/quote]
But creating a rainbow table for each known salt is not hard or time consuming. Let's say you have a dictionary of 1 million common passwords. If you have the salt, you can md5 the entire dictionary with the salt in about 30 seconds using php.

[eluser]wowdezign[/eluser]

But creating a rainbow table for each known salt is not hard or time consuming. Let’s say you have a dictionary of 1 million common passwords. If you have the salt, you can md5 the entire dictionary with the salt in about 30 seconds using php.

30 seconds?

[eluser]Rick Jolly[/eluser]
[quote author="wowdezign" date="1262929300"]
30 seconds?[/quote]
Something like that. I tested md5() within a loop iterating 1 million times. Naturally, a hacker would use a faster platform, but they might use a bigger dictionary as well.

[eluser]bretticus[/eluser]
Hahaha, great thread!

You guys have me convinced on 2 points:

1. There is no way to protect a hashed password in a database if the attacker has access to your code and data UNLESS the password is sufficiently strong (not part of the dictionary list.)

2. When I want to be as secure as possible, I'm going to use a per-user AND a site-wide salt. Of course, that is only going to protect my weak passwords if the attacker gets the database OR the site code AND NOT BOTH. Which brings me back to ENFORCE STRONG PASSWORDS.

Cheers