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

Ask HN: How does your company manage its encryption keys?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 246 posts

Re: Ask HN: How does your company manage its encryption keys?

#91

Post by jabart »

ganstyles wrote: post #89
panpanna wrote: post #37

Earlier quoted context omitted.

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 of…

My SG API keys, for an account that we terminated still send out emails if I happen to use an old config for a service.

IP Rules are super helpful in this case, still need to rotate when exposed but can limit the exposure.

Re: Ask HN: How does your company manage its encryption keys?

#92

Post by CiPHPerCoder »

NovemberWhiskey wrote: post #60
hn_throwaway_99 wrote: post #42

I highly second the people saying KMS (AWS KMS, Google KMS, or KeyVault). * The pricing for just storing keys is incredibly cheap. * At least with Google KMS you can't delete the keys without a 24 hour waiting period (and you can alert on the deletion attempt), so that's a huge safeguard. * You get key access auditing out of the box.

This is fine if you're committed to using (say) AWS KMS for your encryption needs as a service with its per-API-call pricing. The costs of that obviously scale in a completely different way from the per-key storage costs (which are actually zero, I think).

If you use the AWS Encryption SDK, you can cache your data keys and reduce your calls to KMS: https://docs.aws.amazon.com/encryption-sdk/latest/developer-...

Re: Ask HN: How does your company manage its encryption keys?

#93

Post by CiPHPerCoder »

2mol wrote: post #62
hn_throwaway_99 wrote: post #42

I highly second the people saying KMS (AWS KMS, Google KMS, or KeyVault). * The pricing for just storing keys is incredibly cheap. * At least with Google KMS you can't delete the keys without a 24 hour waiting period (and you can alert on the deletion attempt), so that's a huge safeguard. * You get key access auditing out of the box.

Can you easily set up policies that prevent deletion of keys?

Yep: https://asecure.cloud/a/scp_kms_delete_keys/

Re: Ask HN: How does your company manage its encryption keys?

#94

Post by pnutjam »

nocman wrote: post #71
nihil75 wrote: post #54

We use cloud-provider managed encryption because we're not paranoid and don't have legal requirements to manage our own keys. We don't have SSH keys because it's not the 90's and we don't have servers.

> We don't have SSH keys because it's not the 90's and we don't have servers. This seems unnecessarily snarky. There are lots of businesses in 2020 that still maintain their own servers, use ssh keys, and are staffed by admins and developers who very much know what they are doing (and are not at all "behind the times", as this comment seems to imply such businesses are). If that's not what you meant, well, OK, but I…

He'll learn...

probably the hard way.

Re: Ask HN: How does your company manage its encryption keys?

#95

Post by Ididntdothis »

dijit wrote: post #49
thieving_magpie wrote: post #32

Earlier quoted context omitted.

We make no distinction between dev keys and production. Consider them production. Since it's of interest to HN, I am working on educating our very small team on how keys should be protected and used. I am the youngest developer by about 15 years. It's a very rural company and it often feels like all learning and passion for development stalled around 2005. It's a company that gave me a chance to grow into a developme…

aha, sounds fair. I don't judge too harshly- anyone who has black and white principles on these matters has never worked in any other industry most likely... all you can do is your best to steer the ship and convey the downsides. I think it's important too because it helps us understand how much friction people will tolerate. In many cases, even a small amount of friction will cause people to stop functioning complet…

One thing i have noticed is that “security conscious” people are very good at criticizing things and pointing out flaws. But they are not as good at proposing clear and workable solutions that don’t add huge burden to users.

It should be no surprise that people do insecure stuff under deadline pressure.

Re: Ask HN: How does your company manage its encryption keys?

#97

Post by zemnmez »

toomuchtodo wrote: post #4

https://www.vaultproject.io/ We use Hashicorp's Vault product to manage SSH credentials, TLS certificates, as well as application secrets across thousands of users, tens of thousands of virtual machines, and hundreds of applications. We pay for the enterprise version, but the free version is more than capable for most needs. Avoid a password manager if you can, it leads to poor security practices and availability iss…

This is the best answer I know of. A secret management system is what you want, for several reasons:

1) Secrets checked into code means when the code gets stolen, this is an unimaginably major breach. Code tends to get stolen eventually and most tech shops will never know / only know years later because they don't have access to the channels who will sell your code.

2) You can track secrets you have in storage, who has access and who is using them

3) When a secret does get stolen, they can be rotated with ease. You do not want to be spending on the order of man months manually auditing a huge code base and manually indexing and rotating every secret. With good setup you can do this without taking any systems down.

4) Most support HSM / KMS systems which encrypt the data using a key in a hardware security module, which, in theory the key cannot physically leave – the HSM will re-encrypt all your other keys. The HSM, if used properly can be a continuous bottleneck to decrypting any information, meaning, if your encrypted objects are stolen, the attacker needs active access to your (e.g. AWS) KMS system to decrypt them.

Password managers are good for individual users, but provide bad security characteristics for development and deployment.

AWS Secrets manager, AWS's competitor to Vault used a similar system I worked on that was developed within Twitch for this purpose.

Re: Ask HN: How does your company manage its encryption keys?

#98

Post by [deleted] »

2mol wrote: post #62
hn_throwaway_99 wrote: post #42

I highly second the people saying KMS (AWS KMS, Google KMS, or KeyVault). * The pricing for just storing keys is incredibly cheap. * At least with Google KMS you can't delete the keys without a 24 hour waiting period (and you can alert on the deletion attempt), so that's a huge safeguard. * You get key access auditing out of the box.

Can you easily set up policies that prevent deletion of keys?

[deleted]

Re: Ask HN: How does your company manage its encryption keys?

#99

Post by speedgoose »

We save the keys in a cloud vault. For the most important keys I also print them on paper, in text and in a QR-Code (that I generate with an offline tool). It is then placed into a physical safe. This is in case we lose access to our cloud vault, or if the keys are deleted from the cloud vault.

Re: Ask HN: How does your company manage its encryption keys?

#100

Post by mpfundstein »

thieving_magpie wrote: post #14

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

like every startup ever

in the last startup I worked, all jwt tokens were created from a 10 letter long shared "secret" stored in json config files all over the place :p

even dev environments had same key lol

Post reply on HN