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.
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.
... and it feels really natural. Amazon identifies me easily, but if I do anything that feels like I need my password, it asks for it. Apple's App Store has similar logic, although it bothers me in one place where they ask for your password when downloading free apps.
And then there's Windows Live. Click on anything remotely related to Passport? You need a password (followed by 17 redirects, which is hilarious when managers have sound turned on and you here the "click click click click click" as IE bounces around).
followed by 17 redirects, which is hilarious when managers have sound turned on and you here the "click click click click click" as IE bounces around
I wonder if someone added a few extra redirects just for that reason. Seems like a quick and easy way to remotely identify coworkers that don't customize or disable their sound scheme and use IE.
I saw one of Amazon's UX team at a talk a while back, and the way he described it is they have a set of actions/permissions for people who are totally logged out, a set for people who are "sort of logged in", and then a set that require full login.
It's definitely tricky to implement (how do you determine whether a user is "sort of logged in"?), but once you get over the conceptual hurdles it's a pretty awesome user experience.
However, I would argue that like much of what Amazon does, it's not necessarily appropriate for the majority of sites.
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.
A good take-away from this might be "don't do two-level ACL until you have user traction".
DavicMcLaughlin says, "we were getting absolutely ridiculous user engagement..." When you are starting a site, you want as little resistance to usage as possible, and this helps with that. It makes it one step easier for people to use your site. It helps reduce the typical chicken/egg problem, or any other "it's hard to get users" problem.
Once you have the users, and security becomes more of a concern ("But security should always be a concern", yeah I know.) then you should start to think about something more secure. Until then, do all you can, within reason, to get users.
> Once you have the users ... then you should start to think about something more secure. Until then, do all you can, within reason, to get users.
Worked well for Sony!
Seriously, that is an egregious abuse of both ethics and morality, the latter because you are implicitly abusing your users' trust (unless your welcome screen says "NOT YET SECURE" in huge font). If implementing reasonable security before you enter beta testing is such a resource burden that your product will go under before it can get its footing, then your product goes under. Ethics do not go away when your profitability and success are on the line -- that is the specific moment when ethics come into play.
I realize you have already thought through this and have a different POV. Newbies are liable to see this kind of talk however, and think it is an accepted industry-wide practice to treat security as an afterthought until you have scaled, when that is in fact a profitable but unacceptable antipattern.
P.S.- This is like a new small-town restaurant saying "Refrigerators are expensive, so we can't afford to refrigerate our eggs and milk until we get more customers. Otherwise we might go under from the increased operating cost, and then our customers wouldn't get to enjoy our restaurant!" Draw your own conclusion.
I think you're overblowing his point a little, and attacking a straw man. I don't think he's talking about not-using-refrigerators/storing-passwords-in-plain-text type of insecurity, just worrying less about loopholes that are non-critical and unlikely to be exploited anyway until you have lots of users. He did say "within reason".
Here are two suggestions that we would have seen, if the underlying assumption was not that {increasing the derivative of user count per day} justifies {poor security}:
1.) Implement bulky external security measures -- like client-side certs or VPNs -- and replace them with more scaleable solutions as the user count grows.
2.) Inform your users that they are interacting with an unsecured fledging service, such that they do not have an expectation of privacy. At the very least, warn them not to use this service on an unsecured coffee-shop WAN.
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 system, someone that has access to my email (even for a short time) might get continued access to my OKCupid account. I won't know that they have access. With Foursquare, someone who has access to my email can get access to my Foursquare by using the forgot password system. However, when they reset my password, I won't know the new password and there's a decent likelihood that I will realize that someone has broken into my account.
With the forgot password system, it's easy to expire that token as soon as the password is changed. 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. In one case, there will be a URL in my history with the token and if someone is smart, they can just try typing in okcupid.com/l in my browser and wait for the autocomplete with an auto-login token from my history. With the forgot password system, it will be in my history, but it will have expired when I changed my password. So, even if I've signed out of my email and okcupid before letting a friend borrow my computer, there will still be an auto-login token in my browser history that can be exploited.
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.
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.
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).
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.
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.
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.
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.
> 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.
> 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.
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.
Joke or not, I have to point out that just because someone's screen resolution is 2560x1600 doesn't mean they have their browser that huge. Personally, my browser is never wider than 1100px. I do usually go as tall as the screen, but on a small laptop...
Mobile version didn't kick in on iPad, which doesn't do CSS position: fixed, so the footer ends up hiding some of the text, and makes the site unreadable.
Even #newtwitter gets this wrong. Space jumps down a page, all right, but one of the unread tweets hides behind the black header.
I haven't looked into this, but if anyone has a fixed position header on their project, they should look into overwriting the space bar action readability-style and calculating how far to jump down.
If you want to do this, at least make the login cookie expire at the end of the session.
I had a friend forward me an OKCupid e-mail when they sent mis-matches for April Fools - a few days later I realized that I had somehow been logged in as said friend and was majorly creeped out. Had I been less mature about it there was major potential for trolling said friend - particularly on OKC.
Mistakes like this will inevitably occur even with a cookie that expires as you suggest. Not as often as with a non-expiring token, but there are plenty of people who will leave a browser tab up for days at a time, keeping the session alive.
The convenience is tempting but it seems careless.
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.
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.
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).
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).
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 user to enter their password to access sensitive settings or data (like changing email, passwords, etc.)
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" feature work?
Please don't act as an authority on security when you do not understand how something like a POST request works.
What you're encouraging is forfeiting the site's accounts in standard communication, of which you send many, many more than "Reset your password" emails (which should, but may or may not be triggered by a form that presents at least one security question), and which are fundamentally different than "account security" emails, for the sake of streamlining the user experience, i.e. saving the user from having to log in at all from new devices.
If any users forward any of these mails to anyone else, they've essentially given them complete access to their account--imagine if Facebook started doing that in their "You've received a new message". It's needlessly and inconspicuously compromising account security on a regular basis with no real win. (The idea wouldn't fare well in a proper risk evaluation.)
This my first thought upon reading the article. If people designing websites are making decisions that are not really well thought out (like this), episodes like Sony will continue to happen.
> I guess I am being insufficiently clear about why this is no less secure than what exists today.
Because it sounds scary really. But if someone aiming to take over an account already has access to the account's email inbox then forcing the user to reset their password immediately is no hurdle, it inconveniences a legitimate user (however briefly) more than a malicious user.
However, I am still not in favour of an immediate auto-login without a password reset beforehand (as there is a need for the user to update their password). Since we've already 'verified' that the user at least has access to their email (so it is probably them) I don't see anything wrong with automatically authenticating the user after this though.
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.
They both change the password, thereby granting access to the account. The security issue is really just the true stupidity of "sending password reset links via unencrypted email" - but it's already the standard so we can leverage that to offer auto-login links at no extra charge.
That's true but with reset password links you can force the user to do extra work, like enter a CAPTCHA or answer a secret question. That should prevent bots from scraping and compromising accounts on a large scale.
Whoever downvoted me is apparently unaware of encrypted protocols like SMTP w/ TLS (which most major webmail providers use) and IMAP (which is increasingly preferred over POP3).
IMAP is an unencrypted protocol (as well as SMTP and POP3) in the same regard that HTTP is not HTTP + SSL. All three mail protocols can be wrapped nicely inside SSL/TLS, but it is only point to point encryption.
If I connect to my SMTP server over TLS and send you a message to your server, I cannot guarantee that your SMTP server is listening on the secure ports, let alone serving IMAP or POP3 over SSL to your client, which can be intercepted. Never mind the fact that 45%+ of all mail servers are storing these messages in plain text in /var/mail/
IMAP is an unencrypted protocol (as well as SMTP and POP3) in the same regard that HTTP is not HTTP + SSL. All three mail protocols can be wrapped nicely inside SSL/TLS, but it is only point to point encryption.
This is true, but most major providers only offer IMAP over SSL IIRC.
If I connect to my SMTP server over TLS and send you a message to your server, I cannot guarantee that your SMTP server is listening on the secure ports, let alone serving IMAP or POP3 over SSL to your client, which can be intercepted. Never mind the fact that 45%+ of all mail servers are storing these messages in plain text in /var/mail/
True but once again I think all the major email providers use SMTP over SSL.
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?
"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.)
> "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.
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?
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).
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.
I think this could be done safely (well just about as safe as sending forgotten password reset links):
1. Set a short expiry date on the link (1 day).
2. On first click within 1 day, log user user in and expire link. Ask user if they want to stay logged in (via a subtle overlay at the top of the page perhaps + set "remember me" cookie)
3. On subsequent clicks within 1 day. If user has "remember me" cookie, log them, otherwise redirect to login screen.
4. Clicks to link after 1 day. Redirect to login page.
This should be just about as safe as a forgotten password email; they both have an expiry period + 1 time use, meaning anyone intercepting the email before the expiry and before the user clicks on it can impersonate the user.
The only counter-point that I'll make against my own point is that a forgotten password email is sent on demand, i.e. a user requests it, so they are probably more likely to click it immediately (hence expire it immediately).
I wouldn't do this for an e-commerce or otherwise sensitive app, but for something a bit more casual I think it would ok.
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.
This is the way to go imo. For some reason a lot of people have the idea that it's somehow more secure to build your own login system than it is to use Google's or Facebook's. But doing it yourself opens up new vulnerabilities and you'll be reinventing the wheel making all the mistakes that have been tested out of veterans' systems.
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.
Traditionally if an account reset email is sent out you didn't trigger, it's a huge red flag. With this proposed approach, especially on a location based service like foursquare, getting access through a sniffed seemingly harmless notification email would most likely go unnoticed.
The closest method to this I'd personally implement is a toggle option only, with no further access. Similar to a standard unsubscribe toggle link.
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.
It seems like this calls for a two-pronged approach. If you've been logged in to their site from that browser in that account, then the link from the e-mail should auto-log in (unless it's been disabled for that account). Otherwise, it should prompt to allow an actual login as usual.
This way, you can forward an e-mailed link, and unless they happen to have logged as you already, they don't get into your account.
This probably means a significant amount of attention to detail to exactly which cookies are set, how long they live, and what they mean, but it sounds worth the effort.
I'm not sure if I can totally agree with the author. I understand his pain, but email isn't the most secured place. If your email is being "watched" by someone else, then that someone else can access other web services that you own WITHOUT requiring to type passwords! I know that it is very rare to have your email being watched, but in security, even the most rare case should be taken into consideration. It's a trade off between user experience and security. This is something you find very often in software engineering.
> If your email is being "watched" by someone else, then that someone else can access other web services that you own WITHOUT requiring to type passwords!
The person watching your email can ALREADY DO THAT NOW by clicking on the "I forgot my password" link, intercepting the reset email, and then setting a new password and logging in.
That assumes someone has live access to your email. If someone has a recent enough dump (or simply a mail you forwarded yourself, because you didn't understand the security implications), then the "forgot password" button does really provide more security than login tokens inside the URL.
After reading the article and comments, it appears that what this really represents is a need for more secure email protocols. How would one go about creating and ensuring and end-to-end secure email protocol? It could be done within a domain, but once you send or receive messages outside of your domain it's up to the intermediate and end parties to keep the message secure.
I suppose you could ensure secure communications via encrypted messages and end-clients with the key, but how could such a system be ubiquitous and practical?
There's no safe way. As soon as you start sending tokens that grant complete control over the account in normal/regular emails, you've reduced the account's security.
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 it sounds like it should be.
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.
For example, Canonical's Launchpad requires you to sign "code of conduct" with your GPG key before doing certain actions. And, if I remember correctly, they do send GPG encrypted emails for key ownership verification.
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.
I would use the same implementation as a password reset token - generate a hash and store it with a time-to-live - but I would probably be less lenient with the TTL (although as has been discussed, not for any real good reason).
This is a compromise in security, and it should be seen in the context of the application/domain. I don't think it would fly in the medical or financial world.
That's what http://www.yourpane.com uses, so that when someone sends you a link you don't have to enter your password to use it.
As a matter of fact, it forgoes passwords altogether, using a secret token to log you in. It also creates an account as soon as you send a link to a friend, so there's no explicit account creation either. This is done to avoid the obvious hurdle, as it allows you to send links to your friends without them having accounts already.
A lot of issues like this will be overcome with iCloud's ubiquitous kay-value stores, but sorry those are native apps. This points out yet another way how the web is a broken platform.
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.