I'm building a web app. The app needs to keep certain data within the database very secure.

Please assume for the moment that I don't have a HSM or Key-Management facility and can't afford to implement one.

When storing away a user's data, I want to generate a random key and provide it to the user. This will not be stored anywhere on my server. This key will be used to encrypt the data.

I don't feel comfortable with the user having the only key required to decode the ciphertext, as I don't know how they're going to store it, whether they're going to email it around, etc.

As such, I intended to apply some further form of encryption on the server-side.

So first, I would encrypt the data using the random key provided to the user, and then encrypt that again, using either a static key, or a second random key which I WILL store on the server/db.

By not storing the random key provided to the user, the data remains protected if the server is compromised, as there is nowhere within the server or associated components that a hacker can obtain all the keys required to decrypt the data. They may get access to the static key, or second random key, but this won't be enough.

I was thinking of using AES for both the first and second encryption.

  • Is this a bad idea?
  • Should I instead create an encryption key that is a formula of the user's random key and the server-stored key, and then only encrypt once?
  • Should I do something completely different?

1 Answer 1


If the server is going to decrypt the data when presented with the user's key, that second layer of encryption does not protect against a leaked user's key. Whoever has that key can decrypt the data.

A second layer of encryption does make a brute force attack harder, but if the key for the second layer is stored with the data that advantage vanishes as well.

Finally, your biggest worry isn't the user leaking the key, it is the user losing access to the key. "I've got a new computer; please send my secret key again."

  • Thanks for your response. I'm not all that concerned with the user losing the key. It will just mean they will need to re-do a fairly simple task. I see your points though. It seems the 2nd key adds nothing in my scenario. I still think it wouldn't hurt to contribute to the key from the server side, although probably by making the encryption key a function of the user string and a server side string, rather than encrypting twice.
    – Baraka
    Oct 26, 2014 at 3:43
  • If I store the key for a 2nd layer of encryption on another server, that will improve security, would it not? It wouldn't have to be a key management server or HSM necessarily, but the fact that its on another server would still be advantageous. Let me know your thoughts.
    – Baraka
    Oct 26, 2014 at 3:50
  • The second key has to be available to the server with the encrypted data. If it is available, it doesn't improve security in the case of a server compromise.
    – Bob Brown
    Oct 26, 2014 at 11:11
  • If a hacker enters my server, I would hope that I could find this out in a short enough timeframe such that they aren't in there for too long. If they take full control of the server, to the point where I can't access it myself right away, at least I can shutdown or change passwords on the other server holding the key. Also, if they just download the database and files and take it with them for later analysis and attempted decryption, they'll find that the key is nowhere within those files. By this time I will have hopefully done enough to ensure they can't return. Hence more secure, yes?
    – Baraka
    Oct 27, 2014 at 6:59
  • Nope. You are talking about security by obscurity. If something is accessible to an adversary, you have to assume that the adversary will get it during a compromise. Read about Kerckhoffs's Principle, restated slightly as Shannon's Maxim. en.wikipedia.org/wiki/Kerckhoffs%27s_principle
    – Bob Brown
    Oct 27, 2014 at 10:22

You must log in to answer this question.

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