8

I was using the Node library https://github.com/expressjs/session and noticed that it requires a secret to be specified for signing the session ID cookie.

If just the session ID is being stored in the cookie, and not any data, what is the use in signing the cookie?

My reasoning is that if someone wanted to modify a session ID cookie, then that's fine if the session ID sufficiently long to prevent brute force attacks. Am I missing something?

countunique
  • 4,068
  • 6
  • 26
  • 35
  • 1
    This might be helpful: http://stackoverflow.com/a/3240420/406249 – Nick McCurdy Mar 02 '15 at 06:25
  • 2
    @NicolasMcCurdy Thanks! Was interesting to read, but that question seems to be about session cookies that contain data so no server-side storage is needed. It makes sense that a signed cookie is needed for that, but in my case the cookie is just an identifier for data stored on the server so it's not prone to the same issues. – countunique Mar 02 '15 at 06:40
  • Maybe it's to prevent others from creating fake session cookies in the user's browser (via XSS or something like that). – Nick McCurdy Mar 02 '15 at 06:46

4 Answers4

3

I questioned this as well and the only answers I could think of were,

  • a) If someone (for no good reason?) changes the default session ID generation to a non-cryptographically random session ID, signing it helps prevent attackers generating valid session IDs.
  • b) Reduce round trips to the session store by validating the session ID using the signature/HMAC. (I can only imagine this being a problem for DoS attacks).

Both seem like valid reasons though using good session caching would negate the need for b) and assuming your library's users are daft enough to change the default session ID generation, it seems a bit much to safe-guard against their own stupidity when the majority of users would just use the default generation algorithm.

Ben Ellis
  • 163
  • 1
  • 8
1

If you store just id of session there is not reason to encrypt it. You are right. You need to encrypt if you store some session data inside cookie, not only id. This will prevent users of changing session data.

Serhii Kuts
  • 429
  • 2
  • 9
1

A session_id cookie is anything (number or alphanumeric) which identifies a client to a server, which in turns stores (usually temporary) data on the server accessed through this session_id/key.

The point is, if the cookie is going to be passed forth and back over HTTP, it doesn't matter whether you have "signed" it or not. Any man-in-the-middle could get your "signed/encrypted session_id" and make further requests pretending be the proper user. And I mean, this attacker doesn't have to care which information is inside the encrypted data, he could pass the exactly same signed/encrypted data, and the server couldn't figure out if it comes really from the right user.

In cases like these, you have to figure out if the privacy is important, if so, don't think too much, you got have to use HTTPS. If you understand it is not so important, don't waste your "processing time" signing/encrypting and decrypting your session id.

This answer is valid only for signed session_id.

Laurel
  • 5,965
  • 14
  • 31
  • 57
0

I believe the reason it is signed is so that it is not easily guessable. For instance if someone decided to use integers as session id's, you could easily impersonate another user's session by trying multiple numbers. I believe that the signing makes it so that changing your session id value client side will not be valid (that is it prevents tampering).

dwoodwardgb
  • 180
  • 4
  • 10