Hacker News Reader

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!

Yep, this alone is a borderline fatal flaw. The practice of sharing links, whether done intentionally or unintentionally through email forwarding, is pervasive and people won't stop to think about whether the url contains an embedded login token. This practice opens up a new class of vulnerabilities in the human error realm.

Now there could of course be ways around this like time/ip/geo pattern tracking, but that's no trivial enterprise.

And not without their own set of flaws either.

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.

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.

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.

You could also pixel-track the email, and only allow in the first IP address.

However, that falls over with people who have Display Images turned off AND don't click through to the website before they forward it. But if you HAD to do this feature, it would help a little.

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

It's getting upvotes because the title says "don't do this". People are voting for the fact that the article is offers bad advice. The author however doesn't seem to have quite grasped this - thanking us for his position on the HN front page!

No, the main article has the same title. The author seems to mean: "don't make me log in after I click on an email!". It is clearly bad advice but HN often seems to vote on confidence of delivery.

I upvoted it for the value of discussion in the thread than for the article itself. :)

> With the instant login system, you can't expire the token after its first use since the email will still be in the user's inbox where they expect it to work.

As the article mentions, you can expire them after a week or so. And if you're smart enough to do this, you're smart enough to fall back gracefully to the old "login form" behavior when you get a link with an expired token.

Hell, you could expire them as soon as they are clicked, and then have the fallback.

An immediate expiry would not solve the initial problem. A user can easily click on the link on an iPhone, then want to read the content on his desktop. A timed expiry would work much better.

Another trick is to mix in the user's hashed password when you generate and check the HMAC - that way if the user ever changes their password all the previous links fail to work.

> The reason so many sites prompt for password is for security

I doubt it. I think the reason has more to do with what their framework or authentication scheme supports or how rigorous they are with user engagement.