Should password reset link expire when clicked, or wait until reset is filled out and completed?

Question

Im implementing a password recovery solution that follows this Generic Framework convention:

https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Insufficient_Password_Recovery#Generic_Framework_Solution

My questions is when should the reset token be destroyed. According to the frameowrk, "The reset token should be invalidated as soon as it is used."

Does it mean:

1. to destroy as soon as the user lands on the webpage to enter a new password
2. to destroy when we call the API to reset it with the new password

First option means the user cannot refresh/hit the page twice because is going to destroy the token in the first landing. Second option allows the user to hit the page as many times as he want because token validation is made upon a new password is provided. Although, we could go further and validate the recovery token when the customer hits the webpage but destroy it only when a new password is provided.

Can you please give me a hand on this?

Note: Link to reset password is provided by email.

Answer 1

I don't see a problem with #2 and it is certainly more user friendly, provided that the reset page is only available through https (so that it can't be mitm'd and someone can't sneak in faster).

I don't see a vector to exploit #2 that isn't there for #1.

Answer 2

With "used", they of course meant when the password reset was submitted. Not when the link was clicked. Else they would say "Destroy the token when the link is clicked"

It would be a very cumbersome process if the user clicks the link, and then enters a password which doesn't meet your password rules... oops link invalidated, now user has to start over from the beginning.

There is a risk that the actual password reset token could be stolen in-transit on the page load, and then used before the user actually submits the password reset. But this risk can be mitigated by not including the reset token inside link. Instead you have two links on your login page: Forgot password - which will email the token. The email then contains no link at all.

And then reset password, which will provide a form that request username, new password, comfirm password, and token.

Then the user has to input the token from the email manually instead of it being included in the link, thus avoiding the possibility to sniff the token and then use it before the real user. Because then the adversiary has to block so the real request never arrive.

Answer 3

I agree with @crovers. Another trick would be to put a timer on the link, say 30 minutes. Easy to do, unlikely to impact valid users, but does make life harder for anyone processing a large dump of traffic.