Mark Alan Richards

Reset Password Links are a Security Failure according to the HTTP RFC

security privacy data-protection

tl;dr

https://tools.ietf.org/html/rfc7231#section-9.4

9.4.  Disclosure of Sensitive Information in URIs

   URIs are intended to be shared, not secured, even when they identify
   secure resources.  URIs are often shown on displays, added to
   templates when a page is printed, and stored in a variety of
   unprotected bookmark lists.  It is therefore unwise to include
   information within a URI that is sensitive, personally identifiable,
   or a risk to disclose.

Reset Password Link

Reset password links typically work by generating a unique URL containing enough random data to be considered impossible to guess.

The user opens the URL, the request is validated by the service provider and they then offer a user the ability to set a new password.

Why a failure?

The reset password page may include the following and lose the link as a referer:

Nobody would load third party content on their reset password page?

I've found it on sites by these companies:

*Some have fixed it!

"But it's okay on https"?

No, that's a myth I've heard a few times. There is a security improvement on HTTPS, but it is only that it won't be sent to http sites. It is still available to third party http JS loaded on the page (document.referer) and it's sent to all other HTTPS sites.

"But they will only used by the user"?

What evidence do you have of this?

I saw opposing evidence, one company admitted 5% of requests to their reset password pages were from multiple sources and I've seen logs showing user agents for reset password links as bots.

So how do they use it?

A percentage of users will not complete the request after opening it. They may get distracted (meeting notification, baby screaming, train entering a tunnel, endless numbers of reasons for why you might not finish what you are doing on a page).

Also, users cannot beat a bot. Once the password has leaked to a third party an automated system would reset the password quite quickly.

But wouldn't users notice?

Maybe, but I'd suggest that without evidence, most users would consider it a bug that the reset password page failed and retry (maybe assume that the link expired) and if they got an email suggesting it succeeded, might believe they'd typed their password wrongly when entering it into the reset password flow (had caps lock on?) so would try again.

But wouldn't the website notice?

Depends on what it is used for. If you wanted to steal data, then without any malicious changes to the site you could grab user data. Also, if you kept the percentage of requests low for malcious changes, like purchases, then it'd be within expected bounds for account fraud and the user would likely be blamed.

But you can protect it? Yes, but can your developers?

As with most of the web, it is not designed with security in mind. It is an after thought.

In this instance, you need to learn about Referer policies and the dangers of loading third party JavaScript, or you could use multiple factors of authentication or only include the randomised token in the transmission to the user (so they have to type it).

Given the companies I've seen fail at this (and I'm guessing the list is very long I just don't have time to fish them all out) then I doubt most companies employ developers who know how to both create a secure reset password page and then maintain it (from the risks of someone thinking, great I'll add Google Analytics to the page, an explicit breach of GA's terms).

Bug Bounty Time

This is a simple bug bounty win... go get 'em!