2

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.

3

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.

  • I do agree #2 is the best option.. is there any issue on validating the token when the user lands on set password webpage? So that if the token is expired we can give feedback right away – Roberto14 Nov 3 '16 at 8:34
  • 1
    Assuming your reset password page is rate limited and assuming your token space is very large, no. If those things aren't true, you may be opening up for brute force attacks. – crovers Nov 3 '16 at 13:03
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.

0

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.

  • Can you clarify "anyone processing a large dump of traffic" – Bryan Field Nov 2 '16 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.