Instant login from email. Why have so few done this?

Question

Tried searching for this but turned up nothing. Discussion or relevant links are requested.

Suppose we are going to send an email to entice a user to login to our super social webapp. The goal of this email is to get them to return to the site and poke around a bit more before they forget us so naturally we want to lower the barrier to them returning. Cookies help in preventing them from needing to log in every time but still don't help in the case when the user has forgotten their credentials. We want instant gratification here--one click straight to the action baby. Instead, why can't we just send the user a hashed form of a randomly generated, time-sensitive token that we have stored in the DB? If they can supply this token back to the server then we can we trust their identity.

This scenario seems like it could be secure, as long as you managed the tokens correctly. The process would be something as follows:

1. Before sending the reminder email to John Doe, generate a random number token (a large enough number to prevent guessing) that expires after a few days.

2. In the email, include a url that contains a hashed form of the token (perhap xor with the user's ID).

3. When John Doe logs into his email and clicks on the link, the server verifies the existence of the token in the DB and that it isn't expired. If the token exists, he is automatically logged in by the server.

Security: We assume that the email for John Doe actually belongs to John Doe, if only because email addresses are verified as part of the registration process. Any user that has access to John Doe's email would be able to access his account; however, this isn't new. Many sites already assume that the user's email account is secure because they implement the feature to reset password to email.

My googling has turned up only one site that does this, OKCupid, which is an online dating site. Does anyone know of any other sites that do this? Why isn't instant login via email more common? Security? Lack of substantial benefit for the added complexity?

Solution 1

On some sites you can separate the "important stuff" from the "really, really important stuff". Let's say that the "important stuff" on your site allows users to view policies, active members and incoming group messages. The "really, really important stuff" allows you to change policies, reset passwords and add new users. So what you can do is as follows:

1. Allow your http link to give access to the "important stuff". After all, it's not the end of the world if people know about policies, users or messages in your system.
2. Request an actual username/password authentication if a request is made for the "really, really important stuff".

In essence you are building different trust levels within your system. The emails you send outbound to entice users are almost always for innocuous activities ("hey, check out the new widget we have added"), and if people wish to stay on the site then they won't mind the extra time for authentication.

Solution 2

If the user forwards the e-mail to a friend for any reason, then that friend could log in as the user.

Solution 3

Emails are not secure.

You cannot assume that the email won't be seen in transit, and you also cannot assume that the user will read the email over SSL (especially if he's using a webmail client)

Password reset via email typically (hopefully?) requires a second factor - the security question.
You wouldn't have a security question.

Solution 4

Many websites let users recover their passwords through email verification. Your idea isn't much different, but:

1. If a user isn't logging into your site by following a link on SSL, then your key is being passed around unencrypted and can be hijacked through packet sniffing.
2. You said that the token you'll generate will expire in a few days. The long expiration time will make you more vulnerable to session hijacking. Tokens created for password recoveries usually expire in under an hour.

Solution 5

Lea Verou has an interesting idea on that:

This feature could be activated only if the user in question was inactive for a while. Frequent users don’t need it that much and even if they did, they don’t run away so easily, so it’s not as crucial.

Source: http://lea.verou.me/2010/08/automatic-login-via-notification-emails/

View more solutions

Comments

[Michael Todd]

Will you be using a secure connection? If not, packet sniffing could be an issue.

[Tom Anderson]

As an example of the instant login, OkCupid sends links like okcupid.com/l/…. If anyone clicks on it, they are logged into this account.

[user207421]

What evidence do you have that 'so few have done this'? I see it everywhere.

[Tom Anderson]

If the server responds to the token login by immediately issuing a cookie and a redirect to the same URL minus the token, there's no danger of referer leakage. Since the token has a limited lifespan, the cache and log arguments don't really apply.

[Tom Anderson]

The point is that it's no less secure than a password reminder email. Not secure, but evidently secure enough for many sites!

[Tom Anderson]

It's quite common for sites to do this even for normal logins; if you want to change sensitive stuff, you have to enter your password again there and then. Which i think is what you're saying anyway. Either way, it's a good point.

[Tom Anderson]

Some sites do password reminders over email. No second factor. Arguably, this is a terrible idea and they shouldn't, but it's at least not unheard-of. For infrequent users of social networking site, as in this case, it doesn't seem like a terrible security risk.

[SLaks]

@Tom: That is an abominable idea (storing passwords in plain text). I avoid such sites like the plague.

[Alan Jones]

OpenID/OAuth is important also, but I have a gut feeling that alot of users don't feel comfortable enough with those systems to use them on a whim. Or, in other words, though users may know how to use them, and the number of clicks would be the same, the perceived difficulty is actually higher.

[Tom Anderson]

abominable is an entirely accurate way of describing it!

[Tom Anderson]

@Alan Jones: interesting point. Perhaps i'm seeing the world through nerd-tinted glasses.

[Alan Jones]

By password reset to email, I meant that they provide you with a link via email by which you can reset your password. There's no plain text password involved here.

[SLaks]

@Alan: Unless you require a security question after clicking the link, anyone who intercepts the email can change the password.

[Francisco Caviano]

I actually think there's much more on that post than what you've quoted. Lea writes also about the pros, which should be also considered and in the comments section very good ideas appear on how this just depends on context and with a few measures place like preventing access or asking for password to go to more private data and expiring the token, it would't be less secure than the actual "Remember password' button that almost every website has nowadays. Anyway +1

[Ron Burk]

Or just different-tinted glasses. I refuse to ever click on any of those OpenID/OAuth login links because I do not want to leak any positive indication that I have an account on any particular service. Also, refusing to click on them was trained in to me by how many times somebody wanted "additional" privileges -- just knowing they could ask for more permissions instead of just confirming I am me amplified the creep factor for me.

[ORyan]

If it's a nonce and is reset or invalidated as soon as the user uses it, then there really is no issue. By the time someone else sees the token, over the network, it's already been invalidated. I suppose it doesn't really protect against man in the middle... but neither does a password.