If you develop web apps, don't do this.

Re:If you develop web apps, don't do this. by thirsteh on Tuesday June 14, 2011 @02:31AM (#2652001)

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

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by sneak on Tuesday June 14, 2011 @02:51AM (#2652036)

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

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by thirsteh on Tuesday June 14, 2011 @03:49AM (#2652150)

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

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by sneak on Tuesday June 14, 2011 @04:04AM (#2652189)

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.

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by thirsteh on Tuesday June 14, 2011 @07:07AM (#2652531)

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?

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by sneak on Tuesday June 14, 2011 @02:53AM (#2652042)

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

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by yread on Tuesday June 14, 2011 @03:17AM (#2652093)

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

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by sneak on Tuesday June 14, 2011 @04:10AM (#2652207)

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

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by badmonkey0001 on Tuesday June 14, 2011 @06:00AM (#2652397)

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.

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by stcredzero on Tuesday June 14, 2011 @09:34AM (#2652871)

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

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by roel_v on Tuesday June 14, 2011 @04:02AM (#2652184)

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.

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by sneak on Tuesday June 14, 2011 @04:09AM (#2652201)

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

[ Parent | on HN ]

Re:If you develop web apps, don't do this. by thirsteh on Tuesday June 14, 2011 @04:19AM (#2652230)

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

[ Parent | on HN ]