Very Good Security | Hacker News Reader

Very Good Security

a16z.com

127 pointsjaxondu90 comments

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?

Exactly. I don't see anything new or differentiating here except that A16Z has a louder microphone and is using HN as a stage to announce it. Besides also apparently reveling in the fallacy that if expert are involved, it can't be hacked.

Looks like they're solving a sales and distribution problem, not one of technical innovation.

I think it’s because of the cool name

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

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

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.

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.

Be careful to not use anecdotal evidence as support for an argument

Tokenization is just one part of the solution and you're correct, tokenization providers are plentiful.

VGS also handles compliance, audits, assumes liability and handles custodianship of the data, and provides a convention (versus configuration for most tokenization security) that provides a simple integration.

If you're looking for someone to help offload and get you compliant quickly without having to get mired into the world of compliance yourself it's a solid offering.

From a quick skim through their FAQ it wasn't clear that they are even encrypting the data on their servers, and I didn't notice any claim about users controlling access to their private information.

It's actually way cooler than that, besides all the compliance help they provide - they provide tokenization but also software to make that tokenization work with 0 code changes on your side (besides env changes), via the use of proxies. It's awesome - your system won't know the difference between the tokenized SSNs and the real ones.

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

Huge fan on EnvKey. A perfect example of security + usability done right -- they make more convenient to do the right thing in terms of managing sensitive environment variables.

Different niche than VGS, which again, is taking a novel approach to securing sensitive information. You can tell that their founders have had real-world experience from their novel solution; using a proxy to mask and reveal sensitive information.

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.

I don't see how that changes things at all... The payment gateway still gets the info, you still need to enter the info somehow, and in most proper e-commerce implementations these days they don't have access to the cc # anyway.

What changes except adding more work/failure-states/encryption at the one point where it does not matter?

I agree that for most implementations, it wouldn't make much difference. There's no point in trying to hide a cc # from Stripe, since they need it in plaintext to make the charge anyway.

But the use case of VGS as described in the article is for companies that do want to charge the cards themselves or otherwise access the cc # for whatever reason vs. outsourcing that. In this case, VGS allows you to hold a token instead of the cc #, and then you can trade your token in for the cc # (alongside some other authentication probably, like IP restrictions/anomaly detection) to make the charge.

I'm not an expert on PCI, so I don't know whether this approach truly satisfies it in itself since yes, the tokens are still sensitive. But my point is that if you're going to take this approach, and believe it does satisfy PCI, then it's strictly better if you don't have to trust VGS to store the cc # in (effectively) plaintext.

Encryption is one part of PCI (data stored at rest and in transit). There's still a slew of controls that need to be satisfied when you have access to the data and there's no getting around them if you chose to take this burden on yourself.

The technology involved in persisting sensitive data on disk is a small portion of becoming compliant.

Having said that, huge fans of envkey.

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

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

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/

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.

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?

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.

Yours was a good question, no idea why you got downvoted. Mdpopescu provided an insightful answer.

Also, it opens up networking opportunities for said developers, maybe they get a better remote contract afterwards.

To be fair that was actually an issue he brought up- he said that several of their Ukrainian staff could not come to the US because they were not willing to lie on their visa application.

I don't think they're YC: http://www.ycombinator.com/companies/

Their list of investors: https://www.crunchbase.com/organization/very-good-security/i...

The CEO is a former YC founder and is using the resources that are provided to YC founders to help start VGS. You'd be amazed the cool stuff former YC founders get access too.

You should put this on Glassdoor.

A16Z should look into these alleged practices, given that they are the lead investor in VGS.

Edit: I've sent an e-mail about it.

Whether they actually violate visa laws really depends on particular circumstances. Getting paid Ukrainian salaries actually makes it more likely that what they're doing is completely fine from USCIS point of view. Employees of multinationals such as Google, Microsoft, Facebook, Intel etc. who live and work outside of the US routinely travel to US on B2 visa for various work purposes. It really depends on how long you are planning to stay, what exactly you are planning to do, etc.

It does violate the letter of the law. B1 visa is only for training, meetings, conferences, etc, if you work remotely for an U.S. company you're not supposed to work while there, only training and meetings. Not sure if you work for a foreign entity (maybe Facebook Ireland is a separate, foreign entity for B1 visa purposes, and maybe they're being paid by an Ukranian entity in Ukrania). B2 is the tourism visa, so definitely no work, but most people get a dual B1/B2 visa.

Edit: apparently the key part is "no salary/income from a U.S. based source". So maybe they're in the right.

In practice, if they're only staying for a few months I don't know if USCIS will care, unless they get caught red-handed.

I wouldn't want to argue with USCIS about the letter of the law though, they'll deport first, ask questions later.

https://travel.state.gov/content/dam/visas/BusinessVisa%20Pu...

Ah, I meant to write that they routinely travel on _B1_ visa for work purposes -- I confused which one is tourist, and which one is business visa. And yes, the difference here is mostly immaterial, since most people simply get a dual B1/B2 visa.

> I wouldn't want to argue with USCIS about the letter of the law though, they'll deport first, ask questions later.

I don't think that's how it works in practice. It is quite rare that people are deported in cases like this, and much less on a short notice too.

I'm sure the CEO @mahmoudimus can chime in - he's been posting in this thread noting that he works at VGS.

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.

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.

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.

like this?:

https://www.cipheredtrust.com/doc/

> Replace the single human-memorable token (SSN) with a unique public/private key pair

There are governments that work on solutions to give each citizen a certificate. What I would love to see would be the possibility to issue your own sub-identities that only exhibit as much information as you want/need to share for that specific use case. E.g. if you need to make $20k/yr for a new mobile phone plan, you can issue an identity that makes $20k/yr as long as you make at least that.

You have just described IRMA (I Reveal My Attributes) which is an experimental non-profit implementation of a subset of Idemix, a type of ABC (attribute-based credentials) system:

https://privacybydesign.foundation/irma-en/

https://privacybydesign.foundation/irma-explanation/

https://petsymposium.org/2017/papers/hotpets/irma-hotpets.pd...

edit: links

https://www.civic.com/

What do you think of Vinny Lingham's company that is aiming to do something similar?

Not to knock your answer, I agree with you that this is a usability problem, but also to be fair, there’s a lot more to the technical side of this than the use of public/private key crypto as you described.

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.

The article says the token "maps" to the SSN, and since they want to give different tokens to different vendors using VGS, I'd assume they're either wholly random tokens associated in a database somewhere or that some other factor of randomness is added in.

But the issue I see is that there still has to be a way that the user is handing say, their SSN to a website, for it to request the token key that associates with it, which is a big risk point. Because they need to identify themselves in a way that can identify the correct VGS account to talk to?

I mean, I think really you'd be better off doing a private/public key thing, where you have some sort of device that gives a sub-key of your master identity key to the vendor?

seems related to something like this:

https://www.cipheredtrust.com/doc/#anonymized-identities

Salt?

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

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

I'd like to make but one appeal to everyone reading this thread:

Ask your cryptographer if the algorithm they're proposing you to use is IND-CCA2 secure (especially if it meets the criteria for IND-CCA3).

Litmus test: If they don't know what that means, you shouldn't be trusting them for cryptography advice.

If it isn't IND-CCA2 secure, you shouldn't be using it. Full stop.

For the curious: https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt...

The IND in IND-CCA2 means "INDistinguishable"; i.e. from randomly generated line noise. For symmetric cryptography, your ciphertext shouldn't have any structure to it. (Lattices and such are a different story. If structure is permissible for your security goals, you're probably doing asymmetric cryptography anyway.)

To be clear: Format-preserving, order-preserving, order-revealing, and homomorphic encryption technology-- while an exciting research area-- fails to meet this requirement and should not be used for non-experimental purposes until their techniques have had time to mature. And even then, until they meet this requirement, only when the threat model doesn't realistically include the possibility of adaptive chosen-ciphertext attacks. (Spoiler: A real world threat model will almost certainly always include that.)

> We use FF1 and are actively engaging with the world's leading cryptographers

I've seen this "we engage with the world's leading cryptographers" genre of claim before, albeit from a much more arrogant source: https://news.ycombinator.com/item?id=6916860

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

NASDAQ had a 2 Petabyte Microsoft SQL Server.

https://customers.microsoft.com/en-us/story/nasdaq-omx-group...

Exactly, it seems way too complex. I don't know why my insurance company can't give me a 9-digit number that is HASH(SSN + member_id) and tell me to use that instead of my SSN.

It also would need to be salted

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 [2] http://financialcryptography.com/mt/archives/001011.html

I've never heard of this before. Do you know which technologies specifically address the article posted?

Chapter 1 explains the usage of the protocols. Quoting from the book, on page 33:

"The authentication mechanism is such that the receiver not only authenticates the message, but also demonstrates a property of the attributes encoded into its certified key pair. The receiver has full control over which property is demonstrated: it can be any satisfiable proposition from proposition logic, where the atomic propositions are relations that are linear in the encoded attributes. Any other information about the attributes remains unconditionally hidden." (Emphasis mine.)

I will admit that the math was not something I studied in depth (and I definitely didn't check the proofs!), since crypto is at best a hobby for me and not my main job.

(disclaimer: I work @ VGS)

We are actually evaluating more recent advances in zero-knowledge systems. Stay tuned on more news soon in that front :)

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

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

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.

Er... it was on the Wikipedia page. It was published on Amazon [1] but the Wikipedia page also seems to have a link to a PDF (ref #5).

[1] https://smile.amazon.com/Rethinking-Public-Infrastructures-D...

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

agreed, imagine the ability to look at all of the data they have and find a dump on that.

idea time: Cryptographically store this data on physical cards that can fit into wallet and be managed by the user and 'revoked' if they lose the card. obviously things like backing up and storing will still need to be done, but that does not necessarily need to be reachable via an API or on the internet all after it has initially been created.

I spent two minutes on this idea, be nice :-)

https://en.wikipedia.org/wiki/Estonian_identity_card

Belgian eID is similar. But the state crippled the ability to sign with it, because they wanted to have control over authorisation.

(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

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.

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”?

I can think of a few:

  1.) Shared resources, and exploits like meltdown and spectre 
  2.) Cloud provider employees potentially have access
  3.) Cloud providers are subject to law enforcement requests

However, there are benefits. Typically Google Cloud for example is going to have much better systems and security that a home-rolled data center setup. They've been working on it for years and essentially have unlimited resources (time and capital).

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)

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.

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

Case in point: T Mobile Austria. https://nordvpn.com/blog/t-mobile-passwords-hacked-twitter/

Here in HN, we all know what happened whenever a large actor took on the liability. The answers here are almost insulting given the category of the service provided; dismissive even.

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

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.

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.

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.

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.

Yeah this tokenization stuff is already used all over the place, (for example, Stripe does it for you with credit cards, giving you automatic PCI compliance).

I think the innovation here is that instead of being part of carrying out the rest of their business, tokenizing and keeping the real info safe is the whole product here. That seems smart to me.

The dumb part, of course, is that we have these bearer tokens (SSN and CC numbers) in the first place, without constantly rotating them. There's some amount of rotation with CC numbers when the company detects fraud and sends you a new card. But for SSN, it's unconscionable that they're both the username and password.

It exists, it's called tokenization

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

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

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.

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?

the biggest pros of VGS: 1) tokenization/detokenization through their proxies does not require any code changes, you don't need to change your architecture ( which happens if you decided to add some secret storage like HashiCorp etc) 2) Compliances, VGS provides you: PCI, EI3PA, SOC2, HIPAA, GDPR

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.

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

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.

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.

Reply on news.ycombinator.com