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.

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

3 Answers 3


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.

  • 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, 2013 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). Sep 2, 2013 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.

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

If your company's load balancer setup does the non-standard thing of not locking sessions to servers, then you have several options.

Either you keep the keys static across the cluster (you can base them off something changing, but consistent across the cluster - for example application version / maven information).

Or you have to put a synchronization mechanism in place to share the secrets.

For example, ZooKeeper is a fairly simple to use coordination service. Alternatively, you could use JMS to send a message to the other cluster members with the key.

Or you could even use JMX, with a set mechanism, if your application is aware of the other cluster members (hardcoded cluster, or service discovery).

Or even write your own sync API, a nice secured restful key sharing mechanism between cluster members.

Once you have a coordination system in place, you suddenly can generate new keys and salts all the time, which is nice (and recommended).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .