Ask HN: How does your company manage secrets like API keys?
Fellow HNers,
I'm collecting data on how companies of various sizes handle sharing and deploying secrets like API keys, database credentials, etc. in both production and development.
If you have a minute, I would love to get your answers to this anonymous, 4 question, multiple choice survey:
https://goo.gl/forms/Mx97T9HD3s91DFLv1
In a couple days, I'll aggregate and post the results along with some analysis and pretty graphs.
Full disclosure: I'm the founder of EnvKey[1], a secrets management service, which is why I'm especially interested in this topic.
1 - https://www.envkey.com
28 comments
[ 5.9 ms ] story [ 75.5 ms ] threadI think Vault can be great for teams that are sufficiently large and sophisticated on the DevOps front. I felt there was a need for more of a Heroku/1Password-style tool for teams that want a secure way to manage secrets without undertaking a big project to setup/maintain their own secrets server.
Right now, I'm encrypting sensitive values in Consul for expediency. I'm going to implement Vault with an AWS back end eventually.
[1] https://www.passwordstore.org/
Any good design should be able to withstand public scrutiny.
Unless you voluntarily submit your company/email, the responses are 100% anonymous and I have no way whatsoever of knowing who you are or what company you work for.
Secret storage should really be solid enough that you could publish how you manage your secrets on a billboard without any meaningful impact to your probability of breach.
I am a big fan of security by obscurity actually. I mean, by announcing to the whole world how you store your secrets, you are telling all the hackers in the world what protocols, what algorithms should they target against. Then one day you suddenly have a 0-day vuln and boom, everything is gone.
Compare the risks of that to an employee leaving and leaking the secrets.
Maybe they're just being helpful, maybe they're outright malicious, or maybe they have no idea what they're doing, but insiders are always a massive source of breaches. Don't minimize that; accept it.
And second, I said "risk management". Risk management not only looks at probability of breach but at the probability of a judicial or (worse) a legislative response to the breach. If you rely upon security by obscurity, you have to assume that someday, you'll be deposed by an attorney who will want to find out how you protect those secrets.
That gets tough because protecting secrets is notoriously difficult, even for government organizations with massive budgets for employee screening and training. It's not impossible, but it's so difficult that you should assume that the probability of a secret remaining secret is close to zero.
And, this is where obscurity by obscurity get complicated. It's very hard to tell if a secret has leaked. So, when do you revoke a secret? There is always an organizational cost to changing a secret, yet there is potentially a massive organizational cost to holding onto a secret for too long. That looks too much like a coin toss to me and I don't like playing odds like that.
Instead, I like playing the odds by using trusted algorithms and protocols to protect secrets and backing those trusted algorithms and protocols up with some hardcore monitoring, solid policy and well drilled process.
I won't be rolling out my own crypto of course. I like to use existing known parts. But add some slight improvements of my own. Customizations to my use-case. It's a layered defense approach against attackers. The point is to make them work hard.
The idea was to have a simple encrypted storage of markdown (or something similar, I actually prefer Asciidoc myself) files, with possible binary attachments. I wanted to build in a break-the-glass function: if something goes wrong somebody authorized can click a button at which point all alarms start ringing but the person can read the contents (perhaps after a certain time delay during which opening can be prevented).
Would be great for secrets, emergencies, and also for non-tech uses.. wills for example :)
(if someone decides to build this just let me know because I'd totally use it :P )
You might also consider https://github.com/StackExchange/blackbox which does the same job in a similar way.
Sorry, couldn’t resist.
More on "secrets at scale" from recent Real World Crypto 2018 talks:
https://rwc.iacr.org/2018/
I've found it pretty easy to set up, use, and not think about it. It's great for integrating with AWS IAM and whatnot.
[1]: https://github.com/segmentio/chamber
[2]: https://aws.amazon.com/blogs/mt/the-right-way-to-store-secre...