0

When we store confidential information in our database, we encrypt it using AES. In addition, when customers install our product, they protect their machines using a firewall.

Should we use different encryption keys (passphrases) for different customers? What would be the benefits and/or drawbacks?

Added

We have Web UI system that access via a browser. The encryption keys (passphrases) are stored on the server side. Web client to not have access to encryption keys (passphrases). Example of the confidential information: LDAP Bind DN password. This password is used by server side when a user authenticated against LDAP.

Therefore all user should be able to use the encryption keys (passphrases) during LDAP authentication but no one need to read it (in fact nobody read it)

Michael
  • 1,467
  • 1
  • 18
  • 36

3 Answers3

3

I highly suggest creating secure, random cryptographic keys every time you have to encrypt customer information via AES and enter it into the database. Obviously, you will have to somehow store the keys since they will be randomly generated. With that being said, I would suggest using a Hardware Security Module to store keys, but you should definitely check out this answer for more storage solutions. Just make sure the data is encrypted and decrypted on the client's machine.

The benefit: Let's say an attacker compromised your customer database. If he finds the encryption key, he has all of your customer's data, the encryption is rendered completely useless. However, if the keys are randomly generated and stored in a Hardware Security Module, the attacker would basically have a useless database (unless he were to somehow get they keys from the HSM, which he shouldn't be able to do). Your customer's security is an extremely important factor, and you should make sure you are doing everything you can to keep their information safe.

Sakamaki Izayoi
  • 138
  • 7
2

Since there's only one key for all users, you're probably storing it on the server that the DB is located on. This is only marginally better than just leaving data in cleartext - it's like taping your house key to your door's lock. If you give the key to every client, then it'll be trivial for an attacker to acquire the key, rendering your encryption pointless.

In both of these cases, using a single encryption key means that all data is compromised at once.

It's hard to offer more pointed advice without further details, however. Do you want to simply store client data securely for later access by the client, or does the server need to have access to it at arbitrary times? What is the data used for?

If you're just holding onto data for the end users, then you should have each client generate an AES key and encrypt all data before sending it to you. This way, a data breach will not leak the confidential data; attackers will have to get at individual client keys as well.

If you need to be able to access the confidential data at will, though, it'll be tougher. You'll have to keep a copy of the decryption keys somewhere, and then you're back where you started with keeping the keys together with the locks.

etherealflux
  • 780
  • 4
  • 12
  • I'm not sure how you can state an "ideal" solution without understanding more of the problem. The question seems incomplete to me. – Neil Smithline Aug 04 '15 at 15:07
  • Yeah, it's very sparse on details. However, for the generic case of "I want to store data and it should be secure", client-stored encryption keys are the way to go. If the server needs to have ready access to the data, then that goes out the window. – etherealflux Aug 04 '15 at 15:09
  • 1
    Perhaps you want to add that quoted statement to the `Ideally` paragraph somewhere. I think it clears up what you mean. – Neil Smithline Aug 04 '15 at 15:25
  • Sure thing, that'll make it a little more general. – etherealflux Aug 04 '15 at 15:25
  • I have added clarification to the question – Michael Aug 05 '15 at 08:22
1

You used both terms key and password, so I am not sure what you mean because they are different concepts. That is why I will discuss them briefly:

  1. In the case you are talking about keys, then your whole system is insecure because:
    • The person who has encryption keys should not be the same person who has access to the encrypted data.
    • At least two persons should be needed to authenticate the access of an encryption key, so that no one single person has access to an encryption key
    • No one should know the complete value of an encryption key (or its passphrase)
    • Ideally, the AES symmetric key should change with each interaction,

Regarding these elements you rather need to deploy a PKI (it costs).

  1. In the case you are talking about passphrase: each user must have his own passphrase for some reasons @etherealflux and @SakamakiIzayoi mentioned.