Reset Password Links are a Security Failure according to the HTTP RFCsecurity privacy data-protection
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:
- links to same origin pages: document.referer available to third party JS
- links to third party pages: referer sent to third parties when clicked
- third party content: referer sent to third parties on reset password page load
- shared libraries from CDNs (eg: bootstrapcdn)
- analytics and social media spyware
- ironic fraud detection JS (some finance sites)
Nobody would load third party content on their reset password page? #
I've found it on sites by these companies:
- Daily Mail
*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.
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!