Is encrypting session id (or other authenticate value) in cookie useful at all?

Question

In web development, when session state is enabled, a session id is stored in cookie(in cookieless mode, query string will be used instead). In asp.net, the session id is encrypted automatically. There are plenty of topics on the internet regarding how you should encrypt your cookie, including session id. I can understand why you want to encrypt private info such as DOB, but any private info should not be stored in cookie at first place. So for other cookie values such as session id, what is the purpose encryption? Does it add security at all? no matter how you secure it, it will be sent back to server for decryption.

Be be more specific,

For authentication purpose,

1. turn off session, i don't want to deal with session time out any more
2. store some sort of id value in the cookie,
3. on the server side, check if the id value exists and matches, if it is, authenticate user.
4. let the cookie value expire when browser session is ended, this way.

vs

Asp.net form authentication mechanism (it relies on session or session id, i think)

does latter one offer better security?

Solution 1

Attacks on sessions like Session Hijacking aim for a valid session ID. If you now would encrypt the session ID, attackers would simply aim for the encrypted session ID and you wouldn’t have any advantage. So encrypting the session ID is useless. Remember that the session ID is just a random value that is used to identify a session. Attackers don’t need to know if that random value has some specific meaning; they just need to know that random value.

If you want to secure your session, use HTTPS to encrypt the whole HTTP communication via SSL and set the cookies only with the flags

• secure to only allow the cookie to be send via HTTPS and
• HttpOnly to forbid local access via JavaScript.

Solution 2

I think what the "you should always encrypt your data" is referring to is to use SSL in your connections using a properly signed certificate. This will encrypt the whole communication between client and server.

I can't see any other use in otherwise additionally encrypting the session ID (which is already a very randomly generated ID in the first place).

Solution 3

This is documented in the OWASP site

Via web.config in the system.web/httpCookies element

<httpCookies httpOnlyCookies="true" …> 

Or programmatically

C# Code:
HttpCookie myCookie = new HttpCookie("myCookie");
myCookie.HttpOnly = true;
Response.AppendCookie(myCookie);

Solution 4

The data sent over SSL (HTTPS) is fully encrypted, headers included (hence cookies), only the host you are sending the request to is not encrypted. It also means that the GET request is encrypted (the rest of the URL). Although an attacker could force a client to respond over HTTP, so it is highly recommended to use the "Secure" flag in your cookie, which enforce the use of HTTPS to send cookies.

The Secure attribute do not have associated values. Rather, the presence of the attribute names indicates that the Secure behavior is specified. The Secure attribute is meant to keep cookie communication limited to encrypted transmission, directing browsers to use cookies only via secure/encrypted connections. Naturally, web servers should set Secure cookies via secure/encrypted connections, lest the cookie information be transmitted in a way that allows eavesdropping when first sent to the web browser.

View more solutions

Comments

[rook]

+1 Damn you Gumbo! I was going to say https and HttpOnly cookies.

[JiJ]

Thanks. https Makes communication secure, which I know. But httponly cookie is very interesting , will investigate.

[AJ Henderson]

Actually, it depends. If the random number was not cryptographically secure, encrypting it with a server side key will produce better security. If I used sequential session numbers, guessing a valid session is trivial. If I encrypt that such that it becomes cryptographically secure, you may know that 2 is the next session number, but you have no idea what value you need to provide to get session 2. If the random number was cryptographically secure to begin with then it doesn't matter though.