Hacker News Reader

Actually, you aren't meant to store credit card data when it's not necessary. And credit cards are meant to be encrypted at rest - in other words, on encrypted storage, with a split key management system.

None of these things are being done.

View on HN

Yes, that's true. But the letter of part 3 only talks about encrypting data at rest on your own systems; it mentions nothing about client systems. There's a huge discussion about whether or not the user's browser is within scope for PCI-- this is what systems like Stripe and Braintree are gambling on, that the browser _isn't_ within scope (Braintree actually makes this a big selling point; if you use their system, your platform is no longer in scope for PCI-DSS).

The PAN data -- the cookie -- is encrypted in transit, and if it's encrypted at every point in Santander's network then technically they could be compliant to the letter of the rules. I have no doubt that a company so dumb as to store your PAN data in a cookie is probably breaking a myriad number of PCI-DSS rules, but the card-data-in-cookie may not be one of them.

Does "You are only as strong as your weakest chain" mean anything here? It seems like the letter of the law here is not expressing the intent of the law. Sure, Part 3 didn't explicitly mention don't store it on a client machine because its such a stupid thing to do there wasn't a point to expressing it. Doing such a thing completely undermines the entire PCI documentation because who cares how it's stored,transmitted, etc at the trusted source if it's written out to significantly less secure sources. Just go steal it from the least significant secure source. I fail to see how this language argument has any real point.

Reply on news.ycombinator.com