by jaxondu on 8/28/18, 5:31 PM with 90 comments
by tptacek on 8/28/18, 7:30 PM
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?
by danenania on 8/28/18, 6:56 PM
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.
by vgs_interviewee on 8/28/18, 6:39 PM
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.
by throwawaymath on 8/28/18, 6:35 PM
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.
by CiPHPerCoder on 8/28/18, 6:10 PM
- If H is a simple cryptographic hash function, it's not resistant
to brute-force attacks to recover the SSN
- It's not revokable
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.
by mdpopescu on 8/28/18, 6:28 PM
[1] https://en.wikipedia.org/wiki/Stefan_Brands [2] http://financialcryptography.com/mt/archives/001011.html
by robert204 on 8/28/18, 6:10 PM
by mvpu on 8/28/18, 8:49 PM
by delinka on 8/28/18, 6:23 PM
- $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
by jamestimmins on 8/28/18, 6:01 PM
by venganesh on 8/28/18, 10:12 PM
by nodesocket on 8/28/18, 6:49 PM
> 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?
by dpeck on 8/28/18, 6:20 PM
by mtgx on 8/28/18, 6:46 PM
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.