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

[2]: https://aws.amazon.com/blogs/mt/the-right-way-to-store-secre...

https://www.vaultproject.io and so should you

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.

Well, maybe not the founder of envkey... he might have colleagues depending on him :)

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.

badly

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 )

We aren’t quite sorted enough to use hashi vault everywhere, so a few of our teams are using 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 which does the same job in a similar way.

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

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/

Vault. AWS KMS. GCloud KMS & IAM.

More on "secrets at scale" from recent Real World Crypto 2018 talks:

https://rwc.iacr.org/2018/

We print it in a paper, seal it in envelope and give it to company owner. He then keeps it in his Safe.

Always keeping the best practices that were already in place... So obviously not good :D

Paste into word doc.

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.

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.

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.

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.

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.

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.

I wish KeyBase would take it on.

I’m not telling …

Sorry, couldn’t resist.

AWS KMS