[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?
