Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Prevent password reset token leak via HTTP referer #706
The password reset token is included in the URL emailed to users who
Taking advantage of this would require an attack to:
This is a rather involved exploit, but something we should close
This is the simplest change I could think of to fix this in a likely
This change could impact end users who click the reset link and for
referenced this pull request
Sep 23, 2016
I wonder whether you considered a CSRF-like approach, in which when the user requests to reset their password, the website issues a request validation token and store it in user's cookies. When the user clicks on the link contained in the e-mail, however, the password reset form submit action is accepted only if validation token is valid (or maybe they don't even get to see the form page).
Since the validation token would only be in user's browser, I think it wouldn't be possible for a malicious party to exploit possibly leaking
What do you think?
I hadn't considered that. It's an interesting idea. The only downside I can think of is that it means the user must use the same device and browser to request and complete the reset.
That's not a deal breaker for me but I think it's different enough from other reset mechanisms that it might lead to some confusion.
Are you aware of major sites or libraries that do that?
Not really, no. However, in my own usage, I have ever noticed anybody use the reset mechanism to open the web page from a different device/browser.
I think it is reasonably safe to assume that the actual password reset will happen in a minute or so (you usually need the password right now, else why are you asking for a reset anyway?):
I think we both agree that "security by obscurity" (that what most password resets do) is the real problem here. So a same-origin-like validation token could help a bunch.
I have asked for a reset and ultimately completed the reset on my phone, or vice versa. I have also requested a reset from Chrome (a browser I occasionally use for Flash), and completed the reset in Safari (my main browser I have my email open in all the time).
Those may be edge-casey enough though. This isn't a bad solution, I'm just not sure of its impact usability wise.
Haha, that is very interesting, and definitely is something that has never occurred to me.
Fair enough. The solution that I was suggesting has the upside of being "secure" at the cost of edge-casey bad UX issues.
The currently implemented solution of invalidating reset token as soon as the user clicks on the link has the upside of being cautious not using the same token twice; but the downside is, although very unlikely, the first person to hit that URL may not be the user themselves. Essentially it's "first-come, first-served". That's bad UX as well.
I don't have any data to backup however which of the edge cases are more unlikely to happen.
Here's another idea: why not asking for the user's email address again in the final password reset page? If the link with the reset token is leaked, chances are, only the user knows their own email, and not the third-parties.