Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am currently working on a password reset flow. We have decided to go with a password reset link being emailed to the user's registered email and allowing them to follow that and input a new password of their choosing.

The current implementation we have in mind provides a one-time use token but not a timeout feature. Currently the research I have done on the matter seems to suggest that expiring these tokens is in some way more secure than not. However, people have not been citing why that is the case.

Can someone provide a use case where that token (while still being a one-time use) not expiring would be harmful security wise?

Additional Details: I am well aware that sending a password reset link is not the most secure way to handle this problem. Ideally we would not want to obfuscate this security to the email provider. However, we have made the decision to go with a password reset link. We are only trying to determine whether we want that to expire or not. For more information on the matter:

http://www.fishnetsecurity.com/sites/default/files/media/10WP0003_BestPractices_SecureForgotPassword%5B1%5D_0.pdf

share|improve this question
    
Related: security.stackexchange.com/questions/1918/… –  Null Nov 20 '12 at 18:03
1  
1) Hash the reset token when storing it in the database. 2) Add an expiration date so that a 5 year old one still in someone's mailbox isn't still valid. –  ewanm89 Nov 20 '12 at 19:38
    
Just wanted to follow up on the matter with my decision (in the comments): reddit.com/r/PHP/comments/13ioz1/password_reset_links_timeouts –  Austin DeVinney Nov 20 '12 at 19:42
add comment

migrated from stackoverflow.com Nov 20 '12 at 18:01

This question came from our site for professional and enthusiast programmers.

6 Answers

Point taken about how a compromise of the email account that is receiving the token negates some of the benefit of expiring the token. I do still think token expiry has some value, per Jonathan Newmuis.

Scenario:

  1. I request a reset for my account at ACME, which is emailed to my mailbox at Big Kahuna Corp.
  2. I remember my ACME password, and don't use the reset token.
  3. Sometime later, I switch to Gmail, but leave my Big Kahuna account lying around.
  4. Sometime after that, my Big Kahuna mailbox is compromised.

Scenario A: No Expiry

5b. The attacker finds the ACME reset token and uses it to compromise my ACME account.

Secnario B: Expiry after N days

5b. The attacker finds the ACME reset token which has expired, but he now knows I have an ACME account. He re-issues the ACME reset token - and since I have changed to Gmail (and changed my reset address accordingly on the ACME website), the reset token goes to Gmail, preventing a breach and indicating to me that I am under attack.

Yes, the example is contrived, but completely plausible.

Perhaps a good middle ground is to have a list of "currently valid" reset tokens that the user is shown on login, and given the opportunity to revoke them.

share|improve this answer
add comment

On top of the scenarios that have been mentioned in other answers, the main reason I could see for having expiring password reset links is that the link could get cached or stored in a variety of locations and that could (under certain circumstances) allow someone else to get access to the users account.

  • Browser History. This one seems most likely as a risk. User resets a password from a shared PC, I'd expect the link to enter the browser history, so anyone who can get access to that browser can reset the users password and take control of the account.
  • Cached by a proxy server. Obviously if you've got HTTPS then most proxies won't see the link however in many corporates, SSL interception is used so those proxies will cache the link and also IIRC some mobile operators do this kind of thing in the name of cost saving.
  • Added to favourites. User follows link, thinks "this is handy" adds it to favourites, now anyone who uses that browser has access to their account. Not particularly likely but possible.

Whether these scenarios matter to you will depend on your use cases and the level of security that you're looking to provide.

share|improve this answer
add comment

OWASP has a great cheat sheet for password reset, their argument on the limited validity period is like @Jonathan Newmuis said that :

[...] if the user doesn't get around to checking their email and their email account is later compromised, the random token used to reset the password would no longer be valid if the user never reset their password and the "reset password" token was discovered by an attacker.

share|improve this answer
    
I'm familiar with this cheat sheet. It came up in my research. However, the use case of a compromised email is not a valid use case for this. I detail my explanation in a reddit comment. Follow the link in the original post comments if you are curious. –  Austin DeVinney Nov 20 '12 at 19:59
    
@AustinDeVinney, I think it is more effective and helpful when questions here are as self-contained as possible. If you feel this argument is not valid, I encourage you to revise the question to spell out why you believe that. Expecting people to dive into some external reddit link is not realistic. –  D.W. Nov 21 '12 at 0:19
add comment

The biggest problem is that you don't want to store the password reset token in the database in clear text. This produces a shortcut, where by the attacker doesn't have to crack the password hash, he can just reset the password. Storing a hash of the password reset token is a good solution to this problem.

It is a good idea that the password reset token expires and that its onetime use only. However, this is not as a big of a concern as storing these tokens in plain text. The biggest reason to have the token expire is to make it more difficult for the attacker to guess this value. If the attacker has access to the user's email then he can just send another token, which is a moot point.

share|improve this answer
    
Well with the non-expiring solution we wouldn't be storing these tokens in the database at all, but still maintaining the one-time use functionality. –  Austin DeVinney Nov 20 '12 at 18:18
1  
@AustinDeVinney you must store them somewhere, a file on the system is still a form of database. Also there is no guarantee that the user doesn't wipe session cookies (browser set to automatically on exit and user exits it before loading mail client?) or other session information so session specific memory is going to cause issues. –  ewanm89 Nov 20 '12 at 19:41
    
That is not accurate. There are ways around that so you do absolutely no storage, but it comes with other security risks that I deemed too great to take. The details can be found in the reddit post I linked in the comments of the original post. –  Austin DeVinney Nov 20 '12 at 19:57
add comment

For example: if I remember my password, then don't reset it.

Now, if my email account is later compromised (or if I visit the link and anyone decides to peruse my browsing history), they can change my password at will and there is no way I can prevent it except to change my own password.

Unless, of course, you meant the token is only good for one page visit. That's certainly secure, but also inconvenient if I close the page, my session expires, etc.

share|improve this answer
1  
Right. But this is not a valid use case in my eyes because if the email is compromised, then the attacker can already just navigate to myapp.com and request a password reset anyways. In other words, it's no more secure than a non-expiring link. –  Austin DeVinney Nov 20 '12 at 18:09
    
(a) That sort of depends on your exact login flow; if your users log in using a username (rather than an email address), they would still be protected in this case, as long as you don't also include the username in the 'request password' email. (b) Regardless, the latter case still applies, and would certainly suck if I was using a public computer (sure, that's kind of the user's fault, but your job is to protect them). –  Jonathan Newmuis Nov 20 '12 at 18:11
2  
@AustinDeVinney Solid logic, but what if an attacker gains access to an email account that I used to use previously, and no longer have registered with your service? Or really in any case where the link goes to more than one of my inboxes (forwarding, for example). In such cases, requesting a password reset wouldn't work, but the link would still be a vulnerability. –  SpellingD Nov 20 '12 at 20:52
add comment

That's correct. Expiring these tokens is far more secure since an attacker with access to your database will be able to get these tokens and use them to reset users requesting a password reset but not completing their request.

share|improve this answer
1  
"an attacker with access to your database" I feel like there are greater risks here and this goes far beyond tokens expiring or not expiring. –  Austin DeVinney Nov 20 '12 at 18:06
    
@AustinDeVinney Not necessarily: if the attacker only has read access, they would greatly benefit from having a bunch of password reset tokens. –  Null Nov 20 '12 at 18:09
    
if the attacker has read access he can read the username/email address, use the forgotten password feature and then read the token... –  Rook Nov 20 '12 at 18:10
3  
@Austin DeVinney sql injection is very common, applications should defend against this attack as much as possible. This is why we hash passwords. –  Rook Nov 20 '12 at 18:11
    
@Rook Although in that case a token that doesn't expire would be vulnerable to the same attack. I think the OP's question is centered around a token that expires in a certain amount of time versus one that never expires. –  Null Nov 20 '12 at 18:12
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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