Live data from Hacker News

Very Good Security

a16z.com

11–20 of 94 posts

Re: Very Good Security

#11

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

Re: Very Good Security

#12
post #10

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* numbe…

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.

Re: Very Good Security

#13
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

Re: Very Good Security

#14

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 b…

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…

Salt?

Re: Very Good Security

#15
post #11

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 initial…

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

Re: Very Good Security

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

Re: Very Good Security

#17

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

(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

Re: Very Good Security

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

Re: Very Good Security

#19

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.

It exists, it's called tokenization

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

Re: Very Good Security

#20

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/00…

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