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

Lock Up Your Customer Accounts, Give Away the Key

technologyadvice.github.io

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Lock Up Your Customer Accounts, Give Away the Key

#21

Post by hellbanner »

TomFrost wrote: post #11
swehner wrote: post #9

I was surprised when the author all of a sudden started talking about AWS, and clicking some kind of button that creates a key. (Besides, one would assume has been backdoored by the Amazon staffers anyway)

Is there a basis for such an assumption? For an organization requiring the highest available security, the ideal solution would be a privately operated hardware security module kept off the DMZ. However, that, as well as the idea of self hosting (and maintaining) the entire dev, test, deploy, and prod stack suggested by another commenter, isn't always within reach of a small, agile team looking to focus on their core…

Re: your first line, yes: the existence of https://aws.amazon.com/govcloud-us/pricing/ -- and we know how the US Gov feels about computers.

Re: Lock Up Your Customer Accounts, Give Away the Key

#22

Post by tjohns »

swehner wrote: post #9

I was surprised when the author all of a sudden started talking about AWS, and clicking some kind of button that creates a key. (Besides, one would assume has been backdoored by the Amazon staffers anyway)

I had the same reaction.

Looking at the docs, it looks like the master key source is pluggable, so you don't have to use Amazon's KMS... but none of the other options inspire confidence (local file, fetch from URL, plaintext password, or no password).

At the very least, I'd like to see a plugin for using a key stored on a local TPM chip -- which almost any modern bare-metal server would be equipped with.

Re: Lock Up Your Customer Accounts, Give Away the Key

#23

Post by [deleted] »

patio11 wrote: post #2

There's a reasonable case for including internal actors in one's threat model for larger companies or ones working in extraordinarily sensitive product domains. Most startups probably don't need to prevent the team from being able to read credentials, because that's theatre when they have 15 different ways to get to any secret the company has. We use Ansible's vault feature to decrypt a few centralized secret files o…

[deleted]

Re: Lock Up Your Customer Accounts, Give Away the Key

#24

Post by yeukhon »

ultramancool wrote: post #6
timdierks wrote: post #3

This article confuses me. The author tears down a strawman argument about running centralized key services ("The expensive solution"), then recommends exactly such a solution in Amazon KMS. The only plausible way this can make sense to me is if he said "Running your own key service is a pain, use Amazon KMS". But that's a simple service question, probably wouldn't have taken up as much space.

Not only that, but everything here except for the engineers question can also be solved by simply hosting these things yourself. You don't need 3rd party code hosting on Github, just use Gitlab or JIRA. You don't need some external CI service, run your own Jenkins node. Chat and email should also be internal (we use XMPP, a local Mattermost instance would be an alternative) and SSL-only. You can do all of this with b…

I argue security starts with being paranoid. Not that I don't trust anyone I work with, including myself, but I can leak emails or my computer can get hacked. Shit happens. So I would start with the worst case and ask myself how to defend against any leaks.

External service SLA can be joke. It's always aftermath thought. Damage control is always on the customer side because customer has to rotate / invalidate leaked credentials, so first step for me is to have a process to invalidate credentials as often as possible.

Re: Lock Up Your Customer Accounts, Give Away the Key

#25

Post by netheril96 »

Every time I see some one touts AES as the reason that their encryption is secure, I want to ask, in what mode? CBC, CFB, CTR or (the best) GCM? How is the IV generated? Are there any potential padding oracles? If they don't even understand these questions, then it is obvious that AES cannot save them at all.

Re: Lock Up Your Customer Accounts, Give Away the Key

#26

Post by rpedela »

timdierks wrote: post #12
TomFrost wrote: post #7

Earlier quoted context omitted.

KMS is not a centralized secret database -- it's a hosted Hardware Security Module. There is no way to store your service's secrets in it for later retrieval, unlike the solutions listed in the article. I suppose an argument could be made that it still provides a single point of failure, however the risk level of KMS and the SLA it provides is far lower than what one might encounter by maintaining their own server cl…

AWS KMS does not use HSMs. Amazon says it runs on HSAs ("hardened security appliance"), but they don't provide a lot of info on what that means. I would presume that the only thing keeping a limited number of Amazon employees from accessing your keys is policy. I agree that using AWS KMS is the same architecture as using some other KMS that you run yourself, you just garner the benefit of their software and operation…

It literally says AWS KMS uses HSMs in the introductory paragraph.

https://aws.amazon.com/kms/

Re: Lock Up Your Customer Accounts, Give Away the Key

#27

Post by homakov »

javajosh wrote: post #19
aytekin wrote: post #10

One solution we came up was to encrypt data before it is submitted and let the user have the private key. The private key is never transferred to our servers. (Generated on browser, kept by the user and used on the browser.) http://www.jotform.com/encrypted-forms/

I really like this solution, but it is still quite vulnerable to an inside job. To wit, if someone at jotform wanted they could poison the page, and recover the private key (or the data directly). To address that you need process isolation between the storage of the cyphertext and the manipulation and use of cleartext. This eliminates the browser since for all intents and purposes it is not an isolated process. (You…

It does make exploitation harder (need to change JS) so it's good enough. There are no other usable options anyway.

Re: Lock Up Your Customer Accounts, Give Away the Key

#28

Post by timdierks »

rpedela wrote: post #26
timdierks wrote: post #12

Earlier quoted context omitted.

AWS KMS does not use HSMs. Amazon says it runs on HSAs ("hardened security appliance"), but they don't provide a lot of info on what that means. I would presume that the only thing keeping a limited number of Amazon employees from accessing your keys is policy. I agree that using AWS KMS is the same architecture as using some other KMS that you run yourself, you just garner the benefit of their software and operation…

It literally says AWS KMS uses HSMs in the introductory paragraph. https://aws.amazon.com/kms/

I'm relying on https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Detai.... There are HSMs, I guess, but they'r only used to back up the keys when they're stored offline for durable backups. I hadn't seen the claim on the main page, but I'd consider it to be misleading, presuming that the cryptographic details whitepaper didn't totally misstate the design.
Post reply on HN