In 2006’s most-read article on my blog, Never store passwords in a database!, I urged web programmers, unsurprisingly, not to store passwords in their user databases. I tried to persuade them to salt and hash the passwords instead: store the salts and hashes in the database and throw the passwords away. The article, posted shortly after the Reddit blog announced the theft of its unprotected user database, generated buckets of comments. Reading over them today, I noticed something that I had missed earlier.
It seems that a decent slice of programmers think that switching to a salted-and-hashed password scheme implies giving up the ability to assist users who have forgotten their passwords. If the passwords are irretrievably hashed away, the programmers reason, there’s no way to recover forgotten passwords and email them to stranded users. Hence those users are screwed.
And that wrinkle, it might seem, is a good reason not to switch to a salted-and-hashed password scheme.
But that wrinkle turns out to be imaginary. Not being able to recover an account’s password does not mean that you can’t recover the account itself. The password, after all, is not the thing of value; the account is. And, as we shall see, we can recover an account without knowing its password.
Recall that the primary benefit of using a hash is that it is a one-way operation. Once you salt and hash a password, there is no practical way to retrieve it. That’s what protects it from would-be attackers. But that also means you can’t get at it, either. Thus sending password reminders to people who have forgotten their passwords is no longer an option.
How, then, can you help your stranded users? One method is to send them account-recovery tokens, which you can think of as one-time, special-purpose passwords. (This method is suitable only if you require authentication no stronger than knowing that your site’s users own the email addresses they claim to own. This is the case for most “low security” sites such as Slashdot, Reddit, and Digg, as well as most blogging systems.)
Here’s how it works. Say Joe has lost his password and can’t log in to your site. He clicks that button that says “I’ve lost my password. Help me!” Now what?
Here’s what you do:
Generate a big, random, unique token and stuff it into Joe’s account record in the database. Stuff the current date and time in there, too.
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 includes the random token:
http://example.com/recover-account?token=pCIqq1unxntVqc8XtCXg.Joe receives the email and clicks on the link, which sends his token to your site.
Look up the token in the user database. Is it there?
No? Render a screen that says, “Sorry, bub, that token is no longer valid.” Stop.
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?
Yes? Render that screen that says, “Sorry, bub, that token is no longer valid.” Stop.
No? Congratulations. Joe has effectively authenticated himself via his email address.
Render a confirmation screen that explains the following to Joe:
His account password is going to be reset to the following random string: ocZodbew. (Generate a new random string each time.)
If he likes the password, great. If not, he can use the change-password feature immediately after the password is reset.
If he understands the above and wants to continue, he should confirm by clicking the big “Reset My Account Password” button.
Joe clicks the button.
You, in response, do the following:
Delete the recovery token from Joe’s user record in the database. (This prevents somebody from using the old token to steal his account, should, for example, Joe’s email get stolen.)
Replace Joe’s old password with the new, randomly generated password from above. (You will, of course, use the salted-and-hashed method and not store the new password itself.)
Log Joe in.
Render a screen saying, “Joe, please don’t forget that your new password is ocZodbew. If you would like to change it, just visit Change My Password in your account preferences [provide a link]. Otherwise, you’re logged in and ready to go. Enjoy the site!”
And you’re done.
The code required to make it happen is shorter than the explanation above. It’s one of those easier-done-than-said things.
So, if concerns about account recovery have been holding you back from protecting your users’ passwords, you need hold back no longer. It’s time to “do” your due diligence.
Update 2007-09-10: I made clear that the account-recovery method I describe above is suitable only for low-security sites where a valid email address is sufficient to authenticate users.