Posted too early…
Salts aren’t designed to protect a single password, they’re designed to protect an entire database by increasing the time cost of generating a table for each individual user. You can crack any password you wish (which isn’t too strong for a dictionary attack). But once again, do you need more than one password? Especially if you see a nice little username called “admin” or “administrator”.
@Spoon: email isn’t a secure medium. If somebody intercepts the email, they have your password.
@JW: It’s a bit like this: would you give the keys to your house to somebody just so that they could get a number out of your address book? And you give your ATM pin to a random stranger so you could pay for book? What Facebook and sites like it who ask this kind of information from you are doing is just that. They should ask you for your friend’s email addresses, not your first born child.
“Add a long, unique random salt to each password you store”
I still don’t quite get this - if the salt is random, how do we reliably generate the same salt value (For the same user) next time they log in?
Bob Armour on September 17, 2007 06:12 AM
The answer is to simply store the generated salt with the user pass.
For example I use PHP and MySQL and so a simple user information table only needs 3 fields: username, pass, salt
When someone tries to log in then you can check if the details are right by using the following:
$user = mysql_real_escape_string(“USERNAME”);
$pass = mysql_real_escape_string(“PASSWORD”);
$result = mysql_query(“SELECT COUNT(username) FROM table WHERE username = ‘$user’ AND pass = MD5(CONCAT(’$pass’, salt ))”);
if(mysql_result($result,0) == 1)
{
echo “Correct details!”;
}
else
{
echo “You silly hacker”;
}
Hopefully that will clear things up for you.
For all you out there that are still wondering how exactly to store passwords in the database…
You don’t. Try doing this as a minimum:
SIGN UP:
LOG IN:
FORGOT PASSWORD:
Peace,
Greg
Keith: They do give you the ability to enter email addresses; they just also provide the import tool as a convenience. I don’t really see it as giving my PIN to a stranger – I have used Facebook for long enough to trust them.
This feature turns what could be a long process (log into gmail, export your contacts, arrange them into the right format, import them into Facebook) into a very simple one. For me it’s worth the tradedoff. But it would be nice if there were a way to only grant them access to my addresses, and not my mail.
The GMail import is an interesting problem faced by almost every Social Network as they almost all now use libraries to make this easy. It’s also faced by untold numbers of Twitter utilities and many other use cases. There are two lines of attack to deal with this which are related.
Come up with a formal API for exporting and syncing Social Graphs between Social Networks. See Brad Fitzpatrick. Then get it adopted widely.
Come up with a formal API equivalent to OpenID to allow a user to authorise Site A to make data requests to Site B on their behalf. See oAuth.
The problem is not Facebook’s. They’re just using a common bit of code to help the user find their contacts. And it’s not GMail’s. They’re just providing a tool for a logged in user to export their contacts. Unfortunately, it’s the industry’s problem for not coming up with a secure method of doing what the user wants to do.
Storing is one thing. I have seen my share of the bad decisions taken while storing the passwords in plain text. However, we have sites on the internet which do not allow strong passwords.
My personal experience with a payment gateway provider recently taught me that. Their rule was 5-8 characters with no special characters allowed. There is a screenshot on my blog: http://blog.gadodia.net/leading-payment-gateway-disallows-strong-passwords/
I couldn’t come up with an 8 character password without a special character that would show up as strong on the Microsoft Password Checker.
@John Rutherford:
"You still should not be storing in plaintext. You should be storing it using reversible encryption. That way if someone gets a backup copy of your database, as happened with Reddit, they still will not have will not have the encryption key you used. "
Man we already went over this in Jeff’s last post on encryption. The attacker will just get the key, too. If it’s an inside job, this will be trivial. If not, and the attacker can’t get the key, why aren’t you securing your database backups the same way as the keys?
Just store the hash. Password-resetting works just fine. There is absolutely no reason to store passwords (sym. encrypted or plaintext) in a database.
In Jan I was at a company meeting. During the presentation, the dufus who put up some wiki service told us that the back of the room had cards layed out with our username/passwords. I looked at mine and it was my generic password that I use (I had logged in and changed my pwrd prior to the meeting).
So I go to bitch to them, and about 10 other people that this idiot has peoples passwords sitting on the table for anyone to look at. The response I got was “Well, it’s just for this service.” Nobody could grasp that people will re-use passwords and this may give them access to their network or other services.
I finally found one of the directors who went and removed them from the table. I got let go 3 months later. I hope the company burns in hell.
Hey Now Jeff,
As always I enjoy reading your post. I’m interested in your thoughts of CardSpace any similar technology as an improvement to this situation we have of many UID’s pw’s.
Thx,
Catto
@Heffocheffefer:
Well you seem to have the database implementation details correct, but if you really want a secure program, I feel like I should tell you that PHP now supports parameterized SQL.
Even if you remember to mysql_real_escape_string() everywhere, it still has issues escaping multi-byte character sets, IIRC.
The problem is not Facebook’s. They’re just using a common bit of code to help the user find their contacts.
That’s interesting, because Facebook uses images with one-hour expiration tags to prevent anyone from screen-scraping their contacts. Which is exactly what they do to other services…
http://www.25hoursaday.com/weblog/2007/08/21/FacebookTheSocialGraphRoachMotel.aspx
How do you avoid storing a password in plaintext when a password-recovery-service is required?
Why do we have to email the current password to the user? We can simply reset the user’s password, and let them change it after they log in.
if the salt is random, how do we reliably generate the same salt value
I was confused about this as well. You store the hash of the random, long salt in the user table right next to the hash of the password. It’s not a secret, so you don’t have to hide it.
While I admit that all these cross-site functionalities that require one to tell site A what their creds are for site B are open to phishing attacks, as outlined, if site A hashes the password provided for site B, how is site A supposed to make use of those credentials to interface with site B? Site A should encrypt the credentials somehow, in a reversible fashion, so that the credentials can be used repeatedly (assuming that repeated access to site B is part of the feature, for continuous updates) – hashing won’t provide that.
The real fix for this is that sites need to stop being walled gardens and need to encourage cross pollination by providing features to allow users to designate other people/sites access to their data, and need to provide APIs that can be used to programmatically interface with other sites to avoid having to “login” as a user to access that user’s data.
“You store the hash of the random, long salt in the user table right next to the hash of the password.”
Why would we want/need to hash the random salt value? If it is completely visible and completely random then does it make sense to hash it before adding it to the password? Or am I missing something?
if the salt is random, how do we reliably generate the same salt value
I was confused about this as well. You store the hash of the random, long salt in the user table right next to the hash of the password. It’s not a secret, so you don’t have to hide it.
I thought the main idea was that if the database is compromised that the salt would help protect the hashed passwords. If you store the hashed salt in the database, then the salt is no safer than your hashed passwords.
So this really presents a two simple scenarios.
Entire application is compromised, source, database, everything. In this case you’re totally screwed and you need to roll over to a backup plan.
Just the database is compromised. If you store a hash of the random salt in the database it’s not clear to me how you can determine what the original salt was so that means the algorithm is a simple concatenation. salt + password or password + salt. You cannot create a more complex algorithm than that unless you have a way of determining what the salt is. If you store the password plain text you’re almost better off because now you need to account for the salt as a split string and the attacker has no way of knowing short of compromising the app how to shortcut his way past combining the salt and password.
if the salt is random, how do we reliably generate the same salt value
I was confused about this as well. You store the hash of the random, long salt in the user table right next to the hash of the password. It’s not a secret, so you don’t have to hide it.
Are you sure about that? Since hashes are one way, how would you compare a randomly salted password with a provided creditential with out knowing the (unhashed) salt?
@Jeff “Short Flip” Atwood:
“I was confused about this as well. You store the hash of the random, long salt in the user table right next to the hash of the password. It’s not a secret, so you don’t have to hide it.”
What are you talking about, baby? Either that hash is the salt, or you don’t hash the salt. Either way, you need to store the actual salt (possibly encrypted [a]symetrically) in the database.
Why would we want/need to hash the random salt value?
I guess I was thinking of storing hashes in both columns just for consistency’s sake:
hashed salt, hashed password
And then we would compute the password hash by appending the hash of the salt instead of the salt itself:
pass = hash(hashed salt + password))
But you’re both right-- it probably doesn’t matter whether we use the actual salt or the hash of the salt.
Jeff,
Excellent post. One other point (perhaps you can add this to your post): Software developers should never, ever ever email passwords to users in plaintext.
A year ago I signed up with a website that provides a minor free service. As soon as I signed up, I received a confirmation email to the effect of “Thanks for signing up! Your username is ABC, and your password is DEF.”
This meant that not only were they storing the passwords in plaintext, they were emailing it around in plaintext for anyone to see. I was astounded by their incompetence. (I sent them an email, but they never responded.) I had not even asked for them to send my password. Rather, they did this for all new sign-ups.
Of course, the username and password were also the same ones I use for my email service, so anyone with half of a brain could have intercepted this email and gained access to my email account (and other online services.)
You can criticize me for repeating user names and passwords, but I can’t remember more than a few passwords without writing them down. I have another more-secure password for financial sites, and that’s it. I refuse on principle to create a new password for every trifling website I visit.
The bottom line is that services should never send passwords via email. If someone forgets the password, they should instead send a password reset and require the user to enter a new one.
There seems to be a ton of confusion about what a hash is. A few points people seem to be missing:
Rainbow table attacks are basically a scan for the “low-hanging fruits” of the password database. They immediately reveal the insecure passwords, but typically will not crack the better ones. Salts prevent these attacks from scanning the whole table at once.
@Aaron G:
Very interesting point. The username/password combination being a dictionary word is fairly intuitive, but you’re absolutely right that even using the hash of the username doesn’t add much security.