Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm working on encrypting a web application's cookie. Using symmetric AES/CBC, I encrypt the cookie data before writing it out, and then decrypt it when reading it back in - the standard stuff.

The problem is that people may use load balancers to host this web app. For that reason, the secret key used to encrypt cookie data cannot be randomized - it must always be the same so that one load-balance server can decrypt a cookie that was written out by another load-balance server.

This means my secret key is much easier to crack than if the secret key was randomized. Right now I use "PBKDF2WithHmacSHA1" to derive the secret key using a non-random salt. Do you think that's acceptable? Is there any way to make it definitively more secure in this case? Thanks for your insights.

share|improve this question

migrated from stackoverflow.com Sep 9 '13 at 2:19

This question came from our site for professional and enthusiast programmers.

    
Is your application stateful at all, do you use session cookies? Or is that what you're trying to build here? –  Syon Aug 28 '13 at 23:41
    
Yes, the cookies store session information for this web app. –  Zoomzoom Aug 29 '13 at 2:45

2 Answers 2

The standard mechanisms on making CBC more secure is to create a random IV (use in a cookie) and a message authentication code. You should use two static, randomly generated keys for this. Using a PBKDF is not a good idea: if an attacker can access the secret then the game is over, no matter what you do. PBKDF has been designed to eat CPU cycles, the opposite of what you are trying to when clustering for performance.

Unless you can differentiate between cluster machines (maybe make one more secure than the other) then adding more security will be tricky.

share|improve this answer
    
Yes, CBC requires an IV and that piece is randomly generated. I don't have to worry about the IV since it's written out as part of the cookie data. The part I'm having trouble with is protecting the secret without a random salt (to prevent dictionary attacks). This is tricky indeed. –  Zoomzoom Aug 30 '13 at 21:34
1  
No, you are looking at this the wrong way. The problem you are having is protecting the secret, full stop. Key management is always hardest. Salt has nothing to do with it. Salt is used to protect passwords. There is no reason in your scheme to use a password at all, you can just use fully randomly generated key(s). –  Maarten Bodewes - owlstead Sep 2 '13 at 6:45

How about using a random secret key and storing it in a DB or other location available from all servers.

Generally load balancers are configured such that subsequent requests that are part of the same session go to the same cluster-member-- they only go to a second when the primary fails. Perhaps you could re-create the encrypted cookie (new secret key) in this (rare) case.

share|improve this answer
    
Thanks, but I'd prefer to keep the secret key in memory. –  Zoomzoom Aug 28 '13 at 21:15
1  
Why can't you share the key between servers at runtime? –  atk Sep 9 '13 at 2:39

Your Answer

 
discard

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