Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Currently our web application uses server-sided sessions. Because of the large amount of memory usage, we want to switch to cookie-based sessions. I have been thinking about several ways:

Idea 1

My first idea was to give the client two cookies: SessionID (a hash) and SessionData (the encrypted data). The SessionID will be used to look up a decryption key for SessionData in an in-memory hashtable.

Because only decryption keys are stored on the server, this should wind up being less memory usage. However it still uses some memory, and the CPU load is increased due to encryption/decryption on every request.

It'd also make the session cluster-dependant, with no graceful failover possible.

Idea 2

My second idea was similar to the fist, but instead of looking up a decryption key in a cache, I'd use a salted version of SessionID to decrypt SessionData.

The upside is that there wouldn't be any in-memory cache or hash table anymore, and that session would be cluster-independent if the salt is the same for all clusters.

However, the tradeoff is that it's much less secure due to a potential danger of decrypting or modifying the SessionData cookie, and that the CPU load is increased due to encryption/decryption on every request.

Is there a better way to go about this problem? Or a way to modify one of these ideas to be a little more palatable?

share|improve this question
    
How critical are your session data? Is it really a big deal if someone manages to decrypt them? –  Mike Nakis Jan 11 '12 at 7:06
    
And, does it really hurt if someone manages to decrypt the session data of their own session? –  Mike Nakis Jan 11 '12 at 7:07
    
Yeah it can get ugly if an authenticated user manages to change i.e. his user ID in the cookie; then he could access/write data from someone else. If he decrypts the cookie that's not a problem but if he can re-encrypt a modified cookie, that's a problem. –  thwd Jan 11 '12 at 7:09
1  
Yes, of course, I understand. Let me ask you something off topic: is it really worth spending time to develop a solution to this problem, wasting bandwidth, taxing your CPU, and risking anything whatsoever security-wise, instead of simply buying more RAM for your server? –  Mike Nakis Jan 11 '12 at 7:19
    
Maybe you're right. In terms of scalability that's a bummer but maybe we really need a dedicated and distributed session store. –  thwd Jan 11 '12 at 7:23

1 Answer 1

up vote 1 down vote accepted

"No sir, I dont like it"

You're needlessly complicating things. Consider that by storing information client side, you now also have to be extra careful to validate all that information when it is sent back to you. Or are you going to simply decrypt and trust it? What happens if the data is slightly corrupted when its sent back? You are also potentially increasing your bandwidth usage as each request, whether you want it or not, will be sending the encrypted session data back to you.

A better solution would be to find a way to store your session data more efficiently on the server. Or store less of it. Or as Mike N suggested, just add some RAM.

share|improve this answer
    
I ended up coding a distributed session store =) –  thwd Jan 13 '12 at 0:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.