"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.)
> "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?
> 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.
Yes, 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.
Even 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?
Also, 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).
POST 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.
(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.)