Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sneak.datavibe.net

Post reply on HN
Print view View original

61–70 of 113 posts

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

#61

Post by danenania »

thirsteh wrote: post #60
danenania wrote: post #54

Earlier quoted context omitted.

This seems like a good compromise. Allow immediate access for convenience in some cases, but restrict that access to a specific task until login.

Yes, but the scope of access would have to be severely limited, to the point where's there's no real sense in doing it, e.g. you'd have to prompt for settings change, but also probably read/write access to private messages, wall, etc... It'd be a lot of work with little return (the more return, the less security).

Yeah, good points.

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

#62

Post by sneak »

zaidf wrote: post #59

Plentyoffish emailing you your password. OKCupid sending login token'd links Notice the trend? When you're a dating website, engagement trumps security in many cases. But if you are a bank or any service with some liability, you're probably going to play it conservative as you should.

"Engagement trumps security" holds true for 99% of the sites this audience builds. There's a reason I used Foursquare as an example.

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

#63

Post by thirsteh »

JoachimSchipper wrote: post #55
itcmcgrath wrote: post #44

Earlier quoted context omitted.

Not to also forget that if you have automagic login links in the email, you can no longer forward that email to anyone without compromising your account. Try educating end-users on that one!

Simple solution: put a persistent cookie on the computer of everyone who's ever logged in. Automatically log the user in if this cookie is present and the URL is correct. Obviously, the cookie should be unforgeable - e.g. HMAC-SHA1(service_secret_key, username).

This is the best approach to the problem, though it doesn't satisfy the implied(?) requirement that new devices should auto-authenticate seamlessly. You have to keep track of all of the cookies, of course, but there is comparatively little risk in letting previously authenticated machines (with an expired session) perform automatic login via a token in an email. The OP should point this out in his article.

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

#64

Post by badmonkey0001 »

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…

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.

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

#65

Post by DavidMcLaughlin »

The real point is: don't do two-level ACL on websites.

At my previous company we had these "auto-login" links in emails and they are extremely powerful.

But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we were getting absolutely ridiculous user engagement from emails because of this feature and this was too valuable to give up.

Before I left the solution I had started to push was to introduce a new intermediate user level - "logged in but not trusted" - to the standard logged out/logged in two-level ACL. The basic implementation would have looked like this:

1) A logged in but not trusted cookie is set on both manual login or auto-login from marketing materials. It allows us to assume that this is user X and they are taking action Y on website Z. It also allows the user to receive the user logged in view where that UX has been tweeked to minimise effort for logged in users.

2) A logged in and trusted cookie is only set on an explicit manual login, and is required to perform _any_ write operation as well as to read certain sensitive information.

Where the practical implementation gets difficult is you really need to refine when to require the trusted cookie - at what point in your UX - to keep the engagement high. It will almost definitely go down, you just want to minimise that.

For an example, say you're a service like LinkedIn. You send emails to your users whenever they get a private message and you want to make it easy as possible for that user to reply because recruiters getting candidate engagement happens to be one of your key metrics. User clicks on the message in their email and instantly gets a login page, they might have been 50/50 about engaging with this recruiter so now that you presented an obstacle they just close the tab and get back to what they were doing. Alternatively, you show them the message from the recruiter and allow them to type up a reply and only ask for a password confirmation when they hit send, and it's possible your engagement will go up.

It requires more thought and is surprisingly tricky to implement once you get past the really easy "read-only" versus "write" type security checks, but it seems to be the way things are going.

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

#66

Post by deno »

JoachimSchipper wrote: post #55
itcmcgrath wrote: post #44

Earlier quoted context omitted.

Not to also forget that if you have automagic login links in the email, you can no longer forward that email to anyone without compromising your account. Try educating end-users on that one!

Simple solution: put a persistent cookie on the computer of everyone who's ever logged in. Automatically log the user in if this cookie is present and the URL is correct. Obviously, the cookie should be unforgeable - e.g. HMAC-SHA1(service_secret_key, username).

The only situation you're targeting, then, is when a user intentionally logged out (in non-privacy mode) in the past (because otherwise they wouldn't have the half-cookie). Is it really desirable to log in them automatically in such cases? But then if they're clicking on the link in the first place, one might conclude that they desire is to log-in, so it's just added convenience.

However is it legal under the new EU cookie-act? I mean, after all, this is tracking outside of our website.

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

#67

Post by jsvaughan »

fullmoon wrote: post #37

What about auto-login info in the browser? If you present them with the login form (maybe with username prefilled), and they need to submit the form, they can update their autofill.

Exactly. If you use an auto login cookie then the browser will not have the password, so for the sake of saving a user a small amount of time you'll inconvenience them in the long run, and discourage them from using the site.

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

#69

Post by Joakal »

staunch wrote: post #17

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?

PGP-encrypted emails? It becomes a question of security vs convenience eventually with security considerations (Someone mentioned dating sites are more engagement > security).

There is no 'safest' way with encryption. It's a matter of time before it's breached.

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

#70

Post by thirsteh »

sneak wrote: post #32
thirsteh wrote: post #19

Earlier quoted context omitted.

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

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?
Post reply on HN