Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Best Practices for storing customer secrets?

news.ycombinator.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Ask HN: Best Practices for storing customer secrets?

#11

Post by dev_0 »

_mme wrote: post #6
n42 wrote: post #5

IMO this depends on the strength of your org's ops function (which will usually correlate with scale of your org), and the responsibility you hold for the customer's data. if your org does not have a strong ops function yet, and you're in scrappy startup phase: just use your language or framework's best practices, standard encryption tools. do not try to create your own encryption scheme. let your app take two keys;…

> 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 "oops I accidentally copied the DB somewhere and it leaked". Good point. If the attacker gains access to e.g. a web service that needs to access the stored secrets, they will have encryption keys and…

[dead]

Re: Ask HN: Best Practices for storing customer secrets?

#12

Post by n42 »

_mme wrote: post #10
n42 wrote: post #8

Earlier quoted context omitted.

Sorry for stream of consciousness here; at the end of the day if the code that handles the sensitive secret is compromised, you’re leaking secrets one of the big ways Vault can help is by separating reads and writes. the web UI that stores a secret, exposed to internet, only receives a token that can write that secret for that customer, and only that customer. that service cannot get tokens that allow the code to rea…

I have to be annoying, but - if you have a token that is only valid for X seconds - you still need a token to renew the expiring token. I have the feeling that damage control is the only option: 1) Secrets store is on different credentials 2) Decryption key is only known outside of secrets storage 3) There is a maximum number of different credentials that can be queried per day (adjustable over time)

Yeah you do, but you compartmentalize that with your orchestration (hence strong ops). With HashiCorp Nomad for example you might setup a parameterized job. When Nomad receives a job to do X for customer Y, it allocates a container with a short lived token. Nomad is the system with the longer living token that lets it generate short lived tokens for short lived workloads, that are themselves containerized to add a layer of security for a compromise. And so on.

Abstract that a little bit; the system that generates the short lived token ideally would not be the same as the system that is using it

Turtles all the way down

Re: Ask HN: Best Practices for storing customer secrets?

#14

Post by AlexITC »

n42 wrote: post #5

IMO this depends on the strength of your org's ops function (which will usually correlate with scale of your org), and the responsibility you hold for the customer's data. if your org does not have a strong ops function yet, and you're in scrappy startup phase: just use your language or framework's best practices, standard encryption tools. do not try to create your own encryption scheme. let your app take two keys;…

Be aware that there are some encryption algorithms where decryption with the wrong key won't fail but lead to a wrong result (rot13 being the simplest example, there are some modes in AES with this behavior too).

A potential improvement could be to use a different key per customer, where the key mapping (customer -> key) is encrypted with the application key, this process simplifies key-rotation and prevent that a leaked key gets access to all the secrets.

The key mapping schema could be handled with postgres security definer functions to avoid dumping the schema from code.

Re: Ask HN: Best Practices for storing customer secrets?

#15

Post by Someone »

n42 wrote: post #5

IMO this depends on the strength of your org's ops function (which will usually correlate with scale of your org), and the responsibility you hold for the customer's data. if your org does not have a strong ops function yet, and you're in scrappy startup phase: just use your language or framework's best practices, standard encryption tools. do not try to create your own encryption scheme. let your app take two keys;…

> 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.

Not necessarily. It can reside in memory that isn’t readable by your web application (e.g. in a different process, in the OS kernel, in Apple’s Secure Enclave or ARMs TrustZone))

If your hardware supports something like that, you should seriously consider using it.

Re: Ask HN: Best Practices for storing customer secrets?

#16

Post by FlyingAvatar »

n42 wrote: post #5

IMO this depends on the strength of your org's ops function (which will usually correlate with scale of your org), and the responsibility you hold for the customer's data. if your org does not have a strong ops function yet, and you're in scrappy startup phase: just use your language or framework's best practices, standard encryption tools. do not try to create your own encryption scheme. let your app take two keys;…

We solve this problem by storing an identifier of encryption key itself along with each encrypted record. The key is loaded on demand assuming the viewer has access.

The encryption key identifier is essentially a timestamp of when the key was generated. We have a process that periodically re-encrypts all data encrypted with the old keys and then purges them. This effectively removes the secrets from our backups because after long enough there is no key to decrypt the data.

This is an acceptable trade off for our use case as the sensitive data is generally not required to be kept very long.

Post reply on HN