views:

266

answers:

4

I'm building a website which allows users to create accounts and access the site's content. I don't want users to log in each time they visit the site, so I'm planning on storing the username and password in a cookie -- however, I've heard this is bad practice, even if the password is hashed in the cookie.

What "best practices" should I follow to safely remember of a users credentials between visits to my website?

+2  A: 

You shouldn't need to store the password, just an identifier for the user that your application can interpret to be them.

Things you need to be aware of:

  • If the cookie is copied, will another user be able to pretend to be that user
  • A user shouldn't be able to construct a cookie that would authenticate them as another user

A possible solution to deal with these would be to create a one-time key for each user that is changed when they next use the application.

You will probably never be able to remember a user fully securely, so this should only be used if there is no sensitive data involved.

ck
-1, you can use client side certificate to securely identify an authenticated user.
Dead account
unless the certificate is compromised....
ck
A: 

Storing a hash of the username in a cookie could provide this "remember me" functionality.

However for sensitive areas of the system you would need to know that a user entered the system on cached credentials so that you could offer a username/password prompt before you let them cause any real damage. This could be held as a session based flag.

Chris Simpson
+1  A: 

Passwords in any form shouldn't be stored in cookies. Cookies can easily be stolen.

Some browsers already support saving passwords. Why not let the user use that instead?

ksuralta
+3  A: 

Don't ever do that. Throwing around passwords in the open.

Safest method:

Store the username in a database, in the same row a randomly generated salt value, in the same row a hash checksum of the password including the salt. Use another table for sessions that references the table with user credentials. You can insert in the sessions table when the user logs in a date you want the session to expire (eg. after 15 days). Store the session id in a cookie.

Next time the user logs in, you get the password, add to it the salt for the user, geterate the hash, compare it to the one you have. If they match open a session by inserting a row in the sessions table and sending the session id in a cookie. You can check if the user has logged in and which user it is by this cookie.

Edit:

This method is the most popular in use on most sites. It hits a good balance between being secure and practical.

You don't simply use an autoincrement value for the session id. You make it by using some complicated checksum which is hard to repeat. For example concatenate username, timestamp, salt, another random salt, and make an md5 or sha checksum out of it.

In order to implement a feature that involves user credentials in a website/service there most be some exchange of data related to the credentials between the client and the server. This exposes the data to man in the middle attacs etc. Additionally cookies are stored in the users harddrive. No method can be 100% safe.

If you want additional security you can make your site go over https. This will prevent people from stealing cookies and passwords using man in the middle attacks.

Note:

Involving IP addresses in the mix is not a really good idea. Most often multiple clients will come from the same IP address over NATs etc.

Vasil
If I store the session ID in a cookie, then its still possible for someone to steal the cookie, manipulate their own cookies, and assume the identity of one my users. Please correct me if I've misunderstood.
Juliet
You are right. If you want additional security you can make your site go over https. This will prevent people from stealing cookies and passwords using man in the middle attacks.
Vasil
Well, there's one potential opportunity for a MITM attack, given that nobody examines certificates.
David Thornley
@Vasil: Lets say I'm developing a simple site, such as a messageboard or blog, rather than a site which transfers money between users. HTTPS is not appropriate, and improperly sanitized HTML is more worrisome than MITM attacks. For a site like this, how would I authenticate users between sessions?
Juliet
@Princess: The same way as I described. And do sanitize the html, xss attacks are much easier to carry out than MITM.
Vasil