Ask HN: Best Practices for storing customer secrets?
IMO this depends on the strength of your org&#x27;s ops function (which will usually correlate with scale of your org), and the responsibility you hold for the customer&#x27;s data.<p>if your org does not have a strong ops function yet, and you&#x27;re in scrappy startup phase: just use your language or framework&#x27;s best practices, standard encryption tools. do not try to create your own encryption scheme. let your app take two keys; `CURRENT_ENCRYPTION_KEY` and `PREVIOUS_ENCRYPTION_KEY`, obviously named however you want. when encrypting data, always encrypt with `CURRENT_ENCRYPTION_KEY`. when decrypting data, first attempt with `CURRENT_ENCRYPTION_KEY`, then attempt with `PREVIOUS_ENCRYPTION_KEY` if it is set. if `PREVIOUS_ENCRYPTION_KEY` was successful, re-encrypt the unencrypted value with `CURRENT_ENCRYPTION_KEY` and save it back to the database. this gives you backward compatible deploys. you&#x27;ll then still want to write and run a script that will run through and manually re-encrypt all the old data, or else you might rotate a second time and lose access to any data encoded with the first key that had not yet been rotated. rotate your key regularly by copying `CURRENT_ENCRYPTION_KEY` to `PREVIOUS_ENCRYPTION_KEY`, and putting a new key into `CURRENT_ENCRYPTION_KEY`. the appropriate value of &quot;regularly&quot; depends on a lot of variables, and only you can determine what is appropriate for your situation.<p>this is table stakes level security; realistically if your DB is compromised, your encryption key probably is too, because they probably got in through your application which holds the key in memory. this just prevents &quot;oops I accidentally copied the DB somewhere and it leaked&quot; (which, at most startups, I would say is the most likely leak).<p>if you have, or when you get to the point that you have, a competent ops org, just use HashiCorp Vault.