[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).