Is it a bad idea to automatically log users in from an email?

Question

For many of the sites we develop, we verify the user's email address. Typically the workflow is such:

1. User registers for site (activation email is sent with link to activate)
2. User verifies email address (by clicking aforementioned link)
3. User must log in to site in order to use it (assuming they weren't already logged in)

Clients often complain about this process being clunky and somewhat confusing, and I agree. The proposed solution is to remove step 3 and automatically log the user in after step 2.

I'm not sure if it matters (hence the question!), but I've always been wary of automatically logging a user in like this. What extra security risks should I consider before implementing the suggested solution?

This also applies in situations like password resets, where the user might be logged in automatically and then made to change their password.

For the sake of this question, let's assume that verifying the email is a hard requirement. I'm aware that there are situations where this isn't necessary, but let's talk about those where it is.

Answer 1

It depends on your application. You would never do that if you were running a banks website. You might do that if you were running a site like Flickr, Facebook, or various other social sites.

The other thing you may want to consider is providing only limited accessibility. I know Amazon does this in parts of their site. A user can browse the site as if they were logged in, but only to a point. Before they can do anything related to purchasing and orders, they have to supply their password.

Edit: One other issue, that just occurred to me. Make sure that you can invalidate the urls. Generate tokens in your database that you put in the emails, and then have a way to revoke those tokens. One way to do this is to put a counter on all of your user records and then copy that counter value into the token table when you generate the emails. If you ever need to revoke a large number of tokens quickly, you can simply increment the counter on the user record. You can then easily see that the token's counter does not match the users counter, so you can reject the token.

Answer 2

I'd make sure there is a time limit on the validness of the link in the email and make it only valid for one click.

Answer 3

At a minimum,

• put a hard time limit on how long the link is active (1-2 days?)
• make it work exactly once. No matter what happens after the first time it is used, if it gets used again, a 404 gets issued.

Answer 4

I would automatically login the user if and only if they have clicked a "Remember me on this computer" check box at step 1

Answer 5

There is nothing wrong with using an e-mail address as a user identifier. It tells you the person who is doing the registration has access to that e-mail address at that particular time. But I do think the link should expire, and if the link expires, kick out that e-mail address out of your database (as it may be someone elses e-mail).

As e-mail is not secure, nor very personal (there are a number of free temporary e-mail sites on the web) you can't really use e-mail in a situation where trust is important. But for a simple website where you want some kind of accounts I don't think it is an issue.

To your opninion on point 2, in my opinion, if you don't have step 2, you also don't have to bother with step 1 and 3.

If you don't let the user verify the e-mail address, you shouldn't even ask it. You wouldn't have a clue wether it was a real address, corresponding to the person who tries to make an account.

If you don't have an e-mail address, there is no way a user could be given a new password, as you don't know where to send it to. The e-mail address entered might belong to someone else, who doesn't even want to have an account on your site.

If you can't reset the password via an e-mail address (reliably), you shouldn't bother with logging in at all. Go for an accountless site.

This assumes you do not use a callcenter or helpdesk to verify accounts, and handle password resets of course.