by andrenarchy on 10/24/16, 1:01 PM
If you use javascript to extract the token from the URL then you can simply pass it via the hash ("fragment") part of the URL. The hash portion is only interpreted by the user agent and never sent to a server (see
https://tools.ietf.org/html/rfc3986#section-3.5). This is how we solved it at paperhive.org.
by tvelichkov on 10/24/16, 1:31 PM
If you steal someones else password-reset link, change the password, then at the end of the day, won't you end up with a password, but missing email/username in order to log in? I mean the reset password link shouldn't reveal any other credentials about the account. (I know at some sites after reseting a password you may end up automatically logged in, but i think this is a bad practice).
by jpalomaki on 10/24/16, 12:30 PM
One option is to avoid putting the token to the link and at least provide user a simple way of copy-pasting the token to the password reset form.
Sometimes this is actually something I as user want to have, since it might be that I'm receiving the email on device A, but want to reset the password on device B.
And please keep the password reset tokens sane. If you are not encoding some data into the token, you don't really need that 80 character random string for security.
by moloch on 10/24/16, 12:26 PM
This is bad but not horrible, especially in the example given leaking the reset token to Cloudfront. The application is loading JavaScript from the Cloudfront origin, so that origin by definition could already read the tokens by modifying the JavaScript (assuming no SRI). The request is sent over SSL/TLS so the token cannot be viewed by a MITM, and referers aren't sent across HTTP<->HTTPS transitions.
Again this is far from ideal, but also not readily exploitable by attackers that couldn't already access the data.
by darkhorn on 10/24/16, 5:21 PM
What I do is I start a session on password reset page. I send an email with the reset link. User visits the link. The web page checks wheter the requester is same with the session identifier. Only then the user has a right to create a new password. So, in other words, if the user tries to visit the link with a different browser a warning says "use your browser that you used to reset your password".
by zaroth on 10/24/16, 4:57 PM
by kelvin0 on 10/24/16, 12:24 PM
I've read the article twice, and I'm not totally clear as to what the problem is, and how it's being addressed (web n00b here). Also, this bit:
"Browsers will not send the Referer for resources fetched via HTTP from a document loaded via HTTPS"
So using HTTPS resolves the issue? But breaks analytics?
Any further clarification would be nice, thanks!
by eterm on 10/24/16, 1:30 PM
For analytics this isn't a big problem.
Once a reset link has been clicked, it should be immediately invalidated.
So unless the server was able to respond to the link and provide the analytics stuff but not somehow invalidate the token, I can't see how this is a problem.
Another related problem is that some third party mailers move all their links via URL redirectors. In that case there's a chance the host application fails and the link is left valid.
by Normal_gaussian on 10/24/16, 1:32 PM
So the fragment solution requires JS, invalidate on request can be upset by email scanning antivirus, manual token entry is inconvenient.
So my first thought is returning a page with no external requests (render on the srrver) which isn't very dev friendly.
My other thought is returning a redirect to a page with a token derived from the original token and the clients IP or some other fingerprinting information.
by r1ch on 10/24/16, 12:20 PM
by zokier on 10/24/16, 12:53 PM
Would putting the token to url fragment id resolve the issue? I suppose the downside would be that then js is required on the reset page. But that is fairly minor imho.
by marichards on 10/25/16, 8:40 AM
by milankragujevic on 10/24/16, 6:11 PM
Does anyone have a list of common vulnerabilities that you should check your app against, maybe excluding the obvious ones like SQL Injection, XSS, etc... ? Because I can't keep track of all the vulnerabilities that exist in the world :(
by pacifika on 10/24/16, 12:26 PM
The problem is that your password reset token shouldn't be reusable. The token is only leaked after the person visited the reset page, which should invalidate the token on load.
Without a valid token, the reset form shouldn't load. Problem solved.
by garglgarbl on 10/24/16, 2:19 PM
I'm a bit of a web noob as well, so I have a related question:
If I have an https url with a token will the token only be sent through the https connection or is it contained in any lookups or connection metadata or such?
by zeveb on 10/24/16, 4:04 PM
He should have also considered the option of not loading third-party assets and analytics on password reset pages.
I'm grumpy enough to suggest not loading them period, but I'm a curmudgeon.
by Lord_Zero on 10/24/16, 5:29 PM
by jccc on 10/24/16, 3:45 PM
Anyone here happen to know how Basecamp works? They seem to be comfortable with emailed login links, no username or password.
by agotterer on 10/24/16, 1:10 PM
Why not have a URL that identifies the reset request uniquely but also requires a code that is entered manually?
by homakov on 10/24/16, 3:51 PM
There's absolutely no situation when it's a risky behavior. It is not a problem at all.
by mmanulis on 10/24/16, 3:51 PM
Why not pass the token as an HTTP header? e.g. X-RESET-TOKEN=foo and then read that via JS