5 ms·

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 t

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.

nileshtrivedi 10y ago
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 10y ago
  If you could somehow encode the value of "PasswordLastUpdatedAt" in your token, you will then could have truly "stateless" tokens.
derekprior 10y ago
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.
- anton_gogolev 10y ago
  > 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 10y ago
    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 10y ago
      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).
- nchelluri 10y ago
  Thanks for the additional thought process here; just a minor question, what's an HMAC token?
  - derekprior 10y ago
    https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithm 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.
jordanlev 10y ago
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).

nileshtrivedi 10y ago

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 10y ago
If you could somehow encode the value of "PasswordLastUpdatedAt" in your token, you will then could have truly "stateless" tokens.

derekprior 10y ago

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.

anton_gogolev 10y ago
> 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 10y ago
  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 10y ago
    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).
nchelluri 10y ago
Thanks for the additional thought process here; just a minor question, what's an HMAC token?
- derekprior 10y ago
  https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithm 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.

jordanlev 10y ago

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