1

I have a login page which asks for a username and password. This page has a checkbox "Remember Me".

Authentication is: For the username provided, convert the provided password to a hash using the salt stored with the user db record and compare the hash to the stored hash.

When a user ticks the box, what should I store in their cookie so they auto login next time they visit?

I was thinking that a good way was to store their username and a hashed value of their password in a cookie and to re authenticate the user on their next visit. The salt will be kept away stored in a database.

Valamas
  • 24,169
  • 25
  • 107
  • 177

3 Answers3

3

I would not store hashed passwords in the client cookie. I would create another abstraction between users and long lived sessions. I would start by reading the following article to get some ideas about the challenges:

http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/

The key part from that article is that not all logins should be created equal.

J. Holmes
  • 18,466
  • 5
  • 47
  • 52
  • Good article. You don't need to put the username in the cookie at all, though, you just need the big random number. The user name and timestamp can be server-side. – Cameron Skinner Nov 23 '11 at 04:12
  • @CameronSkinner I think he's saying that the user names are particularly "secret", so it makes it less likely to find a collision. If it was just a big random number then, then you could theoretically spam the server and attempt to log in as anybody... Even if you had the right key, you'd need to put it in the right door. – J. Holmes Nov 23 '11 at 14:03
  • I suspected someone was going to argue that :) You can *always* spam the server and attempt to log in as anybody. Putting the username in the cookie doesn't prevent that, and it only marginally increases the space the attacker needs to sample. You can think of the username as a very low-entropy addition to the big random number. If you're adding, say, 10 bytes to the cookie to store the username why not just add 10 bytes of randomness instead? Then you *genuinely* make collisions less likely. The key here is that the attacker is guessing stuff - so make it as random as possible. – Cameron Skinner Nov 23 '11 at 20:41
2

It depends on the level of security you want to maintain. When I check a "Remember Me" box, I only want it to remember my username. I still want to provide my password as normal.

Storing username and hashed password in a cookie, seems like a bad idea to me.

Craig T
  • 2,761
  • 5
  • 25
  • 33
  • 2
    @Valamas, as Craig pointed out, storing password (whether hashed or not) in the cookie is a bad idea. You don't gain anything extra out of it. Instead store the user-name and time-stamp in a encrypted form in the cookie. The presence of this token will essentially tells you that your user has been per-authenticated. Further, ASP.NET Forms Authentication has all this already built-in so you really don't have to re-invent the wheel. Use `persistCookie` parameter. – VinayC Nov 23 '11 at 04:05
  • @VinayC: This is not the first time you have directed me well with Forms Authentication. I have now connected it up properly in my FormsAuthenticationService class. Thank you – Valamas Nov 23 '11 at 04:31
2

If you really want to keep a user logged in then you should store a unique login token in a cookie, not the username or hashed password. When your server receives a login token you can compare it with your database of persistently-logged-in-users and see which user the token corresponds to. The server should store the login token, the username associated with that token, and an expiry time. Once a token has been used it should be invalidated so it cannot be reused.

This minimizes information leaked to the client, and it limits the opportunities for an attacker to recover a legitimate user's password if they manage to steal the cookie (which is relatively easy to do).

I highly recommend that you also set the secure flag on all your cookies so they are only sent across secure connections, and make sure you have a relatively short timeout on persistent logins. Also, it's a good idea to have additional authorization checks, such as making sure the login token is associated with a particular IP address or browser fingerprint, to help prevent casual attacks. This still won't seriously hinder a determined attacker but might dissuade some script kiddies.

Finally, please consider taking @Craig T's advice and only remember the username, rather than keeping a user logged in. Persistent logins are very dangerous so you should think carefully about the value your users get from this vs the potential costs.

Good on you for correctly storing your passwords in your DB! It's amazing how many people think they don't need salts.

Cameron Skinner
  • 51,692
  • 2
  • 65
  • 86
  • Excellent. +1 on the secure property - I will now setup a https version of the development site to ensure this. – Valamas Nov 23 '11 at 04:30