What exactly does password hashing and salting protect against?

[eluser]aidehua[/eluser]
Here's what I'm doing - following (I believe) something like best practice:

In the USERS table in the database:
I have a 'salt' field, which contains a unique random string,
and a 'password_hash' field, which contains a sha1 hash of the user's password concatenated with the salt, i.e. sha1($password.$salt).

So when a user attempts to log in, his password is not compared directly with the password in the database, but instead it is first concatenated with the salt from the database, then hashed, and then compared with the 'password_hash' field.

In what ways is this more secure than simply storing passwords in the database in plain-text - and in what ways is it not more secure?

As I see it, salting and hashing would mean that the passwords in the database are safe even if the database falls into the wrong hands.

(Though if someone gets unauthorised access to your database, you've got bigger problems anyway, I'd imagine.)

But in terms of protecting against a dictionary/brute force/guesswork attack, what do you gain? If a user chooses a weak password ('123', 'abc', 'password', etc.), his account is still just as vulnerable to being broken into, and the hashing and salting offers no protection.

To protect against that sort of attack, the best you can do is require users to choose strong passwords (and limit the number of failed login attempts allowed).

Am I right? Any comments?

[eluser]wowdezign[/eluser]
It's true that if a person uses a weak password, then their account is vulnerable.

Hashing and salting passwords helps against "rainbow tables". I hope the reference is alright:

http://en.wikipedia.org/wiki/Rainbow_table

Some developers like to use a site salt. I use a different salt for each user in the db.

Hope that helps.

[eluser]JanDoToDo[/eluser]
As wowdesign said if the user chosoes a weak password their account is vulnerable! However, salting adds extra protection as it introduces a random variable into the password field that would prevent(or at least help with any potential attack). IMO, the salt should NEVER be stored in the database as if someone got access to your table then the salt would mean nothing. Instead, I for example use a script which chooses a certain length of string from the password they typed, md5 it and then concatanate that with some random characters (. ? / !) etc.. The salt in that case would be different for every user but repeatable on every occasion. If the attacked only got the Db then the password would still be extra secure with the salt.

Similarly, when a user is just signing in, the salt would help as the rainbow table attack would fail and it would take far too long for a potential hacker to get onto the system.

(But im not by any stretch of the imagination an expert.. so take what i say with a pinch of salt!)

[eluser]jimps[/eluser]
[quote author="wowdezign" date="1262824970"]It's true that if a person uses a weak password, then their account is vulnerable.

Hashing and salting passwords helps against "rainbow tables". I hope the reference is alright:

http://en.wikipedia.org/wiki/Rainbow_table

Some developers like to use a site salt. I use a different salt for each user in the db.

Hope that helps.[/quote]

It's smart to use static salt AND dynamic salt (different for every user). It's also a good thing to don't collect the dynamic user salt in a extra column named "Salt" or something like that. A better way is to use already stored data and merge it with other data.

[eluser]n0xie[/eluser]
This should make a lot clear: http://chargen.matasano.com/chargen/2007...out-s.html

As I see it, salting and hashing would mean that the passwords in the database are safe even if the database falls into the wrong hands.

(Though if someone gets unauthorised access to your database, you’ve got bigger problems anyway, I’d imagine.)

Correct on both accounts.

But in terms of protecting against a dictionary/brute force/guesswork attack, what do you gain?

Nothing, your assumptions is correct.

The purpose of a salt is not to make guessing harder, it's to make rainbow tables ineffective. There is a big difference.

IMO, the salt should NEVER be stored in the database as if someone got access to your table then the salt would mean nothing.

That's not how salting works. The point is that it is irrelevant what the salt is. The only reason to use salts is to prevent the generated hash from being predictable. So even if they have the salt, generating rainbow tables would still take too long. So saving the salt in the database is not an issue. Obviously it would be safer to store them somewhere else, but if your database is compromised, your system will probably be compromised anyway, so there really is no safe/convenient way to store salts.

Instead, I for example use a script which chooses a certain length of string from the password they typed, md5 it and then concatanate that with some random characters (. ? / !) etc..

[/quote]
That's not random. If the 'algorithm' of your script gets compromised, you basically compromised your entire dataset, since it uses a predictable outcome: every password goes through the same 'function'. Generating a rainbowtable once this piece of info is known is trivial.

Similarly, when a user is just signing in, the salt would help as the rainbow table attack would fail and it would take far too long for a potential hacker to get onto the system.

If you mean that your salt is protecting against a brute-force login attempt, I dare say you are wrong. Whenever a bot tries to log in, it will be send to your 'obfuscate' function which generates a salt just like it would for a normal user. If the bot guesses the password correctly nothing in your salting system would stop it.

I go into more detail on the subject in this long post.

[eluser]JanDoToDo[/eluser]
"That’s not random. If the ‘algorithm’ of your script gets compromised, you basically compromised your entire dataset, since it uses a predictable outcome: every password goes through the same ‘function’. Generating a rainbowtable once this piece of info is known is trivial."

The code would however produce a different salt for each user and also, if only the db was compromised then the salt is not known and so the rainbow atack would be made EVEN more difficult...? (although I do accept if your db is compromised your whole site is probably anyway). Eitherway the salt is introduced - it must be coded somewhere, and your point about the script being compromised would be equally true for my salting method and a different salting method as it will be coded somewhere how the salt is added. However, my point was that if the script isnt compromised then the salt isnt known, and im sure there are standard things people do to combine salt/hash and the hacker would know these and be able to test(if he had the salt). If the salt isnt known they cant do that? Obviously it would all take way too long for anyone to do anyway..true?

[eluser]Colin Williams[/eluser]
I see absolutely no reason to use dynamic salts.

[eluser]bretticus[/eluser]
Oh how I love to chime in on security issues (whether I'm good at it or not!)

So even if they have the salt, generating rainbow tables would still take too long. So saving the salt in the database is not an issue. Obviously it would be safer to store them somewhere else, but if your database is compromised, your system will probably be compromised anyway, so there really is no safe/convenient way to store salts.

Really, the hashing doesn't protect you at all from brute force attacks to your website since your authentication mechanism simply hashes an easy password including the salt anyway before it compares the result with the hash in your database. Thus, the only benefit of hashing is to protect passwords from prying eyes of other administrators or a hacker who compromises your database only (which in a sense can possibly give him or her a free ride to your website anyways as mentioned.)

It should be noted though that if the username/password hash data were compromised, it would be trivial to build a rainbow table based on a dictionary plus the salt stored in the database. Thus, I think there is some merit to storing salt elsewhere.

[eluser]n0xie[/eluser]
[quote author="JanDoToDo" date="1262847907"]Eitherway the salt is introduced - it must be coded somewhere, and your point about the script being compromised would be equally true for my salting method and a different salting method as it will be coded somewhere how the salt is added. However, my point was that if the script isnt compromised then the salt isnt known[/quote]
The whole point of a salt is that it's useless garbage data. I can give you a whole list of salts from one of my databases accompanied with the password hashes associated with it and it would be useless to you. The salt is only valid for 1 row, so for 1 password.

An example:
id hash salt
1 ABC 123
2 DEF 456

Let's say the password for id 1 is 'codeigniter' and the password for id 2 is 'rocks'. You would add the salt making the password 'codeigniter123' for id 1 and that generates the hash 'ABC'. Now let's assume the you found out the password and want to make a rainbowtable: you would add the salt to every word in the english dictionary and see if the hashes match. So your rainbow tables consists of the word 'rocks', and then it would add the salt 123, making the password 'rocks123', which would NOT generate the hash 'DEF', because that one is generated by 'rocks456'. This will be true for every password in the database as long as the salt is unique.

So you see it doens't matter if the salt is known: the idea is to make rainbowtables unusable by making the time it takes to generate/compare every possible combination to the dataset 'very' long.

[eluser]JanDoToDo[/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?