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

Very Good Security

a16z.com

Post reply on HN
Print view View original

71–80 of 94 posts

Re: Very Good Security

#71

Post by Artemis2 »

danenania wrote: post #32

EnvKey[1] takes a somewhat similar approach to securing credentials/config in that we effectively replace your config with a short token that can be set as an environment variable. This then 'expands' into your full configuration when it's needed. But the crucial difference is that instead of storing sensitive data in plaintext ourselves and then sending out access tokens, we manage an OpenPGP PKI/web-of-trust for yo…

Looks cool! I can very much appreciate progress in this space. I haven’t been able to find this info by skimming the website: while I understand that the user ultimately holds the keys that can decrypt the secret, how do you prevent this key from becoming the weakest link? Assuming the worst, users could just store their key where they used to store their secrets before EnvKey (like app environment)?

Something I appreciate very much about running in the cloud is being able to use the control plane’s APIs to authenticate requesters (e.g. Kubernetes API + Service Accounts or AWS IAM + Instance Roles). Does EnvKey have anything in the way of that?

Regarding PCI compliance: if card data is encrypted, the scope of compliance simply moves over to the keys :-)

Re: Very Good Security

#72

Post by mixmax »

tptacek wrote: post #46

This doesn't say anything. They invested in a tokenization company. That's not a new or interesting technology. What am I missing? There are interesting data security companies happening right now. For instance, Matthew Green is doing Zeutro, an ABE company. Think of ABE as Shamir's Secret Sharing on Steroids: you can encrypt data and delegate it out to different people based on boolean expressions. That at least add…

your comment reminds me of the commentary on Drew Houston's announcement of a product called dropbox (you might have heard of it...) here on HN 10 years ago. (1)

"This is nothing new", "I could build this myself", "you have to install something, nobody does that", etc. etc.

The key to a successful company is not being first, not (only) having a great technical solution, and not having tech noone else does.

The key is an umbrella of technology, business sense, marketing ability, salesmanship and much more. Andreeses/Horowwitz probably see a whole umbrella, and not only the tech.

(1) https://news.ycombinator.com/item?id=8863

Re: Very Good Security

#73

Post by drdaeman »

mdpopescu wrote: post #55
drdaeman wrote: post #37

Earlier quoted context omitted.

This sounds weird. What kind of software engineer in their sane mind would want to stay in the US illegally (I don't think one can get any long-term tourist visa?) _and_ get paid peanuts? Even if they really want to live in the US, being poor sounds like a very strange sacrifice. Unless one's a junior developer (where I heard it's hard to compete those days), as far as I know there are a lot of realistic options to f…

I actually went to the US in that exact scenario - tourist visa, six months, paid peanuts. (This was back in 2000.) Until then, it had been a dream of mine to visit the US and that accomplished that dream. I have fond memories of that time and I would revisit... but I'll wait until things return to how they were back then. (Start at "no TSA" and go from there.)

Makes sense, thanks. Yes, no doubt US is a good country and one can wish to live there.

I didn't knew tourist visas can be as long as 6 months - thought they're normally shorter.

Yet, this is still odd to me (just me). As far as I get it, if you're caught, you're banned from visiting the country again, and for a long while. Feels like a bad way to end a dream.

It must be that my subjective perception of the risks involved overweighted the positive aspects.

Re: Very Good Security

#74

Post by [deleted] »

mixmax wrote: post #72
tptacek wrote: post #46

This doesn't say anything. They invested in a tokenization company. That's not a new or interesting technology. What am I missing? There are interesting data security companies happening right now. For instance, Matthew Green is doing Zeutro, an ABE company. Think of ABE as Shamir's Secret Sharing on Steroids: you can encrypt data and delegate it out to different people based on boolean expressions. That at least add…

your comment reminds me of the commentary on Drew Houston's announcement of a product called dropbox (you might have heard of it...) here on HN 10 years ago. (1) "This is nothing new", "I could build this myself", "you have to install something, nobody does that", etc. etc. The key to a successful company is not being first, not (only) having a great technical solution, and not having tech noone else does. The key is…

[deleted]

Re: Very Good Security

#75

Post by mvpu »

This type of things are better off delivered as an SDK rather than a 3rd party API. Sending sensitive data to VGS for encryption would be a non-starter for many companies.. the probability of data getting stolen is same for VGS or anyone else...

Re: Very Good Security

#76

Post by danenania »

Artemis2 wrote: post #71
danenania wrote: post #32

EnvKey[1] takes a somewhat similar approach to securing credentials/config in that we effectively replace your config with a short token that can be set as an environment variable. This then 'expands' into your full configuration when it's needed. But the crucial difference is that instead of storing sensitive data in plaintext ourselves and then sending out access tokens, we manage an OpenPGP PKI/web-of-trust for yo…

Looks cool! I can very much appreciate progress in this space. I haven’t been able to find this info by skimming the website: while I understand that the user ultimately holds the keys that can decrypt the secret, how do you prevent this key from becoming the weakest link? Assuming the worst, users could just store their key where they used to store their secrets before EnvKey (like app environment)? Something I appr…

Thanks! Yeah, the key still needs to be protected--the benefit is that you minimize the number of secrets you need to deal with, but it unfortunately isn't possible to avoid managing some kind of secret entirely. That said, using a token instead of storing the secrets directly also allows for additional access control (say by IP range), quicker/more effective revocation and rotation, and makes it trivial to keep developers and infrastructure in sync (this was always a major problem in my experience with approaches like 12 factor).

We're definitely interested in other authentication approaches that leverage pre-existing cloud credentials/roles, but for now are sticking with the simplicity/universality of an environment variable, since just about every platform supports them, and access is generally coupled to server-level access.

Integrating with Kubernetes in particular is very straightforward--you just set an ENVKEY secret, expose it as an environment variable to your pods, install envkey-source[1] in your containers, and then run a single line `eval $(envkey-source)` to inject your config. Or to make it even simpler, one of our users has figured out an approach that avoids the need to install envkey-source/eval it in your container at all[2].

"Regarding PCI compliance: if card data is encrypted, the scope of compliance simply moves over to the keys :-)"

True enough! This could also be said about e.g. your Stripe secret key, though you're still less screwed by having this exposed than losing the cc numbers directly.

1 - https://github.com/envkey/envkey-source

2 - https://medium.com/@dmaas/add-envkey-to-a-docker-app-in-kube...

Re: Very Good Security

#77

Post by danenania »

SahAssar wrote: post #63
danenania wrote: post #32

EnvKey[1] takes a somewhat similar approach to securing credentials/config in that we effectively replace your config with a short token that can be set as an environment variable. This then 'expands' into your full configuration when it's needed. But the crucial difference is that instead of storing sensitive data in plaintext ourselves and then sending out access tokens, we manage an OpenPGP PKI/web-of-trust for yo…

How would one interface with payment gateways without sending the cc #? I get that you are not storing it in the clear, but what if I actually have to use it?

Yeah, at some point it needs to be decrypted, but the idea is to push it to the last possible moment, and to only allow access to whichever party actually needs to make the charge.

Re: Very Good Security

#78

Post by Artemis2 »

danenania wrote: post #76
Artemis2 wrote: post #71

Earlier quoted context omitted.

Looks cool! I can very much appreciate progress in this space. I haven’t been able to find this info by skimming the website: while I understand that the user ultimately holds the keys that can decrypt the secret, how do you prevent this key from becoming the weakest link? Assuming the worst, users could just store their key where they used to store their secrets before EnvKey (like app environment)? Something I appr…

Thanks! Yeah, the key still needs to be protected--the benefit is that you minimize the number of secrets you need to deal with, but it unfortunately isn't possible to avoid managing some kind of secret entirely. That said, using a token instead of storing the secrets directly also allows for additional access control (say by IP range), quicker/more effective revocation and rotation, and makes it trivial to keep deve…

Thanks for the detailed reply! There is indeed a lot to do with authentication/authorization (and things like audit logging…). I’ll look more at EnvKey later to understand the cryptography better.

Stripe/other gateways do abstract most of PCI DSS from you, and will not return card data via API calls, so that somewhat sidesteps the compliance issue.

Re: Very Good Security

#79

Post by danenania »

Artemis2 wrote: post #78
danenania wrote: post #76

Earlier quoted context omitted.

Thanks! Yeah, the key still needs to be protected--the benefit is that you minimize the number of secrets you need to deal with, but it unfortunately isn't possible to avoid managing some kind of secret entirely. That said, using a token instead of storing the secrets directly also allows for additional access control (say by IP range), quicker/more effective revocation and rotation, and makes it trivial to keep deve…

Thanks for the detailed reply! There is indeed a lot to do with authentication/authorization (and things like audit logging…). I’ll look more at EnvKey later to understand the cryptography better. Stripe/other gateways do abstract most of PCI DSS from you, and will not return card data via API calls, so that somewhat sidesteps the compliance issue.

I look forward to hearing your thoughts--feel free to email me directly: dane [at] envkey.com

All the crypto/security details are here btw: https://security.envkey.com/

Re: Very Good Security

#80

Post by throwawaymath »

mixmax wrote: post #72
tptacek wrote: post #46

This doesn't say anything. They invested in a tokenization company. That's not a new or interesting technology. What am I missing? There are interesting data security companies happening right now. For instance, Matthew Green is doing Zeutro, an ABE company. Think of ABE as Shamir's Secret Sharing on Steroids: you can encrypt data and delegate it out to different people based on boolean expressions. That at least add…

your comment reminds me of the commentary on Drew Houston's announcement of a product called dropbox (you might have heard of it...) here on HN 10 years ago. (1) "This is nothing new", "I could build this myself", "you have to install something, nobody does that", etc. etc. The key to a successful company is not being first, not (only) having a great technical solution, and not having tech noone else does. The key is…

> "This is nothing new", "I could build this myself", "you have to install something, nobody does that", etc. etc.

Note that he didn't make any of these criticisms. What he did say is that there is little information about what the company's innovation is, and to public appearances what the company is doing is not novel. He then went on compare the company to another one with an impressive team of cryptographers behind it who developed an impressive, novel solution to the problem at hand. Further, he's made this point from a position of domain expertise in the field.

Frankly I don't think raising the spectre of famous "wrong" comments about Dropbox constitutes a meaningful response to his point. He outlined a substantive critique. In order for a criticism to be a middlebrow dismissal it has to be both middlebrow and dismissive. What you're responding to isn't, and doesn't fit the template you're invoking.

Post reply on HN