If you develop web apps, don't do this.
sneak.datavibe.net
sneak.datavibe.net
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.
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.
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).
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.
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.
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.
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.
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.
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.
Try educating end-users on that one!
Now there could of course be ways around this like time/ip/geo pattern tracking, but that's no trivial enterprise.
However is it legal under the new EU cookie-act? I mean, after all, this is tracking outside of our website.
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.
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.
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.
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.
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.
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.
(That's a joke. I didn't even make the theme.)
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.
https://chrome.google.com/webstore/detail/oiaejidbmkiecgbjei...
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.
The convenience is tempting but it seems careless.
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.
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...
Allow immediate access for convenience in some cases, but restrict that access to a specific task until login.
Actually it requires one-click or two-click. And not for transactional emails.
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).
(If you use chrome, just prepend any URL with "cache:" instead of posting snarky comments about it :)
* 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.)
> 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?
It's SORT of a "thing you know" vs. "thing you have", except the email account is kind of also a thing you know.
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.
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.
It really makes me sad.
It also makes me angry.
I can just set a new password and then log in with it anyway. Don't make your users jump through hoops.
This is somewhat false. You should clarify your intention here.
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/
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.
It's obvious that a password reset link should not be forwarded, but a monthly newsletter?
(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.)
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.
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.
Most sites don't have any security questions.
And while it's true that many 'forgot password' forms use POST, there's really no reason for it. They could just as easily use GET 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.
"Or provide a single use single action token that performs one function, like confirm friend. Security doesn’t need to be all or nothing."
For extra security this token can be one time useable only.
The convenience factor is also superb.
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.
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.
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.
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?
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?
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.
There is no 'safest' way with encryption. It's a matter of time before it's breached.
Those of us that live in the Real World send our regards.
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.
But there's no safe way.
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.