Using Cookies for Web Session State - What are the pitfalls?

Question

Using in-process session state is evil when it comes to scaling web applications (does not play well with clusters, bombs out when server recycles).

Assuming you just need to keep a small amount of information in the session state, what is the downside of using encrypted cookie items for this purpose rather than specific state servers/db’s?

Obviously using cookies will create a small amount of network overhead, and clearly you operate under the assumption that cookies are enabled on the client browser/mobile device.

What other pitfalls can you see with approach?

Is this a good option for simple, scalable and robust sessions?

Answer 1

Another pitfall is that they can be stolen and replayed on your site.

BTW: Instead of storing some stuff in the cookie, you should also look at storing a key in the cookie and using something like memcached (memcached works across server farms).

Answer 2

Well usually a cookie is used for the session ID, so as long as the amount of information is small it would be a good option to store the information in the cookie, though you shouldn't store anything of value (like CC numbers, SSN, etc) should really be stored in a cookie, even if encrypted.

I'm no expert, but in my experience I've found the following to be true (at least using PHP, and ASP.Net).

Cookie

• [pro] Scales well, since it's transmitted on every request
• [pro] Cookie can be required to submit only through an SSL connection
• [pro] Can be used cross-server technologies, and cross-server machines
• [con] Data is transmitted on every request and response
• [con] Needs to be enabled on browser

State Server / DB

• [pro] Data stored only on server
• [pro] Data persists even if user clears cookies
• [pro] Can be used cross-server technologies
• [con] requires an ID to be passed on request/response (thus requires cookies or appending to every URL)
• [con] doesn't scale well in default modes, but if an entire machine(s) can be devoted specifically and exclusively to state then this isn't much of an issue. Plenty of other scaling techniques out there that can be followed for scalability.
• [con] Requires a session ID variable passed through URL or Cookie or other means, to keep the user tied to the data.

Answer 3

This is an excellent approach for simple, scalable, and robust sessions. Of course the quality of your crypto is important, and that is often something that often proves tricky to get right, but it's possible to do.

I disagree with some of the other posters:

Any replay attack that can be launched against an encrypted cookie value can be launched against a session key stored as a cookie. Use https if this matters.

Session data stored in a state server or database is also lost if the cookie is cleared; when the session key is lost the session can no longer be retrieved.