Reputation: 4719
Lately I have stumbled upon some articles that suggest using a cookie to store session data. I liked the idea and extended my session storage by adding a CookieStorage class which works fine (note that per user I use a unique hash key for sigining and encrypting data) However, there are a lot of other articles that suggest against storing sensitive data in a cookie, even though you encrypt and sign the value.
Personally, I find no reason why not do it especially when encrypting and signing the value with a different key for each user. The risk of the data being compromised is the same as with normal sessions, no? Not to mention that if you use SSL then the risk for hijacking is eleiminated.
What I see as a benefit with such an approach, if the session data are not large, is fewer IO operations on the server for opening/reading/writing session data, whether the storage is file, db, memory based
I would appreciate your feedback on the matter
Thanks
Upvotes: 3
Views: 4848
Reputation: 157839
Upvotes: 0
Reputation: 522024
If you're using pure cookie storage with no server-side component at all, then the user is in control of the data. The only thing keeping him from it is your encryption/signing method; but that can be attacked. If you're not using encryption/signing keys specific to the user's session (i.e. you're not using a server-side session), then you're pretty much limited to a static secret. Someone could attack that offline, trying to brute force it. Once they did, they could spoof their entire session.
If you are using more secure one-time random secrets stored in a server-side session... you're already storing data in a server-side session! Why not keep it simple and store everything there? It would also reduce the bandwidth needs required to transfer all the cookies back and forth with every single request.
If you're doing this mainly to save I/O operations on the server: use a more efficient session store like a memcache based store.
Upvotes: 3