Hacker News Reader

Comment by thirsteh | Hacker News Reader

"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.)

View on HN

> "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.

Most sites don't have any security questions.

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).

You can just make the link go to a page "Do you really want to reset your password?" with a POST form

It already goes to a "type your new password in twice" POST form. That's not the point.

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.

Properly implementing hashed passwords with challenge-response will protect your login, though your session information can still be sniffed.

Using 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.

Variables in GET requests are stored in the history as part of the URLs. Variables POSTed are not.

And any access logs (from edge proxies, etc.), yes.

Reply on news.ycombinator.com