5

I'm in the process of creating a website and uses cookies to track user login. The only bit of information I store in this cookie is the users username.

Should I be encrypting the username even though it isn't sensitive information such as a password?

I've noticed other sites which use cookies to track logins have all their cookies information encrypted.

What potential security threats could arise if I weren't to do this and the only bit of information in the cookie is the username?

  • 2
    The username can't be the only information in the cookie when tracking a logged in user. You clearly need some form of unguessable token, such as a session ID as well. Once you have that, you don't need to store the username in the cookie at all. – CodesInChaos Apr 28 '13 at 08:40
  • Does the session ID get compared to anything? –  Apr 28 '13 at 09:58
  • 1
    typically a session ID is a random 128 bit value that the server looks up in some database/file to figure out which user it matches. On logout the server deletes the token from that database. – CodesInChaos Apr 28 '13 at 09:59

1 Answers1

4

Forget about encryption. You are tracking user logins through cookies and the cookies only contain usernames. How much difficult it is for someone to predict someone else's usernames. If you don't encrypt the session information, there is always the threat of someone sniffing the cookie and hijack the session. But in your case I think a user not only can hijack a single session, he can hijack every login session just by changing the username in the cookie. OWASP recommends a session ID of length 128 bits generated through a cryptographically secure Pseudo Random Number Generator (PRNG). Take a look at OWASP session management for further details.

Once you configure the session management according to the OWASP session management guidelines inside your web application code, establish an encrypted tunnel and communicate over the encrypted tunnel. A lot of people use SSL for the login part but as soon as the user is authenticated, communicated reverts back to HTTP. Make sure the cookie is always communicated over the encrypted tunnel as well. If session cookie is in plaintext, a user who sniff the cookie over the network can replay the cookie and gain access to the user account. Firesheep is a tool that demonstrate the exploitation of this vulnerability through a single click.

void_in
  • 5,621
  • 1
  • 23
  • 29
  • 2
    The communication must be encrypted, not the cookie! An encrypted cookie can still be eavesdropped when the communication is not secured and be used for replay attacks. But if the communication is encrypted, the cookie cannot be eavesdropped. – Gumbo Apr 28 '13 at 07:13
  • @Gumbo You are right. Securing the cookie against replay either through encryption or hash(ID,secret,random) is always implemented the wrong way so yes the communication line should be encrypted. SSL is the obvious choice here instead of going for a self-made encrypted tunnel. Thanks for the comment. I will update the answer as well. – void_in Apr 28 '13 at 08:24
  • @Gumbo if the cookie stores the user name (instead of a session ID), then the cookie must absolutely be encrypted as well. – Dmytro Shevchenko Jun 15 '16 at 12:04