4 ms·
"Forgot your password" requests usually POST to the web server, not GET (what's usually used in emails). Sending links that give you complete control over the a
by thirsteh 15y ago
"Forgot your password" requests usually POST to the web server, not GET (what's usually used in emails). Sending links that give you complete control over the account by default seems like an extraordinarily bad idea--as does allowing users to reset their accounts without any kind of identity verification.
(You could do a POST from an HTML email, but then, in most email clients, the users would be prompted with "You are sending data to the web page. Do you want to continue?" every time they click such notifications.)
- sneak 15y ago> "Forgot your password" requests usually POST to the web server No they don't. They usually just have some sort of password reset token as part of the query string for a standard GET. AFAIK there isn't any good way to POST from the body of an email - do mail readers even do JavaScript?
- thirsteh 15y ago> No they don't. They usually just have some sort of password reset token as part of the query string for a standard GET. AFAIK there isn't any good way to POST from the body of an email - do mail readers even do JavaScript? I think you misunderstood what I was saying. "Forgot your password" requests, as in requests that will lead to the user receiving a new password/ability to reset their password, are usually POST, and are usually on a webpage, not in an email. Besides, POST requests aren't Javascript. It's perfectly possible to use from inside an HTML email. Usually, though, the most you'll provide in an email is a link (GET request) with a param identifying the user, e.g. the UID, that will lead to a form that asks at least one security question. Sending out links that essentially unlock the user's account via email by default seems incredibly risky to me, and only provides a minimally better user experience. Just do better session persistence -- then the worst thing that can happen is you need to log in once via your mobile phone.
- deleted 15y ago[deleted]
- sneak 15y agoYes, but after they get that email, there is a second part to the password reset process - generally that user resetting the password (if one is not auto-generated). That uses a single-use token in the GET request to load the "type in your new password" form. The new password is then POSTed. Dumb sites then require the user to type it in a third time to log in, "smart" ones log them in when doing the update operation. Most sites don't have any security questions.
- thirsteh 15y agoEven so, you're essentially arguing that equivalent access should be embedded in every email the user receives from the service. Is that worth the small, one-time (session is generated, or password manager remembers the password) improvement of user experience?
- sneak 15y agoAlso, that's the core of my argument - the "click here to reset your password" link that is sent, on command, is a link that gives you "complete control over the account" without identity verification (other than your email box).
- roel_v 15y agoUsing POST over GET does not make anything more secure, if I'm understanding your point correctly. And while it's true that many 'forgot password' forms use POST, there's really no reason for it. They could just as easily use GET links.
- badmonkey0001 15y agoPOST can be sniffed and is only slightly less vulnerable than GET. HTTPS at a dedicated address should be a minimum level of security for a login form. Anything else is readily vulnerable to sniffing or spoofing.
- stcredzero 15y agoProperly implementing hashed passwords with challenge-response will protect your login, though your session information can still be sniffed.