1

I'm making a website that has an extended forum feature, where users can login, post comments, etc. I'm making the feature where the website stores cookies in your computer so the next time you visit the website, it logs you in automatically.

I've heard not to store explicit username and password in a cookie. So I decided to store the user id in my database as a cookie value. Essentially, all information when you use the site can be obtained by querying the database again by this user ID.

Then I just realized that if you manually edit your cookie and place a random user ID, anyone would be able to access any account! All the functions in the website such as new comment, new topic etc. are can be accessed just by supplying your user ID.

What is the correct way to have users log in automatically on my site without exposing it so anyone can log in?

3
  1. Create a cryptographically secure random token and associate it with the user id in your DB
  2. Perform an HMAC on the token
  3. the cookie value will then be token+HMAC

This way an attacker would have to know your HMAC key in order to brute force the token and that is not possible.

For validating the cookie you first extract the HMAC, validate the authenticity of the token and then you can check your database and extract the user id that is associated to it. After a few failed HMAC validations you can block the user since not even one HMAC validation should fail and it means someone is trying to attack you.

It is important to keep the security of the cookie by:

  1. Set HttpOnly flag to true - so cookie cannot be accessed from javascript
  2. Set the Secure flag to true - so cookie will only be transmitted via https and cannot be sniffed over the network
  3. Set a reasonable expiration time to the cookie so your user's don't stay logged on forever
  4. Set the cookie domain to make sure it is not leaked to any subdomains where you do not intend it to go
  • Are you also recommending clearing the existing token from the DB when the user clicks the logout button? Then creating a new random token value when the user logs in again and wants to stay logged in? Also, why are you storing the original token in the cookie instead of just the hmac value of the token? – PwdRsch Aug 27 '14 at 16:59
  • For the first part - yes. on logout you clear the cookie and delete or make obsolete the entry in the database so that this token is not associated anymore to this user. regarding the second part - the idea is that an attacker would have to guess both the token (suppose 128 bytes) and its correct hmac (32 bytes). if i just keep the hmac (and I remind you that hmac is one way so no way to obtain the token from it) then the attacker now only has to guess the hmac which is like guessing just a random 32 byte value. – aviv Aug 27 '14 at 18:10
  • Thanks for your answer. I'm still not clear about the second step: how do you verify the HMAC? Doesn't this mean I have to extract a token from the HMAC (but, as you said, HMAC is one way)? Or do I need to go through all existing tokens and HMAC them one by one and compare? That seems inefficient. – l3utterfly Aug 29 '14 at 2:24
  • As I mentioned the token plus the hmac are in the cookie, so first you parse the cookie and extract both, then you hmac the token and compare it to the hmac from the cookie. They should be equal. If they are equal and the token is valid in your DB the user is authenticated – aviv Aug 30 '14 at 4:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.