How to securely implement auto-login

Question

I've read many, many, many posts on how "you're probably storing passwords wrong". They are always referring to storing passwords on a server into which a user is logging; they basically rehash (pun intended) ubiquitous advice like make sure to salt the passwords, etc. etc. However, I've never seen an article on best practises for storing passwords on a client so that the client doesn't have to log in manually every time they want to log in; the "remember me" feature.

Many pieces of software have this feature, from browsers to programs like Dropbox.

I did read an old article recently about how Dropbox was storing an ID on your computer that you could just copy/paste to another computer and start Dropbox and be logged in as the device you got the ID from; no login, no nothing, and full access to the Dropbox account. This seems like a really stupid design, but I can't think of any better way to do it.

I'm not even sure how to avoid storing something like a cookie in plain-text. If you encrypt it, where do you store the key to decrypt it?

The only way I see to not introduce security vulnerabilities is to remove the autologin feature and make the user type their password every time they want to use a service, but that's a usability struggle and users are spoiled to expect not to have to do that.

What can I read about locally storing credentials safely to implement the automatic login feature? If the principles are too simple for an entire article, what are they? The software in question should not depend on features not present on all platforms (like the "keychain" some linux distributions have).

Answer 1

One way is:

• When the user logs in, store a session ID in a cookie on the client's computer (not the username or password).
• Tie session to IP address, so an individual session ID only works with the computer it was started on.

Depending on what framework you are using to develop your site, this behavior may be available as a built-in feature.

Note that, because the HTTP protocol is stateless anyway, there is actually no functional difference between keeping someone logged in during a single session of using the website and "auto-login" the next time they use the site; it is solely a matter of how much time you allow before the session expires.

Update: Also, use HTTPS for increased security, obviously.

Update 2: Note that this approach has limitations, in that it doesn't work well for users who change their IP address a lot. However, it does provide an increased level of security and may be useful in some situations.

Answer 2

Amazon (and many others) use a hybrid approach. They provide autologin for browsing, adding items to the cart, and placing orders using credit cared/shipping address combinations you have used before. However, they require you to enter your password for many actions such as adding credit cards, adding/changing shipping addresses, updating passwords, viewing past orders(optionally to the user), and lots of other account settings.

So yeah, people who gain access to your computer could hijack your session, but you still get what they order! (More importantly, the incentive to hijack a session is pretty much negated.) But if someone has access to my computer, I have bigger problems than people stealing the average site sessions.

If you have parts of your application that don't need as high of security, you can choose a hybrid model where you store a session ID (hashed or whatever if you'd like) to auto login users to low security portions of the site, but require them to enter the password when the enter higher security areas and delete the high security token when the session ends.

Of course if this is a banking level site, than auto login isn't an option. Again, sites that use these types of security assume the value of the data they are protecting and the added convenience to the user out weigh the potential risk of a hijacked session. If you feel that is not the case for your application, then don't implement auto logins. You need to access what level of security/usability trade offs are appropriate for your use case.

Answer 3

It's actually not that hard. First store a cookie with this format:

userID.token

You can use an sha1 hash for the token. Then in your remember_me_tokens database table store userID, a bcrypt hash of the token and the time the token was generated.

Then when someone visits your site, check to see if the cookie is set. If the cookie is set then see if there's a valid row for it in the database within the last 7 days say. If there's a valid row in the database for the cookie then set the session to indicate that the user is logged in and also delete the matched cookie/database row and generate a fresh cookie/token/database row.

If they log out then delete the cookie.

Run a cron job to prune remember_me_tokens that are older than say 7 days.

Answer 4

You can only if you trust the device where you store it. It is up to the user (if you can't influence the device) how secure it is. It is simply out of your hands.

As stated in the comments:

It is about what you trust. If you don't trust the machine store the ID then that is your issue. If you trust the keychain then that is the maximum security you will get. Off course you could add some custom safety like detecting device hardware or something but it's all fake-able so you cannot know in the end. It is out of your control.