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

21–30 of 94 posts

Re: Very Good Security

#21

Post by mahmoudimus »

CiPHPerCoder wrote: post #4

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…

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

Re: Very Good Security

#22

Post by lowry »

toomuchtodo wrote: post #15
fosco wrote: post #11

Earlier quoted context omitted.

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

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

Re: Very Good Security

#23

Post by gav »

CiPHPerCoder wrote: post #4

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…

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.

Re: Very Good Security

#24

Post by PowerfulWizard »

throwawaymath wrote: post #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 verifica…

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.

Re: Very Good Security

#25

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

Re: Very Good Security

#26

Post by mahmoudimus »

mdpopescu wrote: post #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/00…

(disclaimer: I work @ VGS)

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

Re: Very Good Security

#27

Post by fefe23 »

mahmoudimus wrote: post #17
robert204 wrote: post #3

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

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.

Re: Very Good Security

#28

Post by throwawaymath »

PowerfulWizard wrote: post #24
throwawaymath wrote: post #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 verifica…

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

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.

Re: Very Good Security

#29

Post by 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?

Re: Very Good Security

#30

Post by Edmond »

throwawaymath wrote: post #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 verifica…

like this?:

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

Post reply on HN