[danenania]

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.

[mjallday]

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.