When a user uses the »I forgot my password« link several times and gets a couple of emails, each one with a tokenized link to reset his password, what would be the appropriate behaviour?

  • All links work and he can reset his password as many times he likes.
  • Only the link in the newest email works and the others aren't valid anymore.
  • It does not matter which token is being used and all remaining links become invalid.

3 Answers 3


Keep track of active reset links for a given email address. If a link is still active, and the 'forgot password'-button is clicked again, resend the active reset link. You can even warn the user that an email was already sent and that she should maybe check her spam folder.

You still run into the problem that no reset link should be active for longer than about 24 hours. It's probably bad security to extend this period for every time the email is requested, so this period should still count from the first request, no matter how many requests follow. From about one hour before the end, a new request should start a new reset link, with a fresh 24-hour window. There's no real need to disable the old one, as it will be disabled soon anyway. This is a potentially confusing situation, but it should be a rare occurrence.

If a user clicks a disabled link, make sure to give really clear instructions, as the user will be confused, and you have all the information to remove this confusion. Tell her she clicked a link that was requested too long ago. If there are active reset links, tell her to check for the most recent reset email. If there aren't any active links, tell her to request again.

  • 1
    You should also limit the rate at which reset emails can be sent. Wikipedia originally had no limit, and sending a flood of password reset emails was used as a way of harassing people.
    – Mark
    Commented Jan 23, 2015 at 23:55

It does not matter which token is being used and all remaining links become invalid.

This is the behavior I would like, and the email could explicitly state "this link will remain valid until [some date-time] or until your password is reset, whichever occurs first" (if the password were reset someway outside the email resets, e.g via tech support, all previously sent reset emails would be invalidated). It's very possible to accidentally request more than one reset email. If one were to delete the latest reset email your option #2 could put one in a confusing lockout situation. Keeping all three links alive (your option #1) would allow multiple password resets which would certainly be unnecessary and possibly confusing.


All links work and he can reset his password as many times he likes.

This sounds like a "user friendly" way to do things, but in reality this means anyone that gets access to their email at any point in the future (provided it's not deleted) can reset their password (and probably knows their account name from the email as well!). The same problem holds true if only the last link is ever active but it doesn't expire over time, so reset links should always be time dependent.

Only the link in the newest email works and the others aren't valid anymore.

This is now it should be done, and this should all be made clear in the email itself. There's really little reason not to do it this way; as long as I can click the "reset password" link (possibly then providing some other form of authentication for super-secure sites) to get a fresh reset link, there's really no reason to keep old password reset links active, they're just a security risk with no significant UX benefit.

Hopefully more security conscious users will actually prefer that your password reset links expire for security reasons, but you can also simply point this out in the reset emails: "For security reasons this link will only work for the next X minutes" or whatever. It's also a convention, and unlike password limits it's a convention for good reason, so following the convention can help your users understand the process and give them more faith in your process.

It does not matter which token is being used and all remaining links become invalid

The problem here is more hard security oriented; imagine I know what your password reset links look like, from my own account (say they're 10 character query strings). Now since I can generate infinite tokens each press of a button, I can greatly expand the space of successful password reset links, making it easier to attack. You can limit the number of reset links active at a time but...at this point you're just adding layers of obscure, awkward edgecase covering when just having one, single link, the standard method of doing this, would completely suffice.

This answer on Cryptography gives a little insight into the standard process for creating a password reset nonce. You can check out the general reasoning for nonces, there's a reason there's usually only one active at once; the more tries you get, the less secure you are. Especially since all the user has to do is click a link in an email, it's really not a bad idea to be picky here.

If you really, really want to cover the edge case of someone repeatedly requesting a password reset link (I really do think you're over thinking this), it would be much better to simply send the same password reset link for a short period of time.

  • I disagree. The user may have clicked the link multiple times because the emails are slow to arrive. If the user hasn't received the most recent one yet, she still can't reset her password, which is frustrating and bad from a UX perspective.
    – Peter
    Commented Apr 24, 2013 at 14:26
  • Thanks. Really helpful. Yes, the links expire even when they are not used. @Peter: Good point, too, but what would your solution look like? Commented Apr 24, 2013 at 14:27
  • 1
    I have to disagree with your first point. If someone gets access to your email, your accounts are compromised whether there are reset emails sitting in it or not.
    – Jeremy T
    Commented Apr 24, 2013 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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