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.
Very Good Security
81–90 of 94 posts
Re: Very Good Security
#82Earlier quoted context omitted.
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?
Re: Very Good Security
#83Earlier quoted context omitted.
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.
Re: Very Good Security
#84This 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 add…
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.
Re: Very Good Security
#85Earlier quoted context omitted.
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 inst…
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.
Re: Very Good Security
#86This 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 add…
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.
Re: Very Good Security
#87This 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 add…
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.
Re: Very Good Security
#88Earlier quoted context omitted.
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”?
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…
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.
Re: Very Good Security
#89Earlier quoted context omitted.
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…
> "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 behi…
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.
Re: Very Good Security
#90Earlier quoted context omitted.
> "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 behi…
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 o…
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.