Deadline for Better Encryption on Payment Systems Pushed Back Two Years (pcisecuritystandards.org)

An anonymous reader writes: The Payment Card Industry Security Standards Council (PCI SSC) has announced (PDF) that it will push back the mandatory implementation of TLS 1.1+ encryption, over the very insecure SSL 3.0 and TLS 1.0 protocols, subject to POODLE attacks. PCI SSC cites "complications" that may come from dealing with EMV chip&PIN cards in the US, the new mobile payment platforms, and browser upgrades for the insecure SHA-1 algorithm.

Comments

Not the biggest problem

[CastrTroy]

I don't see it as a huge problem simply because this is not the biggest problem that online payment systems face. The big problem isn't people sniffing transactions over the wire. This almost never happens. What typically tends to happen is that somebody breaks into the actual system that houses all the sensitive information and steals the data directly. This is much more lucrative as you can steal thousands (or tens of thousands, or even more) of credit card numbers at the same time.

Until we get to the point where online retailers aren't storing this data (in 99% of cases they don't need to), there's little reason to complain about much smaller problems such as what encryption methods are being used.

We'd be much better off with a system where we didn't even have to send our credit card numbers to the online retailer. Ideally when paying for something online, you would be redirected to your banks (or the credit card issuers) web site with information on where to direct the money. After verifying you identity, a cryptographically signed message would be sent to the recipient site so they could verify the payment was successful. There is no reason for them to every see your account number or other vital information.

Re:Not the biggest problem

[Paul Carver]

We'd be much better off with a system where we didn't even have to send our credit card numbers to the online retailer. Ideally when paying for something online, you would be redirected to your banks (or the credit card issuers) web site with information on where to direct the money.

So I go to a random website to make a minor purchase and it pops up something that looks like my bank's website and asks me for my bank login details? No thanks. I don't want to worry about distinguishing my real bank website from a forgery and putting my banking credentials at risk every time I buy something.

I enter my credit card number with the confidence that if I see an unexpected transaction show up on my bill I can contest it and get it reversed. Nobody can compromise my bank account just by knowing my credit card number, all they can do is place a traceable, reversible charge. Your proposal of having people enter their bank login credentials every time they buy something is an invitation to much more serious consequences.

Re:Backdoors

[rubycodez]

No, the algorithms and libraries in question for TLS 1.1+ are already out. Now if they mandate a new cipher then that would be opportunity for backdoors

Translation: PCI is now meaningless rubber stamp

[rubycodez]

Choosing convenience over security with continuing to allow known weak and broken ciphers, PCI just lost all credibility. May as well dissolve it.

Email clients are the weakest link

[stevel]

I run an e-commerce store and have to deal with PCI compliance. We don't store credit card details, but the info passes through our server. The June 30, 2016 deadline to drop TLS1.0 was a big headache, made worse by the "Trustwave" PCI checking tool (mandatory from our payment processor) failing us as of July 2015 for not dropping TLS1.0, but I could submit a remediation plan every three months to defer it.

I did a bunch of testing to see what broke if I dropped TLS1.0. On the web browser side, MSIE10 wouldn't like it, but other, reasonably current, browsers were ok. What surprised me, though, was how many email clients simply stopped communicating with our server if I turned off TLS1.0 for SMTP and IMAP. It's been hard to find details on which clients support TLS1.1 - and perhaps there's some aspect here I'm missing - but this to me is the bigger problem than the web service. (Even though we don't use email for sensitive info, if TLS1.0 was enabled on ANY port, we fail.)

I'm glad to see that this deadline was pushed back, as it was giving me heartburn.

Re:Email clients are the weakest link

[Alioth]

That's not how PCI-DSS works. It doesn't matter if your MX is on a different continent, and it doesn't matter if no credit card data ever goes on it. if it supports a weak cipher or weak protocol you fail. Bizarrely, for things like your MX, you can pass by simply not supporting encryption at all.

Is it possible to fuck this up worse?

[PvtVoid]

I got my EMV card from my bank, which is one of the few that is actually implementing the cards with a PIN. (Hooray for my bank!)

Guess what? I have found exactly one store where it works: Target. Every other store I've been to, every one, still uses the mag stripe and a signature, with the exception of Rite-Aid where they couldn't accept my card at all and I paid cash. Store personnel are whinging to high heaven about how horrible EMV cards are, how this will never work, how it's totally unreasonable of the banks to force this on them, etc. etc.

Go to Europe? It's been working seamlessly for twenty years now. Why the fuck are Americans so fucking stupid?

Re:Is it possible to fuck this up worse?

[taustin]

National retailers who do their own software, like Target (who had a hell of an incentive) and Home Depot (who also had a hell of an incentive) are ahead of the curve. Anybody who relies on software vendors for their processing software is at said company's mercy, and the software companies (who end up on the hook for any expensive mistakes) are very cautious. Our vendor didn't like the beta testing, and decided to not throw us in to the Christmas season with software they weren't confident in. We did not disagree.

There is no difference to the consumer. Their protections are legal, not technical (and if you believe otherwise, you probably need a more honest bank). The only difference is some liability on disputed transactions shifts from the merchant service or card holder's bank to the merchant, and if the merchant is at all competent, that's a small difference.

The reason it was easier in Europe was that fewer people have credit cards there, and it cost less. When the terminals cost the better part of a grand apiece, it's a huge expense to change them out. That, and inertia, and a certain amount of stupidity.

Re:Most also refuse to implement 2FA

[Zero__Kelvin]

Yay, you don't know what two factor auth is!

A lot of PCI is about scope management

[Chuck Chunder]

I'd be looking at moving that email server out of scope, ie out of your PCI environment.

You'd need some policies around your use of email (ie "We don't send cardholder data via email", with bonus points if you have a way of 'enforcing' that, eg a mail scanner) but with that in place there should be no reason why your mail server is in scope if it's seperate from your PCI environment (ie hosted elsewhere).