I wonder what is the PCI DSS audit committee doing? I mean the world is fool of idiots that need policing and that's why such organs exists at a first place.

Shit like this just shows that being a PCI DSS level 1 certified means absolutely nothing in the real world.

The great benefit of PCI DSS is that a huge number of places choose not to store CC numbers when given a choice of trying to get an expensive PCI DSS certification and not storing CC numbers. We get less of small, random places handling data that they won't ever be able to secure (since it really is completely prohibitively expensive for a small shop to do it properly), and that is a good thing. Of course, the fact that certified places still often fsck up in some way is a bit sad, but at least there are less of them.

You got that right. Most IT shops I've noticed (at least in Australia) used to ask software vendors if their software was "PCI-DSS 2.0 compliant".

Stupid thing to ask. The only key things a software vendor can really answer is that they don't store credit cards in their database, or if they do then they don't display them to anyone. Everything else (well, almost everything else) can be dealt with on the infrastructure side of the equation.

> I wonder what is the PCI DSS audit committee doing?

Creating a racket. PCI is designed to control merchants and extract money, not for security.

I have to disagree with you most emphatically. PCI DSS was a response to a very bad issue, which was and is credit card fraud.

If you look at the DSS, it's eminently sensible and in fact if you implement it properly you will most definitely have a secure environment for credit card transactions. If you do not follow it, then you are leaving yourself at significant risk to be being breached and credit card data being stolen.

I'm curious though: what part of the PCI-DSS merely creates "a racket", and what parts "extract money"?

Actually I'm not sure which of the twelve requirements are being violated here. They could be compliant with part 3 ("Protect stored cardholder data") in their network. If the cookie is secure and only transmitted via SSL, they have a case for being compliant with part 4 ("Encrypt transmission of cardholder data across open, public networks"). Part 9 doesn't really apply here. Part 6 might or might not.

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.

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.