Time limited, or one time use, password reset tokens?

Question

Users forget passwords, and (nearly) all membership sites need a way to help users get back in.

I'd like to implement the common scenario:

1. User hits site, tries to log in, can't, and realizes they forgot password - crap!
2. User enters email address and clicks "forgot password"
3. User gets email with a password reset link

Here's how I'm planning to implement this (C#/ASP.NET MVC):

1. When the user enters email and hits "forgot password" button my site will generate a GUID, store it on the member's entity in the DB (member.ResetToken), and email them a link with that GUID in the url (the email sent will inform them they can use this link to one time only)
2. User clicks the link and my site looks up their account based on that member.ResetToken from the url. If their account is found show them a password reset form, and when they complete the reset it clears the member.ResetToken from their account.

Here's my question: keep it like this (in which they can reset their password with that link at any time, now or in the future) or add a timestamp to limit how long they have to reset their password?

From a UX perspective the ability to reset your password whenever you're ready is great, but I want to make sure I'm not overlooking some security issues this could raise.

Answer 1

Your scheme actually works, but there are some points that could be improved. But first to your original question about the time limit:

Let's ask the opposite question: Why should a token remain valid infinit?

There is no advantage, when the reset-link can be clicked two years later, either the user clicks the link in about an hour or he has probably forgotten about the link (and can request a new one if necessary). On the other hand, being able to read the e-mails doesn't necessarily mean, that an attacker must hack the e-mail account, there is for example the open e-mail client in the office, a lost mobile phone, a backup on the (lost) USB drive...

The most important improvement is, that you should only store a hash of the token in your database. Somebody with access to the database (SQL-injection), could otherwise demand a password reset for any e-mail address he likes, and because he can see the new token, he could use it to set his own password.

Then i would store those reset informations in a separate table. There you can store the userid, the hashed token, an expiry date and the information whether the link was already used. The user is not in a special state then.

Maybe i misunderstood this point, but the reset link should point to a special page for password resets. When the user goes to the login page, there should be no special handling, the login page should not be aware that there is a pending password-reset.

The reset token should be unpredictable, this can be achieved best with a really random code, reading from the random source of the operating system.