skip to Main Content

Wanted to understand if this is a common and secure practice.

I have an application that has a lot of customer secrets (their API Keys, credentials).

We’ve reached a stage where AWS secrets manager is not proving to be cost-effective as the number of secrets are high.

Was wondering to encrypt the secrets and store them in a database (we use postgres already) and store only the AES keys in secrets manager or KMS (which can only be accessed by resources with the relevant permissions).

This way the costs for us can be significantly reduced.

Vault can be another option, but this is currently not in the tech stack of my company and may require a lot of time to take to production.

Storing the secrets in the DB using AES encryption at rest is a common practice? Anything to be wary of?

2

Answers


  1. I am a little worried that you even have the secrets in the first place. You should forget encryption and just store salted SHA2 hashes of the secrets in your database. When you get an API key or password to verify, compute the salted hash of it and compare with the value you have in your database. Only a valid API key will pass this test.

    In short, using salted hashes instead of plaintext credentials will reduce cost and increase security.

    The problem with encryption is rarely the algorithm, but the implementation. To achieve similar security conrols, you will need to develop things like master key rotation, unique and random IV per secret, granular access policy to secrets, and secret versioning. Vault and your Cloud secret manager handle that for you behind the scenes.

    Login or Signup to reply.
  2. Was wondering to encrypt the secrets and store them in a database (we use postgres already) and store only the AES keys in secrets manager or KMS (which can only be accessed by resources with the relevant permissions).

    This way the costs for us can be significantly reduced.

    Yes. IMHO this is good solution, mainly using directly KMS (or rather AWS Encryption SDK as the library enforces use of good practices such as random nonce, authentication, ..).

    Best practice with KMS is using the envelope encryption – you should encrypt the plaintext (value) with a random data key and then use the KMS to encrypt the data key. I believe the AWS Encryption SDK is handling this for you.

    Using the SecretManager – it is like a ParameterStore, just encrypted using KMS and handling extra events (like what to do on changing the secret value). In this case IMHO it’s safer to use KMS directly as the key material is never exposed.

    Storing the secrets in the DB using AES encryption at rest is a common practice? Anything to be wary of?

    As already written in another answer, try not to handle secrets or 3rd party credentials at all when really not needed.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search