Deadline for Better Encryption on Payment Systems Pushed Back Two Years (pcisecuritystandards.org) 91
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.
Re: (Score:2)
Not the biggest problem (Score:5, Interesting)
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: (Score:1)
Almost like PayPal
Re: Not the biggest problem (Score:1)
There is already for SSL client side certs which can come from a credit card.
Banks shouldn't be reinventing the crypto wheel anyway, just have the card provide the cert to identify the terminal.
Re: (Score:2)
Couldn't credit cards be a little like those RSA cards with a number that changes every minute?
When buying things, the number gets entered as part of the transaction, verifying that the card is in the hand of the cardholder.
Re: (Score:2)
Not quite RSA type, but one time pads.
http://www.creditcards.com/cre... [creditcards.com]
Re: (Score:1)
There are better ways than that. Just sign the transaction with your private key. This is a solved problem. No need for fussy timing, and no threat or replay of MITM attacks. You just look at the terms of the transaction, and if you like them, sign it and off it goes to the payment processor, which will in turn sign it if all is good and return it to the merchant. The merchant now has proof the payment processor agrees to transfer the money, so they can perform the transaction without fear. Some of the part
Re: (Score:2)
What would be nice, would be an e-Ink display on the card that would change over time or when a button is pressed. If the card expires in 2-4 years, that is well within the time of a battery's lifetime, especially for a TOTP system.
This way, online purchases are protected by a form of 2FA as well, since an attacker would have to have the card info, as well as a challenge/response code.
Re: (Score:2)
EMV dates back to 1994(with smartcards more generally being a late-80's thing); and we've just started to pretend at actually being serious about using it. Merchants hate upgrading POS hardware(which damn well earns its name; but at least it's surprisingly expensive), every change means a knife-fight over processing fees and an attempt to sho
Re: (Score:2)
"an attempt to shove liability onto merchants"
FTFY
You think the intent is to shift liability to card holders? Wrong. Merchants are captive. Card holders can change brands, go to prepaid, or go to cash. Online merchants fear this the most, since issuers that try to shift liability to card holders risk those card holders going to cash (yeah, some will), and well no one pays cash for Amazon goods.
Re: (Score:2)
October 2015 was a deadline that card vendors transition to EMV or else take responsibility for fraud. However, my recent credit card from a few months ago has no EMV chip on it, and most retailers still are using swipe terminals. Even with the one retailer that used EMV, it would not ask for the PIN of the card... just did the transaction, and called it done.
Who is to blame? In this case, it can be shared equally.
As for separating tokens from transactions, I wonder if this could be done via just databas
Re: (Score:2)
U.S. acquirers chose to implement chip+signature in the U.S. first, planning to to chip+PIN 'later'.
After a noticeable flurry of on time implementations, adoption in the U.S. seems to have halted to deal with the holiday shopping season. Hopefully this picks up in February.
Wal Mart for instance dips (shorthand for accepting EMV) and doesn't need a sig for smaller purchases. Same for Target. Fry's supermarkets also, I believe.
Re: (Score:2)
I have encountered exactly one retailer which actually asked for a PIN: Target. Everyone else either tells me to just swipe and ignore the dip part or jam the card in, and have the transaction treated like a swipe (tap "yes", sign.)
Of course, it is like having a deadbolt lock with no tumblers in the lock. Chip & PIN not just protects against using swiped codes, but also unauthorized use of the card. Someone who found a card lying on the road can't just use it as one sees fit.
Hopefully CNP transactio
Re: (Score:2)
I dont get why the US is moving to chip-and-signature instead of straight chip-and-pin. Australia moved to chip-and-pin a few years back and there is no problems now.
Although maybe in the US the card companies (Visa, MasterCard etc) are worried that if people have to remember a pin to use their card, they will say "screw this" and use cash instead...
Re: Not the biggest problem (Score:2)
Yup. You're correct.
Re: (Score:3)
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
Re: (Score:2)
Really, I try not to buy off sites that look too shady. But a lot of the foreign sites have really good deals, and also look shady. Here's the options:
A) Going to some shady website and entering your credit card info directly into the website where it is saved on their insecure servers forever.
or
B) Going to some shady website and being redirected to a site you can guarantee belongs to your credit card provider and verifying you identity there. And then they just hand off a payment token to the shady site
Backdoors (Score:2)
They just need more time so that the government can implement their back doors into the new algorithm
Re: (Score:3)
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
Re: (Score:2)
It's more that some of the big banks would no longer be PCI-DSS compliant.
Imagine most major CC payment provider suddenly ceasing to exist. ;)
Translation: PCI is now meaningless rubber stamp (Score:4, Insightful)
Choosing convenience over security with continuing to allow known weak and broken ciphers, PCI just lost all credibility. May as well dissolve it.
Re: (Score:2)
Choosing convenience over security with continuing to allow known weak and broken ciphers, PCI just lost all credibility. May as well dissolve it.
What is wrong with AES CBC ciphers in TLS 1.0 with record splitting? A workaround known and implemented since at least 2002?
Honestly the credibility lost for me was crying wolf on TLS 1.0 without supporting technical merit. This is a fixed problem for vast majority of clients.
Re: (Score:2)
Not crying wolf, TLS 1.0 includes too many weak and broken ciphers, you just cite 1 that might be "good enough" and not all servers allow a specific single cipher to be specified
Re: (Score:2)
Not crying wolf, TLS 1.0 includes too many weak and broken ciphers
Acceptable cipher suites are configurable by client and server independent of TLS version.
you just cite 1 that might be "good enough" and not all servers allow a specific single cipher to be specified
No, I cited a _class_ of them.
ECDHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA
AES256-SHA
DHE-RSA-AES128-SHA
AES128-SHA
There are other good algorithms besides AES:
DHE-RSA-CAMELLIA128-SHA
CAMELLIA256-SHA
DHE-RSA-CAMELLIA256-SHA
CAMELLIA128-SHA
Re: (Score:2)
>> Acceptable cipher suites are configurable by client and server independent of TLS version.
Not a true statement for web servers, clients and libraries in general. You are thinking only of Apache or openssl?
Not all clients do record splitting either; again you seem to be thinking of specific product
Re: (Score:2)
Level 1 PCI compliance is tougher than that, auditors actually review and record configuration files. Client's answers are verified
Re: (Score:2)
PCI compliance has always been a complete and utter scam. The magnetic stripes on the bank's cards have never been secure. But instead of rolling out chip cards that have dynamically generated authentication codes, they said stupid, expensive things like "hey, retailers, spend a fortune on encrypting our crappy mag stripe cards" and "hey, retailers, go through an expensive audit of your systems to prove you're properly encrypting our crappy mag stripe cards" and "hey, retailers, you got breached because t
Re: (Score:2)
I do work in the industry, and your statement is nonsense. Plenty of vendors already are at non-vulnerable portions of TLS 1.1 and/or 1.2
Why not TLS1.2? (Score:2)
Why do they not mandate TLS1,2 with PFS?
Email clients are the weakest link (Score:4, Informative)
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: (Score:2)
Why not just host email on a completely different system? There's very little reason to have email hosted on the same machines as your web server.
Re: (Score:3)
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.
Re: (Score:2)
The "auditor" in this case is an automated scan done by your card processor. Like the Terminator, they cannot be bargained with or negotiated with. They either pass or fail. If it fails you have to fix it. They won't accept "That's not part of the CHD environment".
You can do this if you're getting an audit done by an actual human being. We went for the full big formal audit to get a Report of Compliance by an independent auditor. You can show to the auditor that your MX and everything else surrounding it go
Re: (Score:2)
Re: (Score:2)
No., it doesn't solve anything. Trustwave will look to see who the MX is for our domain and probe it. I'd rather solve the underlying problem than hide it.
A lot of PCI is about scope management (Score:3)
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).
Re: (Score:2)
It's been hard to find details on which clients support TLS1.1 - and perhaps there's some aspect here I'm missing
While there is some variability in how clients may implement or require certain features, 99% (yes, I just made that up, but a high%) of applications will use a library for tls connections, so capability is determined by the library it uses, and there aren't that many. For example, the majority of Windows applications, and certainly the ones provided by Microsoft will use SChannel which supports TLS 1.2 as of Win7, although it may not be enabled by default. Likewise, Apple applications like Mail.app use Sec
Re: (Score:1)
Is it possible to fuck this up worse? (Score:5, Insightful)
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: (Score:2)
Can you say which bank/which card that is? I'd love to get the security improvement of having a PIN rather than the silly chip+signature everyone else is doing.
(Yeah, I know it doesn't solve all problems with security, but it is at least a step in the right direction)
Chip and Signature is only slightly less secure than Chip and PIN. Both systems require the card to be present in order to generate an authentication, and neither can be skimmed or stolen by hackers. The only thing the PIN adds is the assurance that it's you that is using the card, and not some mugger who stole your wallet. But in the case of a mugger, as long as you call the bank to report the stolen card, you're not liable for any of the charges he incurred. You're inconvenienced for a few days while
Re: (Score:1)
You do not even need to go that far. Just north of the border, Canadians are also using pin&chip cards just about everywhere. Even debt cards are now pin&chips.
Re: (Score:1)
Re: (Score:2)
I use the chip at trader joes. It does seem like most of the time I'm just swiping the card. Of course people are resistant to change and are going to complain. Most of them will get used to it.
I just wonder how much this will actually help with reducing fraud. EMV prevents the card it self from being cloned. How does it prevent someone for hacking the store and using the information to purchase something online?
Re: (Score:2)
What annoys me is trying to predict which I need to be using - swipe or chip. Walmart is chip only. Most of my other stores are swipe only.
Re: (Score:3, Insightful)
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
Re: Is it possible to fuck this up worse? (Score:1)
Not sure that fewer people in Europe have credit cards and in the UK at least, chip and pin is used for debit cards as well. In any case every merchant needs to support them.
Re: (Score:2)
Re: (Score:2)
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
Correct me if I'm wrong, but I don't think this is the whole story: the big advantage of EMV from a consumer perspective is that merchants don't store the card data, since every transaction has a unique code. This was the mechanism of the Target hack, which EMV shuts off. It's a big difference.
Re: (Score:2)
Unfortunately from what I understand you are wrong. It takes services like Apple Pay to tokenize transactions. I have no idea why, but I guess it is a backward compatibility issue, and the merchant's desire to track customers.
That has not been true for a decade or two (Score:2)
Basically your "Not everybody has a CC" hide the fact that actually we all have a bank card which fulfill the exact same need, and has chip and pin.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Your experience is the opposite of mine: I live in a major metropolitan area, and the only place I've seen that does not suppor chip+pin in the last 6 months is on the vending machines at my office. I think every other store supports chip+pin. That includes: McDonalds, Target, Kohls, Home Depot, Giant Food, and the little cafeteria at our office. Maybe not the chocolatier around the corner.
Most also refuse to implement 2FA (Score:2)
Vote with your feet and money
Re: (Score:3)
Re: (Score:2)
What good is text message 2 factor auth if people are stupid enough to use their cell phone to access the web page...
We've done it, they can also. (Score:2)
As of last week, my work no longer accepts incoming connections via SSL or TLS 1.0. SSL was disabled early in the year, and TLS 1.0 recently.
A few of our larger clients were caught off guard, and took a few sleepless days/nights to fix, though we had been warning them for 18 months. We still get connections, which are refused, and their support teams notified.
This is really not so simple for some, as they have old, brittle systems. But must be done. The PCI cabal is failing here, but that's their model