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

71–80 of 113 posts

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

#71

Post by JoachimSchipper »

deno wrote: post #66
JoachimSchipper wrote: post #55

Earlier quoted context omitted.

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…

Lots of people "log out" by letting their session expire; this would merely get them back in the game faster.

I'd expect this to be legal - set the cookie on login.mydomain.com and never use that domain name for anything else - but IANAL.

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

#72

Post by sssparkkk »

mdasen wrote: post #36

The reason so many sites prompt for password is for security. Yes, they will also send you an email with a link to reset the password to the same address. However, the difference there is that you will know if someone has changed your Foursquare password and the token used to allow for a password change can be expired immediately after the change takes place rather than offering continued access. With the OKCupid sys…

> I'm not saying that there aren't low-security services where this convenience is good. It's more that the author hasn't taken into account that there is greater security in the forgot password system.

Exactly. And I think it's somewhat dangerous for the author of the article to not understand this important distinction and at the same time advise creators of web apps to implement this behavior.

Judging by the amount of upvotes for the article and the comments it has been getting, I'm afraid some of us will simply follow his advice and replace reset password emails with direct login links.

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

#73

Post by eli »

You should definitely NOT be putting auto-login links into every email without very careful thought and planning. People routinely forward emails to their friends and colleagues, or copy links and post them on twitter.

It's obvious that a password reset link should not be forwarded, but a monthly newsletter?

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

#74

Post by eli »

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?

I would also make each link only auto-login at most once per message (or maybe once per week across any message). You could also make the auto-login fail if any images from the message have previously been loaded from a different IP.

But there's no safe way.

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

#75

Post by StavrosK »

StavrosK wrote: post #25
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?

A good way I can think of is to include a user's secret (hashed password or whatever), HMACed with the number of the week. This way, the token expires at the end of the week. There would be a problem with links sent late Sunday, but I guess you could always try verifying with the previous week's number as well. Of course, I'm not sure if this is faster than storing random tokens in the database and expiring them, but…

So, uh, why the downvotes with no comment?

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

#76

Post by StavrosK »

Joakal wrote: post #69
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.

So, the one with the most time before it's breached is the safest.

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

#77

Post by LiveTheDream »

DavidMcLaughlin wrote: post #65

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

The not-fully-trusted user paradigm is actually pretty common in websites for changing your password (enter old password, new password, and new password confirmation). The main reason, as I understand it, is to limit the damage made possible by session hijacking.

Session hijacking and the wrong person auto-logging in are actually the same thing on a technical level; the difference is semantics. In both cases, a logged-in user is not the owner of the account.

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

#78

Post by sneak »

Joakal wrote: post #69
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.

PGP encrypted emails? Are you serious?

Those of us that live in the Real World send our regards.

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

#79

Post by deno »

JoachimSchipper wrote: post #71
deno wrote: post #66

Earlier quoted context omitted.

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…

Lots of people "log out" by letting their session expire; this would merely get them back in the game faster. I'd expect this to be legal - set the cookie on login.mydomain.com and never use that domain name for anything else - but IANAL.

> Lots of people "log out" by letting their session expire; this would merely get them back in the game faster.

I'd expect, that someone that is going to employ auto-login URLs, is not going to be shy in using ‘forever’ login cookies anyway.

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

#80

Post by unshift »

DavidMcLaughlin wrote: post #65

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

amazon does that. you can browse the site and it identifies you and your preferences, but when you go to check out or modify account settings, you have to enter your password.
Post reply on HN