What's the risk in putting semantically meaningful data in an HTTP session identifier?

Question

I'm currently looking at performance optimization and am considering a way of speeding up cookie based session handling. There are advantages to having a session identifier in place when there is no server-side data referenced by it. I'm trying to work out if it's a good idea to attach an indicator to the session id which shows if there is serverside data. This would avoid the need for attempting to fetch non-existent data in some cases, and could be further extended for other simple cases (e,g, to differentiate between different server-side session data storage backends).

e.g. the first time a user hits a site they get a session id 'abc' and...

Set-Cookie: sessionid=0abc;  HttpOnly

When any data is added to the session....

Set-cookie: sessionid=1abc; HttpOnly

Obviously the presence/absence of server-side data will be apparent to an eavesdropper. And there is the potential for the cookie to be tampered with such that it appears to be associated with serverside data - but in this case the worst thing to happen is that it behaves the same way as sessions do currently.

I'm also mindful, that in the EU we must now ask users for consent before dropping any non-critical cookies.

Further, I'm not proposing to use 3 letter session identifiers! Apart from a small stub, the remainder of the session id would continue to follow usual practices of being essentially random data. I'm assuming that there's no gain to be made by regnerating this at the point where the stub changes.

But can anyone see an issue I don't?

Answer 1

If you'll be using this solely as an accelerator tag, then I don't see any reasons why not. You've mentioned you considered the possibility of this cookie data being tempered with, so if you're already designing your user identification (when it applies) with this possibility in mind, it really shouldn't be an additional security issue.

As for that EU "cookie directive", here's a quick digest of it:

The law requires companies to obtain “explicit consent” before using or storing data in ways that may be considered to be “intrusive.”

IANAL applies, but in my book an accelerator that isn't neither too space/bandwidth consuming, nor “intrusive” by identifying or helping to identify the user in any way whatsoever, really doesn't fall within this "cookie paranoia" category. If anything, it's there to the benefit of the end user. But to be sure, you should check with the lawyer of the company you're designing your solution for, as they'll be the ones responsible for how their services operate. You will be required to notify users of the use of cookies on the website anyway ("this website uses cookies... blah, blah, blah..."),

"Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information."

so that notification could point to a page describing each cookie value. Not too descriptive to be a security issue on its own, but enough to help clear the user's mind of it. Any other requirements regarding this "cookie law" really depend on what other cookies you'll be using and for what purpose.

The only other "issue" that I can think of is that you should take into account that users might be enabling/disabling or even deleting cookies at random and at any stage of using your website (especially with all these required by law warnings reminding them they ought to be more paranoid than it's worth or mentally healthy being), and that this switching on its own shouldn't present any issues with how your code functions. In a nutshell, you should never depend on any cookie values and rather consider them as "helpers", as you suggested you already do anyway.