Remember me Cookie best practice?

Question

I read about many old questions about this argument, and I thought that the best practice is to set up a cookie with username,user_id and a random token.

Same cookie's data is stored in DB at cookie creation, and when users have the cookie they are compared (cookie data, DB data).

Sincerely I can't understand where is the security logic if this is the real best practice.

An attacker who steals the cookie has the same cookie than the original user :|

Forgotten some step? :P

Answer 1

You should NEVER EVER store a users password in a cookie, not even if it's hashed!!

Take a look at this blog post:

• Improved Persistent Login Cookie Best Practice (Nov 2006; by bjaspan) (orignal)

Quote:

1. When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.[2]
2. The login cookie contains the user's username, a series identifier, and a token. The series and token are unguessable random numbers from a suitably large space. All three are stored together in a database table.
3. When a non-logged-in user visits the site and presents a login cookie, the username, series, and token are looked up in the database.
4. If the triplet is present, the user is considered authenticated. The used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.
5. If the username and series are present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user's remembered sessions are deleted.
6. If the username and series are not present, the login cookie is ignored.

Answer 2

You should store the user_id and issue a random token in addition to the user's password. Use the token in the cookie and change the token when the password changes. This way, if the user changes their password then the cookie will be invalidated.

This is important if the cookie has been hijacked. It will be invalidated if the user detects the hijacking, and furthermore because the token is unrelated to the password the hijacker won't be able to derive and then change the user's account password and "own" the account (assuming you require the existing password before changing passwords, the hijacker doesn't own the email account so they can't use "Forgot my password" etc).

Take care that the tokens aren't easily guessable (i.e. they should consist of entirely random data, like from a CRNG).

If you want to go one step further, you can encrypt the cookie before sending it and decrypt it upon receipt. And further to that, don't assume that a hijacker doesn't know the encryption key used, so validate the cookie's contents upon decryption.

But all that said, prefer to use a library's persistent session management instead of rolling your own.