I have some data that is symmetrically encrypted with a single key in my database. Rather than hard coding it into my code, I am looking for a safer way to store the encryption key. Where can I safely store it?

  • 1
    There really isn't a way to store it, at least not in a safe way, more information is needed to expand this comment. – Ramhound Mar 1 '12 at 17:28
  • 3
    Without secure hardware, I think you are out of luck. That is why it is most common to store a hash of a password instead of an encrypted version of a password. If you have secure hardware such as a TPM, you could use that. – mikeazo Mar 1 '12 at 18:16
  • 2
    For those who are looking for a key management solution for an application running in Amazon Web Services, AWS Key Management Service (KMS) may be a good option. – Ville Jul 30 '15 at 22:07
up vote 105 down vote accepted

Here are your possibilities:

  1. Use an external Hardware Security Module. There is an entire industry of products designed for offloading security-sensitive operations to external devices. This doesn't solve the problem so much as relocate it, but it relocates it to device that is far more secure, so altogether it's a security win. If you're doing anything high-stakes, then this is almost certainly going to factor into your solution.

  2. Tie the encryption key to your hardware. TPM chips are useful for this, as are USB security tokens (not flash drives, though). In this case, crypto only works on that specific piece of hardware, but isn't otherwise restricted. It's a bit like the kid-sidekick version of the HSM mentioned above. Google's recently-announced Project Vault takes this a step further by making a high-bandwidth HSM embeddable into even the smallest consumer devices.

  3. Tie the encryption key to your admin login (e.g. encrypt the the encryption key with your admin login). This is only marginally useful as it requires you to be logged in in order to encrypt/decrypt anything. But on the plus side, no one can encrypt/decrypt anything unless you're logged in (i.e. greater control). Much of the secure storage in Windows works like this.

  4. Type in the encryption key when you start up, store it in memory. This protects against offline attacks (unless they capture the key out of RAM, which is tougher to do). Similar to the option above, but also different. However, the server boots into an unusuable state, requiring you to manually supply the key before work can be done.

  5. Store the key on a different server. E.g. put the key on the web server and the encrypted data on the database server. This protects you to some degree because someone would have to know to grab the key as well as the database, and they'd also have to have access to both servers. Not amazingly secure, but an extremely popular option anyway. Most people who think they're doing it right do it this way. If you're considering doing this, then also consider one of the first two options mentioned above.

  6. Store the key elsewhere on the same server. Adds marginal security, but not a whole lot. Most smaller operations do this -- they shouldn't, but they do. Typically because they only have one server and it runs in some cloud somewhere. This is like taping a key to the door instead of leaving it in the lock; guaranteed to stop the most incompetent of attackers.

  7. Store the key in the database. Now you're not even trying. Still, a depressingly popular option.

  • i'm dealing with this same issue, where i am trying to use encryption at rest, and i'm required to have the encryption key sitting on the filesystem. it might be ok if it was a temporary file that can only be read once, and supplied remotely on startup. the idea is to prevent a tar of the filesystem from being enough to recover the database. i looked into vault.io a while back for scenarios like this, but it just moves the problem around when connecting to the secret server requires... a private (x509 verify) key on disk. – Rob Jan 28 '16 at 15:55
  • 3
    As soon as you put your keys in an external service (opt 1 + 5), you then have the credentials to access those services in plain text on your server. So the problem is not solved, you have just created a new class of problems. How are these avoided? – Chris Seufert May 8 at 3:48

I realize this was answered a while ago, but to give a couple examples to Tyler's good answer: I plan to use his #1 to tie a password to a service account and use a Powershell cmdlet to grab it. That way the scripts do not need to be as heavily modified. The service account's password is in Active Directory and would have to be compromised first. This works for me since I have use it on two servers. For his #4, to meet our compliance we were able to store a key in plain text on another server with external storage because that storage was itself encrypted and access to it restricted. As Tyler mentions the latter doesn't seem so secure, but it was good enough even for a tough assessor.

You can create two layer architecture for the key management.

  1. A key to encryp your data at rest encrypting the tablespaces,or column based.
  2. Master key to unlock 1.

for your master key(s) use one of one of the established key management solutions such as:

  • Amazon AWS KMS
  • Oracle Vault
  • Microsoft MKS.
  • or open source ones.

Just keep in mind that your key manager has to support equal or higher availability than your infrastructure where the managed key are used.

  • 1
    That's nice for centralised key management. But how does this support security? Since now you need to store e.g. your asw kms credentials to be able to reach aws kms. I am puzzled. I am not the only one. – musicformellons May 16 at 11:13

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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