If you develop web apps, don't do this. • Hacker News Board

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

#11

Post by yread » Tue, Jun 14, 2011, 7:17 AM UTC

sneak wrote: post #5

thirsteh wrote: post #2

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

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

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

#12

Post by wahnfrieden » Tue, Jun 14, 2011, 7:34 AM UTC

unicornporn wrote: post #10

Do what? Create database driven sites that can't handle the load? I get error messages or timeouts when trying to reach the site.

Cached copy: http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3...

(If you use chrome, just prepend any URL with "cache:" instead of posting snarky comments about it :)

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

#13

Post by yaix » Tue, Jun 14, 2011, 7:40 AM UTC

Legion wrote: post #4

If you create a blog, don't use fixed headers and footers that take up half a netbook's screen.

Just wanted to comment the exact same thing. And netbooks still have a big screen compared to many phones.

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

#14

Post by acron0 » Tue, Jun 14, 2011, 7:42 AM UTC

I for one will not be adding this feature to my web app. However, might it be possible to kick in a login process using OAuth/OpenID? The onus isn't then on you to validate the user.

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

#15

Post by jpalomaki » Tue, Jun 14, 2011, 7:44 AM UTC

How about two states for authentication: "light" and "fully authenticated"

If I click to the site via link in email, I get to "light" mode. This allows me to see things. Other actions can require "fully authenticated" mode and the transition light => fully requires me to enter my password.

With password reset emails I'd like to have a basic security question (one that I can pick myself).

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

#16

Post by randomwalker » Tue, Jun 14, 2011, 7:46 AM UTC

The funny thing is that CAN-SPAM mandates 1-click opt-out, and requiring login to unsubscribe is specifically prohibited.[1] So most websites already have code to include and verify auth tokens in emailed links, which they utilize when they are mandated to.

But somehow they haven't figured out that it is in their own interest to do so the rest of the time.

[1] http://blogs.boomerang.com/blog/2009/06/16/can-spam-2008-uns...

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

#17

Post by staunch » Tue, Jun 14, 2011, 7:49 AM UTC

What's the safest way to do an instant login like this?

First thought would be to encrypt a query param with necessary info and add a few day expiration on the link.

Any good articles on doing this as intelligently as possible?

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

#18

Post by nick_lewis » Tue, Jun 14, 2011, 7:49 AM UTC

Huh, I was just thinking about this the other day, and wanted to rant about it but never got around to doing so. It's extremely annoying when I land on a login page from an email when I clicked to take a specific action. ESPECIALLY when logging in takes me to the home page, and not even to my intended destination.

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

#19

Post by thirsteh » Tue, Jun 14, 2011, 7:49 AM UTC

sneak wrote: post #3

thirsteh wrote: post #2

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

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

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

#20

Post by nick_lewis » Tue, Jun 14, 2011, 7:53 AM UTC

sneak wrote: post #8

underwater wrote: post #7

A good idea for some situations. There are some obvious caveats: * Remember email is not encrypted. The links can be intercepted. * Consider looking at other factors (like IP, browser data, persistent cookies) that will let you know the user is legit before you green light the auto-login. * Link to HTTPS, not HTTP. The user might be on a shared computer and you don't want login-able URLs left in the history. * Force…

The "click here to reset your password" links are sent over unencrypted email, too. I guess I am being insufficiently clear about why this is no less secure than what exists today. > Force the user to enter their password to access sensitive settings or data (like changing email, passwords, etc.) If they have to enter their password to change their password... then how will the "click here if you forgot your password…

There's a difference between those two features. Changing the password requires entering the old password and entering the new password, so you're authenticating them via their password. Resetting the password requires sending a link to an email account you know they own, so you're authenticating them via their email account.

It's SORT of a "thing you know" vs. "thing you have", except the email account is kind of also a thing you know.