Tom Moertel's Weblog: Never store passwords in a database!

Never store passwords in a database!

Tom Moertel — Fri, 15 Dec 2006 13:25:00 -0500

Recently, the folks behind Reddit.com confessed that a backup copy of their database had been stolen. Later, spez, one of the Reddit developers, confirmed that the database contained password information for Reddit’s users, and that the information was stored as plain, unprotected text. In other words, once the thief had the database, he had everyone’s passwords as well.

Had the folks at Reddit salted and hashed the passwords, the thief would now be in a very different situation. Instead of holding all the keys to the kingdom, he would face the prospect of a potentially expensive search for each and every user’s password he wanted to extract from the database. The expense of the search would likely have dissuaded him from making the attempt in earnest, given how little exploitable value a Reddit account represents. In short, the passwords would have been secure, even though the database had fallen into the thief’s hands.

Why, then, didn’t Reddit’s programmers salt and hash the passwords before storing them in their database? Because, according to the earlier post by spez, they wanted to be able to send forgotten passwords to users via email. It was a design decision: they weighed the risks of having plain-as-day passwords in the database against the convenience of being able to email users their forgotten passwords and decided that, in the balance, convenience carried more weight. It’s a decision they now regret. (It’s a doubly unfortunate decision because you don’t need to store passwords in your user database in order to offer convenient account recovery.)

The reason I’m writing about this event isn’t to kick the good folks at Reddit while they’re down. Rather, I’m trying to make a point:

If you are storing passwords in a database, you are almost certainly making a mistake.

The guys at Reddit are known for being smart. They thought they had a good reason for storing passwords in their database. They were wrong. If smart programmers can make this mistake, lots of programmers can. Do you think you have a good reason for storing passwords in your database? If so, you’re probably wrong, too.

How can I be so sure? Because, when it comes to web-app authentication, cutting corners doesn’t buy you anything. It doesn’t save you coding time. It doesn’t give your users a better experience. All it does is weaken the security of your web application, needlessly putting your users, your employer, and yourself at risk.

So please let me take this opportunity to ask if you know of (or perhaps work on) any software systems that store passwords as plain, unprotected text in a database. If so, fix your software now:

Salt and hash each and every password (use an expensive hashing function such as bcrypt that was designed for password applications)
Store the salt and hash – not the password – in your database.
Throw the password itself away.

You’ll be glad you did.

Update: Minor edits for clarity.

Update 2007-02-13: Salting and hashing does not get in the way of account recovery. You do not need to email users their forgotten passwords: there are other account-recovery options that are just as convenient but much more secure. See Don’t let password recovery keep you from protecting your users for more.

Update 2007-10-03: Revised text slightly to emphasize that there is no benefit to be had by implementing a weak password system, and therefore there is no reason not to implement a secure system. Pointed more directly to bcrypt, too.

"Never store passwords in a database!" by Hurricane

Tue, 26 Aug 2008 20:04:25 -0400

I was looking for links about the typical password-stored issue and found this.

I’ve read the comments an I can only add this : encrypted passwords is BAD.

Why ?

_ Because there is a way to decrypt them. _ Because it means YOU know the password of your users. And if you are a company it means that the disgrunted guy you just fired knows them too.

If a user loses his password, start an recovery using a question and contact him by email/fax/phone/... to allow him to reset.

Digests are good :

A digest using a salt, login and password will not allow an opponent to retrieve the password easily. He may find something that matches the digest but it will most probably not be the original password of the user. (So he is safe, which is what matters)

You can also use a few random bits in your digest. It means you will have to try&error all the bits to see if one matches but it means the brute-force attacker will have to too. It will be less expensive for you than for him. (Just check the last OpenPGP specifications)

"Never store passwords in a database!" by Tom Moertel

Thu, 27 Mar 2008 23:36:50 -0400

James, thanks for your question.

In answer, what stops a (reasonably secure) application from unencrypting the password from the database and then sending it to the user is that the password isn’t encrypted or stored in the database. Rather, the password was fed to a one-way hashing function, and the resulting hash value, which cannot be “decrypted” into the original password, was stored in the database instead. The password itself was thrown away and is long gone by the time a user might need to recover his account.

Cheers! —Tom

"Never store passwords in a database!" by James Law

Thu, 27 Mar 2008 12:32:38 -0400

Forgive me for asking a possibly obvious question but what stops your application from unencrypting the password from the database and then sending it to the user via email?

Just for the record I do disagree with this method of password recovery as email isn’t a secure medium.

"Never store passwords in a database!" by David

Sat, 01 Dec 2007 01:59:17 -0500

bcrypt is not nearly as secure a hash as sha1 or even md5.

"Never store passwords in a database!" by brianeleahy@cox.net

Mon, 10 Sep 2007 13:34:02 -0400

More then likely it wasn’t smart programmers that dropped the ball.

I bet it was dumb managers insisting that the functionallity of emailing someone their forgotten password was of dire importance.

"Never store passwords in a database!" by Coda Hale

Fri, 02 Mar 2007 02:46:53 -0500

FWIW, I went out and implemented state-of-the-art password hashing for Ruby:

http://blog.codahale.com/2007/02/28/bcrypt-ruby-secure-password-hashing/


require "bcrypt" 

password = BCrypt::Password.create("secret")
password #=> "$2a$10$zMW2EmVgmKLRtHZLHUPZk.yydsOQPkqMvko2A8GYpJT0o7QVlNrq." 
password == "wrong password" #=> false
password == "secret"         #=> true

password = BCrypt::Password.new("$2a$10$zMW2EmVgmKLRtHZLHUPZk.yydsOQPkqMvko2A8GYpJT0o7QVlNrq.")
password == "wrong password" #=> false
password == "secret"         #=> true

It doesn’t get any easier than that. Don’t be Reddit.

"Never store passwords in a database!" by Andy Chilton

Sun, 25 Feb 2007 18:18:03 -0500

I wrote an article (in Sep 2006) on storing passwords. This was after hearing of a few places where plaintext passwords were being use. You might like to check it out:

http://kapiti.geek.nz/random/setting-a-good-example-with-passwords.html

I agree, salting and hashing your passwords is the way to go.

Thanks for the article pointing out Reddit’s mistake.

"Never store passwords in a database!" by Coda Hale

Tue, 20 Feb 2007 15:29:58 -0500

This is why engineers look down on programmers.

“Yeah, but you only need that kind of support if you’re going to have a lot of cars on the bridge. Duct tape will do fine—you can always replace it once you’ve got a lot of cars on the bridge.”

“There are no fixed rules with high-voltage electricity. That’s why we use dried-up oatmeal as an insulator.”

“But if you can’t kick through the walls of the building, then how will people get inside?”

“Look, responsible people should be wearing parachutes at all times. That way, when a bridge collapses they won’t have to die. It’s common sense, and people who drive on bridges without parachutes get what they deserve. They should know better.”

“You’re probably better off inventing your own steel alloy, like maybe 30% iron, 10% old GI Joe figurines, and 60% margarine. If you paint it rust-colored, people won’t know the difference. But that’s really just for ‘fun’ skyscrapers.”

“I don’t see why we should have to spend so much time making sure the dam doesn’t burst. I mean, someone could just use a garden hose and flood the houses downstream just as easily.”

Jesus wept. Tom, thanks for the article—always nice to see a flash of competency in muddy water. “How would you design an authentication system” just became my #1 job interview question.

"Never store passwords in a database!" by Parker

Fri, 09 Feb 2007 11:12:49 -0500

I use a program called Secret Server. It uses all that good stuff (SHA512, AES26)and works well for multi-users because you can share and audit.

"Never store passwords in a database!" by Tom Moertel

Fri, 09 Feb 2007 09:51:47 -0500

Unni, the primary benefit of using a hash is that it is one way. Once you salt and hash the password, there is no practical way to retrieve it, not for would-be attackers, nor for you. Thus when users forget their passwords, you cannot mail their passwords to them.

How, then, can they log in? If your site requires no stronger authentication than knowing that users own the email addresses they claim to own, you can use the following method.

Say Joe has lost his password and wants to recover his account. Here’s how you do it:

Generate a big, random, unique token and stuff it into Joe’s account record in the database along with the current date and time.
Send an email to Joe, but instead of enclosing his password (which you can’t recover), tell Joe to click on the enclosed account-recovery link, which of course includes the random token: http://example.com/recover-account?token=pCIqq1unxntVqc8XtCXg.
Joe receives the email and follows the link, which sends his token to your site.
Look up the token in the user database. Is it there?
1. No? Render “Sorry, bub, that token is bogus, so we cannot recover your account.” Stop.
2. Yes? Excellent. Grab the user record associated with the token. (It will, of course, be Joe’s record.)
Is the date and time stamp on that record more than a few hours old?
1. Yes? Render “Sorry, bub, that token has expired.” Stop.
2. No? Congratulations. Joe has effectively authenticated himself via his email address.
Render a confirmation screen that explains the following to Joe:
1. His account password is going to be reset to the following random string: ocZodbew. (Generate a new random password each time.)
2. If he likes the password, great. If not, he can use the change-password feature immediately after the password is reset.
3. If he understands the above and wants to reset his account password, confirm by clicking the big “Reset My Account Password” button.
Joe clicks the big button.
You, in response, do the following:
1. Delete the recovery token from Joe’s user record in the database. (This prevents somebody who steals a copy of Joe’s mail from using the old token to steal his account.)
2. Replace the salt and hash for Joe’s old password with a new salt and the salted-hash of the new, randomly generated password from above.
3. Render a screen saying, “Joe, your password has been changed to ocZodbew. If you would like to change it, just visit Change Password in your account preferences.” (Provide a link.)
And you’re done!

If that seems like a complicated process, you should know that the code required to make it happen is shorter than the explanation above. In any case, it’s a small price to pay to protect your users’ passwords.

Cheers,
Tom

"Never store passwords in a database!" by Unni

Fri, 09 Feb 2007 05:15:22 -0500

Definitely, its bad idea of storing password in plain text in database,rather store it in salting hash. BUT i have no idea how to DECRYPT the salted hash. I want to know, if user FORGETS his/her password then HOW we are going to get back the password? I am creating a login page & i have to add “FORGET PASSWORD” feature also. How can i do it??

"Never store passwords in a database!" by neuroxik

Wed, 27 Dec 2006 05:31:33 -0500

One method that could be used if one feels it’s better to send back a password by email than requiring a reset is to atleast use a homegrown encryption algorithm. Now I’m not talking about writing a 100K class, just something rather simple and append random chars, make it equal to 16 or 32 bytes to make it resemble a md5/sha1 hash and use that same algo to restore the password. Of course, that would be to use only on “fun” sites.

"Never store passwords in a database!" by Anony Moose

Sun, 17 Dec 2006 18:16:05 -0500

Alternate design: The “I forgot my password” handler generates a cryptographically strong new password, then sends that out to the user, who can then reset their own password back to the name of their dog.

Well, ok, sending passwords by email isn’t entirely perfect, but it would have been less bad.

And it avoids screwing around with encrypting passwords in the database and thus needing to protect the key used to decrypt the passwords. If the hackers can get the database, they can get the key – and if they can’t get the key, then the database could have been protected.

And if the protocol “requires” the password to be stored in plain text, perhaps you’re asking for trouble by using that protocol. But if you don’t have a damn good reason to require the password to be stored as plaintext, then doing so is just wrong. It’s nowhere near necessary enough to be worth the risk.

"Never store passwords in a database!" by Peter

Sun, 17 Dec 2006 05:01:31 -0500

Tom Moertel:

Natural language usage doesn’t have to be sloppy. That in itself is a design decision by the user.

"Never store passwords in a database!" by Jonas

Sun, 17 Dec 2006 04:46:31 -0500

Storing passwords in a database in cleartext is, as someone mentioned above, /required/ for some protocols, but then it’s very important to encrypt the backups with GPG. This doesn’t help the security of the runtime database but it sure helps securing backups.

"Never store passwords in a database!" by Noah Slater

Sat, 16 Dec 2006 14:23:10 -0500

Nate, why can the login form NOT be embedded on the same page?

"Never store passwords in a database!" by Nate

Sat, 16 Dec 2006 11:55:25 -0500

Just a copy of my comment on reddit:

It’s not incompetence but a common design decision of 95% of the “fun” sites everyone here uses every day. Go look at YouTube and MySpace, no SSL and they both send back the original passwords in email. 37Signals sends back forgotten passwords in email. Everyone here then should spread this outrage around with all those sites too.

If the site isn’t using SSL for logins, then it doesn’t really matter if these passwords are cleartext in the database. And if you move to SSL logins, then that makes logging in one extra click for everyone. (since the login form can’t be embedded right on the page anymore, or your form is prone to a ‘man in the middle’ attack)

I expect my Mom maybe to use the same password at Reddit and at her bank, but the people here!? Why would you trust any site with the same password that you might use somewhere that’s important?

I like these Reddit guys a lot, but Aaron is one shady looking mofo. :) I just assume that he’d try to use my password at every bank site he could find to funnel money into his porno slush fund.

"Never store passwords in a database!" by oldmangettingold

Sat, 16 Dec 2006 10:14:39 -0500

The best way to store passwords is not storing it. Whenever an user creates an account and provides a password, the following technique can be used to make the life of hackers difficult: 1. use some unique technique should be used to generate a salt, 2. concatenate the salt to the password, 3. use a hashing algorithm such MD5 or SHA1 to hash the password 4. Encrypt the hashed key and save it to database

To authenticate: 1. After the user enters the password, use SSL to transfer the password to the server, add the salt and take a hash, retrieve the encrypted hash, decrypt the hash and match the hashes to authenticate the user.

Though, the above method is bit cumbersome and will take time to develop, but it works good and makes the life of a hacker much more difficult.

"Never store passwords in a database!" by J. Random Hacker

Sat, 16 Dec 2006 10:13:29 -0500

Ow, the stupid. It hurts us, precious.

The average user has maybe one or two passwords, so it’s a disservice to them to store their passwords in the clear.

The slightly more clever user has good, unique passwords for everything important, and a couple of disposable login/passwords combos for everything else. (I know, everybody here uses a randomly-generated 12-character alphanumeric string for each and every Web 2.0 site. But we’re talking about everybody else, not you.)

So, any way you look at it, salting and hashing passwords is the way to go. You could also use an iterated SHA1 hash, applying it perhaps 50 times. This slows down authentication slightly, but proportionally increases the work required for a dictionary attack.

"Never store passwords in a database!" by lexandro

Sat, 16 Dec 2006 10:12:49 -0500

Dear Tom!

I translated your post to hungarian and posted to my blog with your blog’s URL

Lex

"Never store passwords in a database!" by Noah Slater

Sat, 16 Dec 2006 09:26:25 -0500

Binny V A, hashed passwords can be recovered using dictionary attacks.

"Never store passwords in a database!" by Binny V A

Sat, 16 Dec 2006 08:47:51 -0500

If you hash the password(MD5/SHA1), retrieval is impossible. So ‘Forgot Password’ will not work. Yes, you can reset the password – but that tends to irritate the users.

If you are maintaining a critical website – where unauthenticated access can create real problems, there is no excuse for not hashing the password. But in the case of reddit, that is not so important.

The lesson to be learned here is not to use the same password on all sites.

"Never store passwords in a database!" by Noah Slater

Sat, 16 Dec 2006 08:41:56 -0500

pcdinh, your argument makes no sense. PHP is a language, not a framework, and so each application is likely to store passwords as per the developers preference.

"Never store passwords in a database!" by pcdinh

Sat, 16 Dec 2006 08:33:45 -0500

Reddit seems not to be a PHP application. Almost PHP applications store hashed passwords in a database so it is rather difficult to guess them out even the database are stolen.

Is Reddit implemented in Python or Ruby?

"Never store passwords in a database!" by Markus

Sat, 16 Dec 2006 04:30:21 -0500

You ask for the passwords not to be stored in a database. But where else ?

In the fine print you talk about salting and hashing, but your headline should say: Don’t store clear-text passwords !