Why should the value of the cookie be encrypted?

Question

I am working at a SSO project right now with CAS. I am using an RESTful API for communication with desktop-applications. The value of the Ticket Granting Cookie is encrypted. At first I didn't think much about it, but now I realized that I don't really get why that is the case. Since I use HTTPS between the different nodes, the connection is secure. The cookie will be saved in the cookie database of the browser.

As far as I see it, there is a possibility of session hijacking in such cases. But since I use HTTPS I don't get how that should even be possible. Even if it is encrypted, why not just take the encrypted cookie and hijack it. As it seem to me the owner of the ticket also does not have to, and cannot decrypt the cookie value. So at the end of the day he just saves an encrypted cookie and sends it back, a hijacker could do the same if he can break through HTTPS.

Am I missing something?

Answer 1

Well, I guess if the information is secret it could be to protect the data "at rest". This could be against legit users of the PC, or against persons getting a copy of the PC.

Generally though the cookies should be protected against change (integrity), rather than offering confidentiality. This can however be performed by placing a MAC value over the cookie rather than encrypting it.

Sometimes people are encrypting a magic value (crib) instead of placing a MAC, so this could be a case of performing DIY cryptography.

Answer 2

To answer your question specifically, encrypting random data has no value unless you are using both the encrypted and the non-encrypted data. For example, one could be stored in the server database, while the other is served in the cookie. However, a better approach is to use a one-way Hash instead of encryption. I'll decribe this below.

Here are some guidelines for secure session token cookie management:

First, make sure the cookie is marked Secure and HttpOnly, and has at least 72 bits of entropy from a Cryptographically Secure PSRNG.

Then, since the connection is secure with HTTPS, the only way the cookie would be stolen is with a server-side attack (SQLi, etc.) or a client-side attack (i.e. a virus on the PC). In both cases it's probably serious trouble already. But sometimes with these attacks, the attacker will only get a limited amount of data. Just hijacking a session token could be a real time-saver for the attacker, even if other attacks are possible as well. So, in some cases a well-secured session token cookie management scheme can make a big difference.

If the session token is stolen from the client, there is not much you can do. I like to lock down each session to a single IP address but that is not acceptable for mobile users.

However, supposing session tokens were stolen from the server (i.e. a read-only SQLi attack), you can help mitigate this by design. In the server database, only store an SHA-2 hash of the token. This way the attacker cannot convert it back into a usable cookie value. Obviously such attacks are still serious trouble for other reasons, at least you have successfully secured against this type of session hijacking.

Overall the application should be secured against XSS and SQLi of course.

Answer 3

It depends whether the cookie holds important info that would allow the user to get information he shouldn't have access to.

Let's pretend we have a site when on login sets a cookie admin with a true/false value describing whether the user is an admin, and when accessing restricted pages this cookie's value determines whether the user has access.

Encrypting and authenticating (MAC) the cookie would prevent the user from successfully tampering with it.

Similarly most web frameworks allow to store the entire session data in a cookie, in that case you don't want the user to be able to modify the data so you need to authenticate it and since the session may contain data the user shouldn't be able to see you encrypt it as well.

Oh the other hand if the cookies are only used for stuff that belongs to the user in the first place (session cookie, etc) or if it's used by the client side only then there's no point in encrypting/authenticating it.