
If you develop web apps, don't do this. - sneak
http://sneak.datavibe.net/20110614/please-dont-do-this/
======
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.

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

~~~
Splines
... 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).

~~~
nitrogen
_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.

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

~~~
itcmcgrath
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!

~~~
JoachimSchipper
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).

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

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

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

------
Legion
If you create a blog, don't use fixed headers and footers that take up half a
netbook's screen.

~~~
sneak
Sorry, I design for 2560x1600. I don't want poor people reading my site.

(That's a joke. I didn't even make the theme.)

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

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

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

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

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

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

[1] [http://blogs.boomerang.com/blog/2009/06/16/can-
spam-2008-uns...](http://blogs.boomerang.com/blog/2009/06/16/can-
spam-2008-unsubscribe-provisions/)

~~~
thirsteh
You can use such tokens to disable email notifications, and still not provide
complete access to the account, though.

~~~
danenania
This seems like a good compromise.

Allow immediate access for convenience in some cases, but restrict that access
to a specific task until login.

~~~
thirsteh
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).

~~~
danenania
Yeah, good points.

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

------
unicornporn
Do what? Create database driven sites that can't handle the load? I get error
messages or timeouts when trying to reach the site.

~~~
wahnfrieden
Cached copy:
[http://www.google.com/search?sourceid=chrome&ie=UTF-8...](http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=cache%3Asneak.datavibe.net%2F20110614%2Fplease-
dont-do-this%2F)

(If you use chrome, just prepend any URL with "cache:" instead of posting
snarky comments about it :)

~~~
sneak
Thanks for that. My poor old p3 personal page box just about imploded when
@newsycombinator tweeted this...

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

~~~
sneak
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?

~~~
thirsteh
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.)

~~~
itcmcgrath
I wish I could up vote this all day.

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.

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

------
thirsteh
"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.)

~~~
sneak
> "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?

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

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

Most sites don't have any security questions.

~~~
thirsteh
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?

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

------
irfan
Someone commented on the original post:

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

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

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

The convenience factor is also superb.

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

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

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

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

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

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

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

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

------
dkokelley
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?

------
staunch
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?

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

~~~
sneak
PGP encrypted emails? Are you serious?

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

~~~
drdaeman
Unless your general audience are hackers.

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.

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

------
radicalbyte
:facepalm: you don't happen to work for Sony, do you?

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

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

------
buchin
Down here

