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

211–220 of 246 posts

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

#211

Post by meddlepal »

bkandel wrote: post #200
ganstyles wrote: post #89

Earlier quoted context omitted.

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…

So this has happened at more than one company that I've been at, only difference is that these were AWS keys and used to mine bitcoin. AWS was actually pretty good about it, we rotated the keys as quickly as we could and they dropped all the charges.

I once worked for a co-founder who despite all the warnings I gave about not committing infra credentials to source control still went ahead and explicitly committed credentials to public source control because "the developer experience was better".

The CEO was not pleased with the 30K (or maybe it was 60K) bill... and I just pointed at the CTO and was like "I fought this battle and was overruled"

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

#212

Post by ransom1538 »

My humble security advice:

1) If you don't need it - don't store it. If you need it - but it needs to be encrypted - probably! don't store it.

2) Think one way hashes with salts, think deletion policies, rotations, small disk drives.

3) You will get owned!!

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

#213

Post by kevindong »

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

Google's KMS pricing structure is $0.06/key/month + $0.03/10,000 encrypts/decrypts [0].

At $0.06/key/month, that's practically free for most reasonable use cases. For example, if there's 10k secrets that's $7,200/year.

If you encrypt/decrypt your secrets 1 million times per day (~11.6 times/s), the access charges would be $1,095/year (1 million operations/day * 365 days/year * $0.03 / 10,000 operations).

[0]: https://cloud.google.com/kms

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

#214

Post by mb7733 »

meddlepal wrote: post #211
bkandel wrote: post #200

Earlier quoted context omitted.

So this has happened at more than one company that I've been at, only difference is that these were AWS keys and used to mine bitcoin. AWS was actually pretty good about it, we rotated the keys as quickly as we could and they dropped all the charges.

I once worked for a co-founder who despite all the warnings I gave about not committing infra credentials to source control still went ahead and explicitly committed credentials to public source control because "the developer experience was better". The CEO was not pleased with the 30K (or maybe it was 60K) bill... and I just pointed at the CTO and was like "I fought this battle and was overruled"

The most frustrating part of this is that the developer experience isn't better when you check credentials into source control.

It seems convenient until the credentials change (which they ought to now and then). Then when you check out an old revision of the project, it is broken. You end up having to copy and paste the new creds back in time and it's finicky as hell.

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

#216

Post by baby »

zemnmez wrote: post #97
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 h…

I'm always a bit antsy about Vault. You do end up having all your secrets in one place.

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

#217

Post by dfc »

ransom1538 wrote: post #212

My humble security advice: 1) If you don't need it - don't store it. If you need it - but it needs to be encrypted - probably! don't store it. 2) Think one way hashes with salts, think deletion policies, rotations, small disk drives. 3) You will get owned!!

I agree with only store what you need. But I can't think of many things in a professional setting that a company should store but not encrypt.

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

#220

Post by XorNot »

The dream for me has always been to get LDAP/Kerberos tied into container/VM orchestration, and do everything that way with per-instance accounts.

LDAP is ubiquitous enough as an auth method (how do you auth to Vault? You auth to LDAP with it...) that any service you run or use is likely to speak it.

Why this isn't done more often is a mystery to me and probably the number 1 source of credentials being baked into things accidentally: oh we need a service account into the which uses Active Directory.

Might have answered my own question there though.

Post reply on HN