I'm developing a small, non-commercial web app. I'm trying to decide how to help a user who might have lost their password. I need a mechanism that is, in order of priority:
1) User friendly;
2) Secure;
3) Easily scalable across multiple geographies (i.e., location agnostic - so no SMS for example).


An alternative approach:

  1. Have the user provide the email address they used when they registered

  2. Verify that email address does indeed belong to an account (report an error if it does not)

  3. Send an email to that email address with...

    • ...a new password that is auto-generated (dictionary words are better than random characters) and expires after a set period of time (let's say 24 hours)

    • ...a message that this new password was sent as a request from your website and if they didn't request it to ignore that email

    • ...the URL they need to visit to re-login with their new password (make sure this page validates against the temporary password and not their actual password)

  4. After their initial login, take them to a page where they are required to update their password to one they will remember (you can't show them their actual password because you hashed it, right?)

  • Yes, the pw are hashed. – JDelage May 18 '11 at 22:06
  • How do you do #2 ("Verify that email address does indeed belong to an account")? Thanks! – JDelage May 20 '11 at 22:37
  • 1
    Just query your database. If it's there it belongs to an account. – John Conde May 20 '11 at 22:46

My standard operating procedure:

First, prompt the user for their email address or login name. If the information is not found, it's nice to tell the user that the address is bogus, but that can also help people brute-force this information. In systems where the login and email address are not identical, asking for either of these on the same page may be more user-friendly than separating them onto different pages.

Second, generate a unique token and associate it with the account. Send an email to the user's email address containing a link that integrates this token into the URL, allowing for one-click account retrieval.

Third, when the URL with the token is visited, prompt the user for their new password. Make sure the form submit also includes the token. Change the user's password to the new desired value, then invalidate the token.

A variation I've seen also adds a second token into the mail, which must be typed in on the resulting password reset page.

You should also invalidate the token after a reasonable period of time -- say, 48 hours.

You'll note a lack of password reminders or security questions here. If the user's email account has been compromised, this allows a potentially malicious user to hijack accounts. This isn't your problem to solve. You could add some sort of security question, but before you do, think about the last time you were confronted with one of these, and recall how much of a pain in the rear end they are.

If your system allows the user to be logged in from multiple places (it'd better!), you might want to make sure that the token(s) you use to permit this are tied to both the user's email address and password. This will log the user out of all other locations when either of these change.

  • 1
    Make sure the URL with the token isn't very long or it will wrap in the body of their email and break the token causing it to fail. – John Conde May 14 '11 at 3:46
  • I'm not sure that line wrapping is a major problem in the modern era. Everything supports quoted-printable now, which permits longer lines to be split in the message body without impacting the formatting. We'd then just need to worry about wrapping post-decoding, and most users, especially users that we'd worry about usability for, are going to be running a client that probably won't obsessively break lines into 76/78 character chunks. Even then, HTML email avoids the wrapping problem entirely. – Charles May 14 '11 at 4:03
  • 2
    I only mentioned it because I recently had issues with it myself. The problem with emails is you never know how the user's email client will display it. Even if it is HTML since they can view them as plain text anyway if their client is set to do so. You pretty much need to make sure the entire URL is short enough to fit on one line in plain text to be reasonably sure everyone will see it intact. – John Conde May 14 '11 at 4:05
  • I'd love to know what client you had problems with so I can ensure bad things will happen to the author... – Charles May 14 '11 at 4:07
  • 1
    Email wrapping is most certainly a problem. I have a set of standard answers to questions that my customers ask me that include links to my blog. Typically these links are long (I know I could tinyURL them) and about 10% of them complain of links being broken due to line wrapping in their email clients. – nemmy May 14 '11 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.