[pacifika]

The problem is that your password reset token shouldn't be reusable. The token is only leaked after the person visited the reset page, which should invalidate the token on load.

Without a valid token, the reset form shouldn't load. Problem solved.

[derekprior]

This requires non-idempotent get requests as you must invalidate the token on get.

I did consider this approach for Clearance and intended to go with it, but was discouraged from doing so after hearing reports that some enterprise email AV does things like open some links in emails.

There is also the user experience concern that a click the link in my email, do something else, then click the link again, having forgotten I already clicked the link. Now I'd have to re-request again.

Also, this approach is impossible if you use HMAC tokens.

I don't think anyone who opts for this approach is wrong but like most things, it's a tradeoff.

[nchelluri]

Thanks for the additional thought process here; just a minor question, what's an HMAC token?

[derekprior]

https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_A...

I might not be using the right term here, but the general idea is that you create an encrypted token out of some data and verify that the data is unchanged and still valid on the server. In that way you can provide a token that ensures the user had access to the link you sent them, but you don't have to store it in the database.

[anton_gogolev]

> This requires non-idempotent get requests as you must invalidate the token on get.

I think you should invalidate a token whenever a user enters a new password and submits a form (hence POST).

[oneeyedpigeon]

That should definitely happen anyway but, as the article points out, that leaves a window of time between the user clicking the link in their email and them completing the form. It might be a very brief window, but it's still exploitable (and it won't always be brief - consider a user clicking the link in their email, leaving their desk for 5 minutes or going to make a cup of tea...)

[Klathmon]

Not to mention the users that will request a reset but then remember, or forget to follow up with the reset (which I myself have been guilty of in the past).

[nileshtrivedi]

How to implement this if the token is not stored in database at all (eg. JWT)? As far as I know, enforcing one-time-use only requires storing a bit in backend.

[anton_gogolev]

If you could somehow encode the value of "PasswordLastUpdatedAt" in your token, you will then could have truly "stateless" tokens.

[jordanlev]

Hence one of the proposed solutions at the end of the article is to generate a new token when the link is used and put the new token into the form.

But some sort of token needs to be used even after clicking the email link because the "enter a new password" form needs it posted as well (to prevent people from using that form willy-nilly on any account).