
Very Good Security - jaxondu
https://a16z.com/2018/08/28/very-good-security/
======
tptacek
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 addresses a
fundamental problem in data center encryption (the fact that serverside data
encryption is "all or none" with respect to applications).

This, though? I assume the announcement means VGS is doing great in the
market. Congratulations, I guess?

~~~
mixmax
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](https://news.ycombinator.com/item?id=8863)

~~~
throwawaymath
_> "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.

~~~
twelve40
Note that he did make exactly that. "That's not a new or interesting
technology" sounds a lot like "this is nothing new" to me - direct quotes.

This may not be the latest and greatest cryptography breakthrough, but if it
helps me offload the compliance PITA and not even touch any PII ever, I'll
take it - so that my small team can focus on our main business - and no, I'm
not aware of any such general service outside of payments use case. If you
know specific examples of token proxying SaaS services, let me know! Just like
Dropbox, this solves a unique pain point for us and others like us, even
though it may not sound sexy to some people.

~~~
throwawaymath
I think the issue here is that the company does one thing and the article is
sort of grandstanding about a much larger and worthwhile problem that’s fairly
different. As another commenter said, VGS seems to be solving sales and
distribution with security baked on top. That’s useful, but it does not at all
solve the core problems outlined in the article.

So he (and I) are not rejecting this company because the technology already
exists, but because this is not a company capitalizing on that existing
technology. We’re pointing out that the company - whatever it _does_ do - does
not meaningfully resolve the problems in the article, not that the problems
don’t exist. This would be more like someone responding to Drew Houston and
saying Dropbox doesn’t in fact work as claimed. That’s not what’s being said
here.

I’m pretty sure neither of us are saying there’s no problem and to avoid this
exact criticism my top level comment specifically explained why it’s a
usability problem. There _is_ a company to be made based on “not new”
technology; this isn’t doing that.

------
danenania
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 you behind the scenes so that we're only storing
encrypted data, and only the token (which we never see in its entirety) can
decrypt it.

End-to-end encryption is _much_ harder to implement for these kinds of use
cases than simple tokenization, but there's also the huge benefit of not
needing to trust your storage layer.

With credit cards, for example, an approach like this could hypothetically
remove PCI-compliance as an issue entirely because no one is actually storing
the cc # in the clear. To me this is a lot more interesting than simply
shifting the burden of trust. That said, anything is better than our current
status quo of spraying secrets all over the place.

1 - [https://www.envkey.com](https://www.envkey.com)

~~~
Artemis2
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 :-)

~~~
danenania
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](https://github.com/envkey/envkey-source)

2 - [https://medium.com/@dmaas/add-envkey-to-a-docker-app-in-
kube...](https://medium.com/@dmaas/add-envkey-to-a-docker-app-in-kubernetes-
without-rebuilding-the-image-5c7b2775b05b)

~~~
Artemis2
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.

~~~
danenania
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/](https://security.envkey.com/)

------
vgs_interviewee
Anonymous account, because of reasons.

I interviewed and was offered a job at this company. I turned it down because
they had some of the most morally bankrupt leadership I have ever seen in a
startup. Frankly, it made me less likely to interview with YC companies at
all.

Just a quick list of giant red flags-

1\. They are violating visa laws by having their employees in the Ukraine lie
on their applications and say they are coming into the US for tourism instead
of business.

2\. The Ukrainian developers they get out here are kept on their Ukrainian
salary, with a small stipend for housing. So they get to live in the bay area
on a eastern european salary.

3\. Their CEO actually bragged to me about how little they were paying the
only female developer they had in the office. He thought it was hilarious.

4\. When they made an offer they refused to tell me how many shares had been
issued for the company or what percentage the offer included, making their
offer completely impossible to decipher. It was also about 15% lower than the
numbers they had discussed with me beforehand.

If I was an investor in this company I would demand the removal of the CEO and
put their CTO in charge.

~~~
drdaeman
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 find a legal
immigration venue to a first-world country (probably not to the US, though) -
so, why do stupid things like that?

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

~~~
drdaeman
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.

------
throwawaymath
I can see why this is an attractive idea to fund, but in my opinion it's the
wrong way to resolve the problems highlighted in the article.

This is not a technical problem, it's a usability problem. We have had the
cryptography necessary to technically fix this for a long time. Replace the
single human-memorable token (SSN) with a unique public/private key pair. Then
you provide safe authentication by signing verification messages with your
private key without placing that private key into the hands of a centralized
vendor (like Very Good Security).

The obstacle to this solution is 1) buy-in, to either get the government to do
this or to bypass it with this solution in private industry, and 2) usability,
to abstract as much of the technical signing process away from the user as
possible. But this _is_ a better solution. From what I can understand of Very
Good Security's website, it's just more of the same. It wants to become the
secure gatekeeper of sensitive data instead of developing a novel means of
obviating that problem entirely.

The _real_ company to fund is one which takes inspiration from an existing
cryptographic protocol - like ApplePay's or AndroidPay's - and expands it to
handle identity verification and one-time payment authorization without
requiring an SSN or canonical credit card.

~~~
PowerfulWizard
I think it is an example of great preconditions for starting a company, even
though it will be very challenging to make it work well. Basically, our
technology is advanced enough to do this, but it so complicated that the
percentage of people who can use it, rounding to the nearest, is 0%. I see it
as similar to the situation with Dropbox when it was started, where it was
possible to accomplish the same thing yourself -- if you have expert level
ability in that specific area.

Observing how people get along with cryptocurrency wallet software, key
management is a hurdle that many will fail to clear.

~~~
throwawaymath
What you're saying is precisely why I'm saying it's a usability problem, not a
technical one. We have the technology, yes. _This_ company is _not_ that
technology. The company we should fund is the one that solves the usability
problem, not one which moves the goalposts to a different centralized point of
failure.

The ideal solution would look like the ApplePay protocol - there is a PKI and
cryptographic authentication, but users (and receiving vendors) never need to
know what a digital signature even is. I agree with you that trying to get
users to handle their own key management is a complete non-starter.

------
CiPHPerCoder
H(ssn) just kicks the problem downstream.

    
    
      - If H is a simple cryptographic hash function, it's not resistant
        to brute-force attacks to recover the SSN
      - It's not revokable
    

What we need is something more akin to a Credit Card number. Something like an
abstraction layer. It might even be implementable as a UUID.

If you need to revoke it, you can do so since it's not cryptographically tied
to anything.

Failing that, a base32-encoded random string (without = padding) with an
optional checksum would do the trick.

~~~
mahmoudimus
(disclaimer: I work at VGS)

We offer a variety of various format preserving aliasing algorithms. Only
legacy systems tend to choose the SSNs if they have fixed-width columns in
their RDBMS that are difficult to change (imagine petabytes of data).

The idea behind format preserving aliases is actually based on the NIST SP
800-3G standard[1]. We use FF1 and are actively engaging with the world's
leading cryptographers such as:
[https://cryptoonline.com/publications/](https://cryptoonline.com/publications/).

Happy to share more in detail if there's interest. Please email me: mahmoud @
${COMPANY_NAME}.com

[1]
[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38G.pdf)

~~~
miketery
Please provide an example of an RDBMS with petabytes of data. Seems unlikely.

~~~
GFischer
NASDAQ had a 2 Petabyte Microsoft SQL Server.

[https://customers.microsoft.com/en-us/story/nasdaq-omx-
group...](https://customers.microsoft.com/en-us/story/nasdaq-omx-group-
reduces-2-pb-of-data-to-500-tb-with-m)

------
mdpopescu
I find it interesting that Stefan Brands [1] solved the zero-knowledge
authentication problem a couple of decades ago and his tools are still not
widely applied. Given my bias against imaginary property, I believe that's
because his patents on them are still valid -- and apparently owned by
Microsoft at the moment [2].

[1]
[https://en.wikipedia.org/wiki/Stefan_Brands](https://en.wikipedia.org/wiki/Stefan_Brands)
[2]
[http://financialcryptography.com/mt/archives/001011.html](http://financialcryptography.com/mt/archives/001011.html)

~~~
lisper
> Stefan Brands [1] solved the zero-knowledge authentication problem a couple
> of decades ago

Reference? If you want people to take you seriously when you claim that
someone's solution to a problem has been overlooked you have to provide a link
to the (alleged) solution, not just to the author's biography.

~~~
erpellan
See also: [https://www.researchgate.net/scientific-
contributions/354493...](https://www.researchgate.net/scientific-
contributions/35449372_Stefan_Brands)

Although I hadn't heard of Stefan Brands before, I wasn't surprised he'd
worked with David Chaum, who is the person I first think of regarding zero-
knowledge proofs:
[http://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurity...](http://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-
blind-signatures.PDF)

Then I get depressed because we had anonymous digital cash 20 YEARS AGO and
fucked it up.

Software patents are bad, crypto patents are worse. It's (almost) literally
patenting math.

------
robert204
Doesn't this mean VGS becomes the single point of failure and a larger target
for malicious actors?

~~~
mahmoudimus
(disclaimer: I work for VGS)

Hi robert204,

Your question has two specific parts that I want to address:

1) Single Point of Failure

2) Larger target for malicious actors

Regarding point #1:

\- We have invested significant amount of resources in making our product as
stateless as possible and our core product can live on different cloud
providers' edge networks.

\- We conduct failover tests every 2 weeks to ensure we have the capability to
respond to any blips in downtime. Our SOC2 Type2 report is available to
discuss the availability and disaster recovery items in detail.

\- As a side note: We solve the issue of the "vendor is down" problem -- for
example, we have customers who seamlessly switch between providers, say credit
score checks, when one of them is down without the liability of storing that
data themselves.

Regarding point #2:

\- This is our core focus. We take on the liability. The idea here is if this
is the core focus, we can do this better than a lot of folks out there.

\- We also broker access to different Fortune 500 institutions that visit our
offices and constantly pen-test us, audit us, etc.

I think it's important to acknowledge that as developers security is always
important, but never prioritized until its urgent. We are trying to change
that @ VGS.

Please, email me directly and I'm happy to have a further chat: mahmoud @
${COMPANY_NAME}.com

~~~
fefe23
You had me at "cloud providers". If you store the data on some cloud provider,
then you are just as bad as what your prospective customers are doing.

I don't want any of my sensitive data stored on "some cloud provider".

Also, your security strategy apparently boils down to "we'll be REAL CAREFUL,
pinky swear!"

That strategy does not work, and has never worked before. The whole reason why
you think your product is needed is because your prospective customers do it
just like that.

I'm stunned you found investors with this proposition.

~~~
wepple
I’m curious, what’s wrong with storing this type of data in a cloud provider?

Also, security aside wouldn’t a16z have invested because the business isn’t
“do it more securely”, but “outsource PCI compliance entirely”?

~~~
raesene9
If by outsourcing PCI compliance entirely, they mean "ensure you don't store
cardholder data by tokenizing it and we store the real stuff" this is very
much not a new solution, so I'd struggle a bit to see the value of a new
entrant.

There's already quite a few payment gateways where an e-commerce site can
iFrame the payment page (or similar) to ensure that they never see the real
cardholder data.

(the fact that this shouldn't really make them out-of-scope for PCI is a
different problem)

~~~
twelve40
This is not a payments gateway. We use them for something entirely different
than processing payments or credit cards. I haven't seen a general PCI-
compliant transparent PII tokenizer proxy service like that. If you know of
one, let me know, maybe we'll even switch. But this is not a payment gateway
solution, and it's offering many more use cases than an iframe or credit
cards.

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

------
delinka
Why don't we already have apps on our smartphones for this?

    
    
        - $PROVIDER wants the following data: $LIST_OF_OPTIONAL_AND_REQUIRED_ITEMS
        - You select which you can provide
        - If the data to be provided includes "billing identifier" or "credit file identifier" (and especially if the identifier is, say, SSN), then first your app obtains a new identifier from the reporting agency or your insurance carrier, and *that* number is given to $PROVIDER
    

Gives more control back to the customer/patient and eliminates (yet another)
treasure trove of data for attackers to go after.

~~~
fosco
what happens if you do not trust your smartphone? I do not like storing
anything of value on mine.

not that it matters but I recently switched to LineageOS and my opinion has
not changed.

~~~
drexlspivey
Apple does this with apple pay and the per device identifier is stored in the
secure enclave (seperate chip that can create keys and sign data). The
identifier can never leave the SE, requires Touch/Face ID to unlock and can be
wiped remotely in case you lose your phone.

------
jamestimmins
It's mind-boggling to me that this didn't already exist. I wonder if that's
because there's a lot of low hanging fruit in security/privacy, low hanging
fruit in healthcare, or a combination of the two.

~~~
segmondy
It exists, it's called tokenization

[https://en.wikipedia.org/wiki/Tokenization_(data_security)](https://en.wikipedia.org/wiki/Tokenization_\(data_security\))

~~~
jamestimmins
Specifically, I mean for this specific purpose, as a service.

------
venganesh
Biggest problem with this solution is to trust VGS capability to secure our
sensitive data. Which is a hardest thing to do in the first place. All it
takes for a disgruntled employee(given company's practices cited in the posts
below) siphoning out the data. They are really tiny enough to pay for the
damage, making their liability claim render useless. However, given the
trivial nature of this problem and interest, I decided to open source a
solution which avoids liability concern.

------
nodesocket
If an organization is deciding between interacting with VGS hashes/tokens
having to proxy requests or deploying a secret store like HashiCorp vault what
are the pros/cons?

> When it’s time to bill your insurance company, their “reimbursement” code
> goes through VGS which “reveals” the token and sends the real version to the
> insurance company.

Forgive me if I am wrong, but that means all 3rd party integrations that
require the sensitive values must be implemented by VGS correct?

~~~
olkooo
Of course third 3rd party don't need VGS, you will send tokenized data through
forward proxy, and at the other end they will receive real data. That is the
usability.

------
dpeck
This old guy appreciates the nod to Pretty Good Privacy, well done on naming.

~~~
skybrian
It's a nice reference but seems likely to cause jokes after their first
security hole. "Pretty Good" is modest. "Very Good" can be seen as arrogant,
unless you are reading it as ironic.

But no worse than "Best Buy" I suppose.

------
mtgx
I'm not quite sure what this is exactly, but it sounds like they are providing
a security "service", so all the "real identifiers" will be stored on their
servers?

Why should an entire country trust them? I'm not saying they wouldn't be an
improvement over Equifax, but it still sounds far from ideal. I think a
hardware token would be preferable.

