Y HN SearchHacker News Search

new|comments|top|jobs

loading thread…

6 ms·

Ask HN: How does your company manage secrets like API keys?

40 points by danenania 9y ago

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

nly 9y ago
badly
howToLearnSpark 9y ago
https://www.vaultproject.io https://www.vaultproject.io and so should you
- insomniacity 9y ago
  Well, maybe not the founder of envkey... he might have colleagues depending on him :)
  - danenania 9y ago
    I'm actually a big fan of Vault and greatly respect/look up to the Hashicorp team :) I 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.
- scarface74 9y ago
  I don't "get" Vault I just played with it a little bit. I'm all in on Consul and Nomad and we are using them now for production. Right now, I'm encrypting sensitive values in Consul for expediency. I'm going to implement Vault with an AWS back end eventually.
stabbles 9y ago
pass [1] is great. The simple folder structure is great, it's built on git, it works with multiple pgp keys, and different folders can have different keys. [1] https://www.passwordstore.org/ https://www.passwordstore.org/
johnnyballgame 9y ago
No offense, but anyone who is serious about securing their keys is not going to plop that information into a Google form.
- jasonpeacock 9y ago
  Anyone who is serious about securing their keys is not going to rely on security through obscurity. Any good design should be able to withstand public scrutiny.
  - johnnyballgame 9y ago
    Who said anything about relying on it? But feel free to hand over your specific security details to someone you don't even know. And make sure to attach your email address as on the form. :)
    - danenania 9y ago
      To be clear, the company name/email field is optional. It's included so that I can reach out to folks who may be interested in discussing this in more depth or want to improve their approach. 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.
    - hluska 9y ago
      From a risk management point of view (I'm over 40 so I can say that with a straight face), relying on obscurity for key management is an unbelievable shitshow. If you rely on nobody knowing how you store your keys to protect your keys, you might find yourself obligated to change how you store your keys every single time that someone quits. 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.
      - agnivade 9y ago
        So your only argument is that if someone quits, the secrets will spill out ? 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.
nsaje 9y ago
https://github.com/Zemanta/go-secretcrypt https://github.com/Zemanta/go-secretcrypt
deleted 9y ago
[deleted]
gregopet 9y ago
I started building a tool like this for internal use last year, but it was too busy to actually get something noteworthy done, now I would have to get motivated again. 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 )
fanf2 9y ago
We aren’t quite sorted enough to use hashi vault everywhere, so a few of our teams are using https://dotat.at/prog/regpg/ https://dotat.at/prog/regpg/ which is a wrapper around gpg that enormously simplifies key management, in a way that works well with a version control system. It has hooks to work with git and ansible, because that’s what we use, but the core functionality can work with other tools equally well. You might also consider https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox which does the same job in a similar way.
nitely 9y ago
AWS KMS
ppetty 9y ago
I’m not telling … Sorry, couldn’t resist.
drcongo 9y ago
I wish KeyBase would take it on.
indescions_2018 9y ago
Vault. AWS KMS. GCloud KMS & IAM. More on "secrets at scale" from recent Real World Crypto 2018 talks: https://rwc.iacr.org/2018/ https://rwc.iacr.org/2018/
diaz 9y ago
Always keeping the best practices that were already in place... So obviously not good :D
ojhughes 9y ago
CredHub had been developed by folks at Pivotal to manage secret storage and generation, in an arguably more opinionated way than Vault https://github.com/cloudfoundry-incubator/credhub https://github.com/cloudfoundry-incubator/credhub
jamesmishra 9y ago
We use Segment's chamber[1] as a frontend to AWS System Manager Parameter Store[2]. 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 https://github.com/segmentio/chamber [2]: https://aws.amazon.com/blogs/mt/the-right-way-to-store-secrets-using-parameter-store/ https://aws.amazon.com/blogs/mt/the-right-way-to-store-secre...
AdamMills 9y ago
https://github.com/AGWA/git-crypt https://github.com/AGWA/git-crypt
panjaro 9y ago
We print it in a paper, seal it in envelope and give it to company owner. He then keeps it in his Safe.
lmlsna 9y ago
Paste into word doc.

hluska 9y ago
First, in practice, don't ever minimize the risks of an employee spilling secrets. Employees are a massive source of leaks. Some good research suggests that 60% of data breaches are caused by employees. 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.
- agnivade 9y ago
  Thanks. Good points. 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.