AWS secrets manager or SSM or KMS for any kind of secrets, keys etc. Works well because our entire stack is on AWS. Otherwise hashicorps Vault would do I guess but that’s yet another service on life support.
Ask HN: How does your company manage its encryption keys?
81–90 of 246 posts
Re: Ask HN: How does your company manage its encryption keys?
#82We use shh for secrets (https://egt.run/shh).
It's designed to integrate really well with your existing CLI tools like vim, xargs, and diff. It offers user-based permissions, and secrets are encrypted into a single file that's safe to commit into your git repo. We can stream secrets out of it directly to our remote servers during deploys.
Unlike Vault you don't need to manage infra to run it -- it's just a file. Unlike cloud secret managers, there's no lock-in.
Re: Ask HN: How does your company manage its encryption keys?
#83I worked in a place that had a very nice in-house blade server setup with an attached NAS, which was encrypted (at rest, on storage).
This was early in the “cloud” epoch and at any rate they preferred in-house iron for entirely understandable reasons. Also, they needed to do some pretty interesting things, so they had a NAS populated with enterprise-grade SSDs and a native AES-based encryption scheme. This kept the key on what was basically a glorified USB key.
(For those of you who wish to know these details, the network between the blades and between the blades and the NAS was a nicely spec’d fibre channel network, and there was some iSCSI involved. The blades featured Itanium processors, which kind of gives the manufacturer away, and the firm had invested quite heavily in producing very high-performance code for those ill-fated microprocessors, but I digress.)
So... it happened that somebody lost the USB key. Well, not quite. Somebody took it home during a weekend (whilst the system was shut down) and their kid used it for school work.
This proved to be a “significant problem”. There was a backup, and it was encrypted and stored on an adjacent SAN. It wasn’t exactly stale, but it wasn’t entirely pristine either.
There was much woe and gnashing of teeth.
Nobody was fired because the dolt who maintained custody of the only USB key was the founder/CEO, so he couldn’t exactly blame himself.
But, yeah. That happened, sadly.
Re: Ask HN: How does your company manage its encryption keys?
#84The new Google secret manager is a pretty nice way of having an easy to use web interface protected by IAM, with a REST API for applications to pull. You could easily prevent users from deleting keys. It's not as hardcore as Vault but it's a much simpler way of getting keys out of source control IMHO. You can have 2FA and audit logs easily too. Simpler than Google KMS too.
Re: Ask HN: How does your company manage its encryption keys?
#85We use Azure KeyVault
+1
Worth noting accessible using api via REST https://docs.microsoft.com/en-us/rest/api/keyvault/
and powershell https://docs.microsoft.com/en-us/azure/key-vault/secrets/qui...
Re: Ask HN: How does your company manage its encryption keys?
#86Earlier quoted context omitted.
Especially convenient with KMS auto-unsealing ( https://learn.hashicorp.com/vault/operations/ops-autounseal-... )
The KMS autounseal is especially convenient, but you have to know that there is no silver bullet in crypto. You are trading off the convenience of the auto-unseal (and frankly, the fact that this can happen automatically in the middle of the night when your server reboots) against the security of your root unseal key itself. The only thing protecting the unseal key is access to your KMS. So one rogue SRE can unseal t…
And for the rogue dev you have CloudTrail/AuditLogs.
I find it hard to build initial trust in the system, without involving the trust of an administrator + subsequent automation.
Re: Ask HN: How does your company manage its encryption keys?
#87We use Azure KeyVault
+1 Worth noting accessible using api via REST https://docs.microsoft.com/en-us/rest/api/keyvault/ and powershell https://docs.microsoft.com/en-us/azure/key-vault/secrets/qui...
I also use this for my passwords https://news.ycombinator.com/item?id=22316520
Re: Ask HN: How does your company manage its encryption keys?
#88Lots of decent advise here already...be wary of a complicated (fancy product) approach and security theater....frankly when it comes to secret management the KISS principle should apply, with the caveat that it should be secure of course.
Re: Ask HN: How does your company manage its encryption keys?
#89Someone at my company generated the keys. They then put them on a network share without any security restrictions. They've been there for 5 years with no rotation. At least 2 are checked into source control.
If this is a public repo then you are already hacked. There are multiple automated systems that scan public repos for credentials. 5 minutes later you are mining bitcoins for them.
In a boneheaded movei I accidentally committed my SendGrid creds to GitHub. Pretty quickly after, GitHub alerted me. However by then my SG account was sending thousands of automated spam messages. Those automated scammer systems are FAST.
Not particularly germane to the discussion, but really disappointed in how SendGrid handled things. I notified them immediately, rotated all API tokens, and tey could not turn it off, so the spammer sent messages for days and eventually my SG account got suspended.
Re: Ask HN: How does your company manage its encryption keys?
#90Someone at my company generated the keys. They then put them on a network share without any security restrictions. They've been there for 5 years with no rotation. At least 2 are checked into source control.
We have very simmiliar issue. All our databases have password Qwerty1234 Android keystore is checked in repository with access key in scripts. Security keys for external services are also checked in into repository. Some external services for production are managed by devs that are long time ago not working in our company
Hehe. Less than 8 years ago I asked for help to add a column in a database at a company I helped. This was a few days after they met me for the first time.
The company solved this by giving me a root username and password that worked on every single important database in the company, at least every customer database.
I had to beg them to create a somewhat restricted account.
The same company was however deeply sceptical to all kinds of remote work. The security equivalent of penny wise pound foolish I guess :-]