2

So I'm working on my first password reset mechanism. I'm going with what I understand to be a fairly common procedure:

  1. User clicks "Forgot Password"
  2. User is prompted for email address
  3. If the entered email address is valid, send an email with a reset link to it
  4. Reset link uses a token of some kind to identify the user account and keep its details secure
  5. When password is reset, generate a new token and save it to the user account

I feel like this should be pretty secure, but I was wondering if anyone could provide any insights that I may not be considering at this point.

  • 2
    Your reset tokens need to be time limited. – Daenyth May 28 '14 at 11:21
  • How would I manage that? I understand storing a date at which the token would expire, but as far as I can understand, I'd need a service running 24/7 to reset the token after its expiry if that is to be handled automatically – Ortund May 28 '14 at 11:23
  • 1
    When a user asks for reset make a token with a creation timestamp and store it in a database table. When the link is clicked with token (non guessable, like a uuid) you check the tokens time against current and see if it's within acceptable window, maybe 24 hours. If it's not don't perform the reset but show the user a message saying the reset link expired and if they intended to change it to try the form again. – Daenyth May 28 '14 at 11:33
  • 2
    So I assume I should only generate a reset token ad hoc rather than keep one for each user from registration... – Ortund May 28 '14 at 11:46
6

From the OWASP Forgot Password Cheat Sheet:

  1. Gather Identity Data or Security Questions

    The first page of a secure Forgot Password feature asks the user for multiple pieces of hard data that should have been previously collected (generally when the user first registers). [...] At a minimum, you should have collected some data that will allow you to send the password reset information to some out-of-band side-channel, such as a (possibly different) email address or an SMS text number, etc. to be used in Step 3.

  2. Verify Security Questions

    After the form on Step 1 is submitted, the application verifies that each piece of data is correct for the given username. If anything is incorrect, or if the username is not recognized, the second page displays a generic error message such as “Sorry, invalid data”. If all submitted data is correct, Step 2 should display at least two of the user’s pre-established personal security questions, along with input fields for the answers.

  3. Send a Token Over a Side-Channel

    After step 2, lock out the user's account immediately. Then email or SMS the user a randomly-generated code having 8 or more characters. This introduces an “out-of-band” communication channel and adds defense-in-depth as it is another barrier for a hacker to overcome. If the bad guy has somehow managed to successfully get past steps 1 and 2, he is unlikely to have compromised the side-channel. It is also a good idea to have the random code which your system generates to only have a limited validity period, say no more than 20 minutes or so.

  4. Allow user to change password

    Step 4 requires input of the code sent in step 3 and allows the user to reset his password. Display a simple HTML form with one input field for the code, one for the new password, and one to confirm the new password. Verify the correct code is provided and be sure to enforce all password complexity requirements that exist in other areas of the application.

There's more detail at the link.

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.