Very Good Security
a16z.com
Very Good Security
1–10 of 94 posts
Re: Very Good Security
#2It'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.
Re: Very Good Security
#3Doesn't this mean VGS becomes the single point of failure and a larger target for malicious actors?
Re: Very Good Security
#4H(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
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.
Re: Very Good Security
#5It'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.
Re: Very Good Security
#6H(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 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?
Re: Very Good Security
#7[deleted]
Re: Very Good Security
#8This old guy appreciates the nod to Pretty Good Privacy, well done on naming.
Re: Very Good Security
#9H(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…
seems related to something like this:
Re: Very Good Security
#10Why 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