Are there secure alternatives to single-use password reset links?

Question

We currently have what I believe to be a pretty standard scheme for dealing with password resets. Our reset links are single-use links: They expire immediately after they've been visited, even if the user doesn't actually reset their password.

However, our customers are predominately (99%) businesses with aggressive spam filtering. In particular, some of our biggest customers (school districts) have a spam filters in place that perform link-scanning. They visit [up to N] links in an email as part their algorithms. When users request a password reset, the links are "expired" by the spam filter's visit before the user sees them.

Are there any alternatives to the single-use link that are equally secure? Or that are secure enough to fall within the realm of acceptable practices?

We also need to consider usability. Our customers are generally about as non-technical as you can get. So ideally, the password reset procedure won't become [much] more complicated for the user.

---

Here's what we've thought of so far:

• Store the reset token in the session. The link would remain active while the original browser session is open and/or the password hasn't actually been reset. It may complicate the process for users who use two different devices for their email and browsing (e.g., email on phone + laptop for browsing).
• Expire the link after N minutes. I think I've seen this. But, I don't know what time limit is an acceptable balance between usable and secure.
• Expire the link only after the form is submitted. Some users may visit the link, putting it into a browser history, but never submit the form. Is that an acceptable level of risk?

Answer 1

As always, you have to consider the value of the asset you're attempting to protect in order to properly assess if a security procedure is adequate or not. Typically, you'll be willing to accept lower usability when the value of your asset is high.

This means that it's impossible for anyone than yourself to estimate whether a given solution is secure enough.

That being said, a simple way to solve your issue is not to have your links expire immediately but have them expire after a period of time OR when the password has been reset (whichever comes first).

In order to decide whether this is secure enough for you, and assuming you're satisfied current setup, you will need to consider the following changes:

The same link can now be reused several time. This potentially weaken the security of the system.

However, you are currently working on an assumption that is incorrect: the first person to visit a link is the legitimate user. It's clearly not the case (as you've noticed). The consequence is that you're not really increasing the overall security by having the link expire immediately after first access.

So, in my opinion, changing the way your access token expires seems like a better solution: you're increasing usability without impacting the overall system security.

You might, however, consider including some second-level validation in the page you land in when using your reset link. Something that will somehow improve your confidence the user identity (typically, a "security question" is used although that model is not very good).

Answer 2

I don't see the security of a single use password reset link like you describe it. Most single use links are only invalid if the password is changed, not if the page is loaded for the first time. An accidental press on reload or F5 will make the request invalid? This is some kind of a very bad user experience.

So let's think about this: A user orders a password link, two things can happen:

1. A 'hacker' gets the mail first. By using your system the actual user has no chance to even open this link, this is very bad for the user and you. But in this case there is no additionally security by letting the link expire by first time usage.
2. The user gets the mail as desired. Everything is Ok here, but if an accidentally refresh is made, the user has to start with ordering a new link.

To make the system more secure you could build a system where an additional mail is sent to the user with a link to 'recover' the old password, if he/she wasn't the one who changed it. I do not want you to send the old password in plaintext to the user (you shouldn't even be able to do so). What I mean is to historize the old password hash and salt and if the user clicks 'revert' you just use the old hash and password again. Surely, this won't help if the mailaccount is compromised, but for your example with a public computer where the reset link is stored it would help.

Additionally you could forbid to change the accounts mail the first X days after a password change. That way a Hacker could not lock out the user completely (as long as the mail account is not compromised, but in this case there is very little you can do).

Another option is to give the user a code after registering (per old-fashioned letter for best security, if this is too expensive show it on the page itself when the user logs in for the first time with the express request to print it out - still better than sending it to the possible compromised mail account) which acts like an emergency-recovery for the given account. For example when this code is entered, the user can enter a new mail and password to gain access to the account, no matter what happens. But this code has to be very secure, and should really in no way be saved on any computer.

Even more security would be added by using two-factor authentication, like you can use with Google, GitHub and many more. You can even use the system from Google, so you don't have to build everything yourself. This way an attacker has to steal the user's cellphone - making random attacks impossible.

And lastly, a very big and important point: NEVER send the password via mail. I've seen many big websites which do this and there is no way this could be a good idea!

Answer 3

The real threat is that an account could be hijacked. Currently your security is based on keeping password reset links secret, because with it anybody may set a new password at will. Using a single-use link, doesn't help because you don't know if the first visitor is the actual user or an imposter.

To improve your situation, there are three options

• Keep the password reset link secret by using a secure medium instead of unencrypted emails. For example PGP-encrypted email, SMS (not encrypted but more difficult to intercept), TextSecure message, paper letter, ...
• Don't rely on the link to be secret. Then you need some other way to authenticate the user. All examples I can imagine are costly: a more complex password which was sent by postal services (like a PUK), sending a fax with personal information (could also be faked, but is more difficult), additional questions which only the user could answer ...
• Keep your current solution, allow multiple visits to the password reset page, reject attempts after a defined period of time (for example 2 hours) and hope that your network is secure. (Anecdote: Until 2013 most email providers in germany exchanged emails unencrypted.)

Answer 4

One approach to this problem, which I am considering implementing myself could work as follows:

1. User opens the password reset page, which has a form with an email address field.
2. User POST the form with their email address
3. Server send a one-time password to the email address entered by the user.
4. The server reply to the POST request with a new form containing:
   • Hidden field with a secret value
   • Text field for entering one-time password
   • Two password fields for entering the new password
5. On submission of the second form the server verify that the secret value in the form and the one-time password being entered do in fact correspond to each other. Additionally it verifies that the values are no older than x hours (for some x between 1 and 24).
6. If everything was entered correctly, the password is reset.

This is similar to using a session cookie, but the secret value in a form field is likely to be less persistent than a session cookie. It is possible to combine such that the first POST request create three values one in the email and two in cookie and form field in the POST reply, and the second POST request must contain all three values to reset the password.

A variation of this approach, which I am also considering is as follows:

1. User opens the password reset page, which inform them about a one time email address on the same domain as the web page (or a subdomain). Additionally the page contains a form with a hidden field with a secret value and a one-time password field.
2. User send an email to the address, which they were informed about.
3. At the end of DATA, the receiving mail server immediately starts sending a reply to the user's email address. This reply will contain a one-time password.
4. The one-time password that was send to the user is now copied from the email into the form.
5. Server verifies that hidden field and one-time password correspond to each other (connected through the one time email address).
6. If successful the user is presented with user accounts registered to the verified email address.

The second approach might not be completely thought through yet, but I imagine it has the following advantages over simply sending an email to the user:

• You have one more opportunity to validate that the user does in fact control the email address, as you can validate SPF records at this point.
• You are less likely to disturb users with illegitimate password reset emails, as an attacker would have to pass the SPF check before the reset mail will be sent.
• The reset mail is less likely to be blocked by a spam filter, because it is an actual reply to an email sent by the user.

Answer 5

Mail system you're dealing with has a huge security breach by itself. A robot reading secure mails is no problem, but a robot that sends parts of supposedly secure message (links) out to the internet is plain unacceptable. Sad as it is, it rules out links as secure means of transporting data from users to server. You need to consider other options, without customized links at all:

1) Replace links carrying data in URL with generic link to a form + copy-pastable security code. It's certainly worse user experience, however if you unclutter the mail and form to bare minimum and provide short and clear instructions, it should be manageable for everyone.

2) Use one-time passwords instead. The mail would contain one-time password and instructions to log in with it, which would redirect user to "define new password" page.

I recommend second approach, as it's less threatening to users (they are already familiar with login procedure and you can disguise the whole process to look similar to login), you don't need to maintain yet another page (the "enter reset code" page), and the message is short and compact ("your new password:") so you can use other means of delivery, like text messages.

Answer 6

You should consider using two methods simultaneously:

1. Expire the link after N minutes/hours

2. Expire the link only after the form is submitted.

This should be good compromise between security and usability.