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? 😛

Answer 1

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.