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

What a

[Cornwallis]

Racket!

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

[Anonymous Coward]

Almost like PayPal

Re:Not the biggest problem

[Anonymous Coward]

Anyone know if there is or will be a browser API to use USB EMV card readers?

Re:Not the biggest problem

[swb]

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:Not the biggest problem

[fuzzyfuzzyfungus]

The one cause for real concern with the PCI SSC is that whatever mistakes they make now will be with us when we are feebly waving our canes at the kids on our lawns.

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 shove liability onto somebody else, so progress is glacial.

While many of the risks are, indeed, not worth the trouble given the much easier methods available; we might well still be fighting about them in 15 years, and they are unlikely to have aged well in that time.

Re: Not the biggest problem

[Anonymous Coward]

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:Not the biggest problem

[NatasRevol]

Not quite RSA type, but one time pads.

http://www.creditcards.com/cre...

Re:Not the biggest problem

[Anonymous Coward]

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 parties may want a copy that's signed by the vendor in case of an issue with delivery, which can be provided if desired.

Re:Not the biggest problem

[Anonymous Coward]

... web site with information on where to direct the money ...

Encryption aside, Isn't this what the PayPal system does? The POLi payments system is also similar to what you ask.

Re:Not the biggest problem

[roman_mir]

Actually merchants are constantly hit with all sorts of client fraud. people are using stolen credit cards, stolen PayPal accounts, stolen everything. Weather it is hosted checkout (what you are talking about) or an API call to a payment processor, the merchant can get a payment token back (a pseudo random string with the last 4 digits being the last four digits of the credit card). The reason for this is to be able to identify a transaction for a refund or for fraud investigation. As a merchant I avoid storing any user information that I do not need specifically because I want to limit liability. Storing a transaction token, client name, payment amount, payment date and also expiry date on the card and address is useful for fraud investigation and this happens constantly - there are millions of thieves out there and if you don't do anything to protect yourself the payment processors and the banks will hang it all on you and as a small business, a merchant or a service provider you will be hit with back charges and various fines for each transaction that the bank claims was fraudulent. So if a thief uses your service and then the real credit card owner complaints, as a business you are out of money for the service / product and you will be paying a fairly large amount to the payment processor per transaction (on the order of 50USD per transaction that is reversed). If you don't store any information at all, you are fucked.

Re:Not the biggest problem

[Anonymous Coward]

Published: December 14, 2011

Most credit cards have dropped this feature.

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:Not the biggest problem

[mlts]

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:Not the biggest problem

[mlts]

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 database partitioning, perhaps having a hardened computer or appliance whose job is to stash all the sensitive name/address/card no tuples, have a table of those secondary/foreign keys, which are used for the transaction tokenization. Nothing is hackproof, but there are ways to be secure in this manner. For example, one ancient SSL shop I had, it would take the data from the web form, make a text entry, encrypt it with GnuPG, then toss the encrypted file into a directory structure based on transaction IDs and the date. This way, one can find transactions, but the core data remained encrypted until manual decryption was necessary.

I wonder if a tokenization system could function similarly, where the data was tokenized, but a backup copy was stored encrypted via OpenPGP or another means, so the merchant could manually go through records for financial reasons.

Re:Not the biggest problem

[Anonymous Coward]

While that is partially true (trying to snoop an SSL connection to get a single credit card number would be a lot of work for minimal gain) there could also be administration endpoints, ssl based VPNs etc where some other credentials more "valuable" (to an attacker) might be exposed through attacking SSL.

I work for a tier 1 PCI DSS provider and we turned off TLS below 1.1 a couple of months ago. That's probably the oddest thing about the announcement, it doesn't seem to claiming that they can't turn off TLS 1.0 because of lack of browser support from cardholders (in our experience that was negligible), rather it's internal systems or communications between providers that seems to be "too hard". That is a little scary because it's precisely those connections that may be more valuable to snoop on.

Re:Not the biggest problem

[Anonymous Coward]

This is how PayPal works in many cases. You start checkout and eventually get redirected to Paypal's site where you log in to add payment. Works fine.

Many retailers don't like it because it adds an excuse for customers to abandon the transaction. Which is probably a valid concern. However if people knew how many ways their payment info can be mishandled, more would opt for the extra step.

It is true that it is usually not the customer who pays for fraud, but it can take time and hassle to get these situations sorted out. Also many people have cards that withdraw directly from their bank account (which is nuts, imo).

Re:Not the biggest problem

[Anonymous Coward]

In America.

Other countries' merchants upgraded over a decade ago, and the surprisingly expensive hardware is £100 for a mid-range reader.

Re:Not the biggest problem

[CastrTroy]

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. They can't use that payment token to make unauthorized charges.

This is why I basically always use PayPal unless it's a site that I'm very familiar with such as Amazon. There's no way I would enter my credit card number into a site like dx.com or aliexpress.

Sure, if I find an unauthorized transaction, I can always have it reversed. But that's also time consuming on my part to have to call up the credit card company and do so. I shouldn't have to worry about whether or not my credit card will work when I need it because the information was compromised and they cancelled it without my knowledge.

Having a system like I propose would actually allow people to safely make online purchases without the use of credit cards. The ubiquity of credit cards is putting people in debt. Sure there are ways to control it, but it's much easier to control it if you just never have to use a credit card in the first place.

Re:Not the biggest problem

[rickb928]

"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:Not the biggest problem

[rickb928]

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:Not the biggest problem

[mlts]

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 transactions get some security love as well. The only merchant that actually has this is Sony/DayBreak, where they shunt me to Visa or MC to type in my password before the card is approved.

Re:Not the biggest problem

[jonwil]

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

[rickb928]

Yup. You're correct.

Backdoors

[elzurawka]

They just need more time so that the government can implement their back doors into the new algorithm

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

Re:Backdoors

[Anonymous Coward]

just eliminate the middleman and have the government be the payment processor... just as they could already be our 'online backup" service.

Re:Backdoors

[Anonymous Coward]

Moran

Re:Backdoors

[Anonymous Coward]

This?

Re:Backdoors

[Opportunist]

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

[rubycodez]

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

Why not TLS1.2?

[grahammm]

Why do they not mandate TLS1,2 with PFS?

Re:Why not TLS1.2?

[Anonymous Coward]

Why do they not mandate TLS1,2 with PFS?

MSIE

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

[CastrTroy]

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:Email clients are the weakest link

[Anonymous Coward]

Run a virtual server for your email needs. Give it a different IP keep it running on the same physical hardware. Done. You can use whatever you want on the email server and Trustwave wont care.

Re:Email clients are the weakest link

[wbr1]

Better yet, virtualize both into different servers, as well as any other major service. This partitions services, providing a layer of obfuscation and additional security

Re:Email clients are the weakest link

[Anonymous Coward]

For many, the compliance check is used against ALL externally accessible devices, regardless of function, so separate servers would not make a difference. A lot of community financial institutions were struggling to replace their Cisco ASA 5500 series with either the newer 5500-X or Firepower series before the June 2016 mandate.

Re:Email clients are the weakest link

[stevel]

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.

Re:Email clients are the weakest link

[Rutulian]

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 Secure Transport which has TLS 1.2 as of OS X 10.9. Mozilla applications use NSS which has TLS 1.2, as does GnuTLS which is used by Gnome applications like Evolution on Linux. So as far as support is concerned, I think you should be good. Some applications will use the protocol to differing extents, for example differing cipher suites or supporting earlier protocol versions, but if your server requires TLS 1.1, the client should be able to handle it, in the majority of cases. Considering that it's a standard from nearly 10 years ago, I would consider it a downright requirement. In my experience it is usually the servers that fail to support later versions of lts, not the clients, unless it is legacy custom code from random vendor.

Re:Email clients are the weakest link

[Anonymous Coward]

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.

It is extremely easy to set up a test lab chock full of diverse operating system and email client software combinations. You could have comprehensive results in 72 hours if you cared to do so, and you might even share those results with the broader community if you were in a good mood. What's stopping you? -PCP

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.

Re:Email clients are the weakest link

[Dunavant]

I have the same issue, except mine was with advertisers and the API. Disabling TLS1.0 for the site disables it everywhere since they all go through the same load balancers. Suddenly a bunch of the advertisers that use the API couldn't use it anymore because their Java implementations were so old, it didn't support anything newer. I'm sad that PCI moved it back, because it means, once again, the business will force the deadline back, and I'll have to submit the stupid trustwave things every 3 months saying that nothing has changed.

Re:Email clients are the weakest link

[Anonymous Coward]

I think you need to talk to your auditor!

Your mail server can absolutely be moved out of your Cardholder Data Environment (and thus be out of PCI scope). Unless you have a reason to be handling cardholder data on email (I can't imagine a scenario where this is viable) there's no reason for your mail server to be part of the CDE (and frankly I think you are doing PCI "wrong" if it is inside your CDE, by definition you want your scope to be minimal, not just to make the audit easier, but to reduce your attack surface).

See: http://treasuryinstitutepcidss...

Re:Email clients are the weakest link

[Alioth]

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 goes nowhere near the cardholder data environment, and the auditor will be happy and will attest to this. But with the automated scans that a card processor may insist on, not so much. Despite us having a ROC, plus quarterly testing from our own auditors, we had a payment processor require we submit to their automated test. It either passes or fails. If it fails you have to fix what fails, you cannot reason with it or bargain with it. The payment processor just says "tough shit you have to fix it".

Eliminate weak ciphers, TLSv1 is fine

[Anonymous Coward]

So far as I understand, TLSv1 is not a problem, anyway. The problem is the incorporate of weak ciphers from SSLv3. TLSv1 offers AES128-SHA256. Is that a problem?

Re:Translation: PCI is now meaningless rubber stam

[WaffleMonster]

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.

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?

[Anonymous Coward]

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)

Re:Is it possible to fuck this up worse?

[Anonymous Coward]

I've found that Walmart, Lowes (or Home Depot, can't remember), Target, and one or two other places have implemented it near me. Otherwise, basically the same though, little to no support. The banks will love that reality when someone gets a massive set of charges on their credit/debit cards and the store goes crying about having to reimburse those funds because they didn't implement the chip(/pin) reader

Re:Is it possible to fuck this up worse?

[Anonymous Coward]

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:Is it possible to fuck this up worse?

[Anonymous Coward]

You mean greedy? Why the fuck are American Corprations and banks so greedy they didn't roll this out properly?

Re:Is it possible to fuck this up worse?

[reub2000]

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:Is it possible to fuck this up worse?

[Anonymous Coward]

I've used my chip+PIN in about 20 different countries in Europe and Asia, but never in the US--always have to swipe and sign.

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:Is it possible to fuck this up worse?

[Anonymous Coward]

I remember the switchover. Shitty terminals that didn't work well (faulty card slots), and old folks (and yes, a few young folks) that couldn't remember their PIN. Those working behind the counter weren't impressed because the job kinda sucks already and nobody wants hassle. Heck, some terminals (Zellers, LOL) were so shitty that if they couldn't read the chip properly the terminal decided to freeze up and reboot itself. And, of course, plenty enough cards with busted chips because nobody knows what they don't use is broken.

Of course, after 6 months or so, it all settled down. Busted terminals were repaired and people who forgot their PINs had already been to their banks to get it fixed. Bad cards were swapped. Zellers went out of business (eventually). Problems solved.

Same thing will happen in the USA.

Of course, what nobody is discussing is that, at least in Europe, the entire reasoning behind chip and pin wasn't to secure the client's account. It was to download accountability to the client. With swipe and signature, the bank and retailer were on the hook unless they could prove it was a legitimate transaction. After chip and pin, it's now the client's responsibility to prove that their PIN wasn't stolen or that a hacked card wasn't used.

Re:Is it possible to fuck this up worse?

[Firethorn]

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:Is it possible to fuck this up worse?

[Pubstar]

So I'm guessing you bank with Chase. The recently sent me a chipped card. Also, CVS forces you to use EVM if you have one

Re: Is it possible to fuck this up worse?

[Anonymous Coward]

Fewer people? Cards are used so much in Europe that banks are seriously talking of dropping cash currency altogether.

Re: Is it possible to fuck this up worse?

[Anonymous Coward]

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:Is it possible to fuck this up worse?

[Anonymous Coward]

"Why the fuck are Americans so fucking stupid?"

Don't be fooled. In the US, EMV is 99% a fraud liability shift from payment processors onto merchants. Because US EMV systems allow offline transactions, transactions can and WILL be spoofed. When these spoofed transactions happen, the merchant will be on the hook for the costs.

It's the first-gen wireless auto keyfob (or first-gen radio engine-key-handshake antitheft system) story all over again: Non-technical people get lied to about the safety and security guarantees of a new system. The implementers of the system use these lies to shift the burden for failure to somewhere more economically advantageous for them. The low guy on the totem pole (car owners in the auto stories, or merchants in this latest one) get left holding the bag when the inevitable happens.

Re:Is it possible to fuck this up worse?

[raftpeople]

What drove this in Europe was their extremely high fraud rate, it was much higher than US. With chip and pin they brought it down to US levels after many years and now they are a little below US levels except for card not present (online) which of course is where the fraud has shifted to.

Re:Is it possible to fuck this up worse?

[PvtVoid]

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:Is it possible to fuck this up worse?

[plover]

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 you await the replacement card, and that's about it.

Re:Is it possible to fuck this up worse?

[aaarrrgggh]

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.

Re:Is it possible to fuck this up worse?

[MobyDisk]

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.

Re:Is it possible to fuck this up worse?

[Anonymous Coward]

So you are saying you that you never bother to lock your house or car, because if anything is stolen, you are only inconvenienced a few days while your insurance pays out? Nice.

Re:Is it possible to fuck this up worse?

[Anonymous Coward]

Why the fuck are Americans so fucking stupid?

They're being smart. Building a better mousetrap is expensive so it's only a profitable job during plague years; yay capitalism. As long as the losses from plague mice are less than the cost of building and installing new mousetraps, basic ROI says don't do it.

TL;DR: Better infrastructure appears because customers or government control the money; not because corporations can build it.

Re:Is it possible to fuck this up worse?

[houghi]

Ever heard of scaling?
The cost in Europe was higher, because there are less cards. Also people in Europe use the cards less and use cash more than in the US.
The cost of the card is easily recuperated in the lower amount of theft.

So the price per terminal is higher in the EU (and the rest of the world). Yes, the total sum will be higher in the US, but looking per transaction and per user and per terminal it will be lower.

The terminal can be had for less than 100USD easily. And then you will have a high end one that you can take with you to the table in the restaurant. The low end ones I buy for 20EUR and that is retail price in the store including 21%tva, so they should be easily going for 10USD or less.I would say the standard terminal would be around 25USD. Companies spend more on paper for the printer per year.

Software is also cheaper per user, because there are more users.

The thing is that in the US many are not very keen on investment. Rather have 5USD today than 10USD tomorrow it seems.

Re:Is it possible to fuck this up worse?

[Anonymous Coward]

What's "chip and pin" ?

You guys are sooooooooo 2001........ how about Pay Wave ? (HINT contactless).... or even cardless ATM withdrawal ?

Of course, I do live in an advanced land from your future....about 15 hours to be precise ;)

Re:Is it possible to fuck this up worse?

[internet-fairy]

When I was a cashier at wally world (very recently), I was there when chip cards had to now be inserted, not swipped. I don't think I need to tell all of you how idiotic most of the public is. My store was in a higher income area too. I became so sick of explaining to people how to do it that I just did it for them. But I loved when Canadian customers came through my line. I would tell them they were awesome and always so nice. Also, we had a couple week-long fuck ups with the system that required EVERY chip card to be entered manually.

Most also refuse to implement 2FA

[schwit1]

https://twofactorauth.org/

Vote with your feet and money

Re:Most also refuse to implement 2FA

[Anonymous Coward]

This is just like ISP companies all over again... Out of all the banks that are available in my area, only one supports 2FA, and it does not have as many branches to make it convenient. This is just disappointing.

Re:Most also refuse to implement 2FA

[Anonymous Coward]

yay skimmers!

Re:Most also refuse to implement 2FA

[Opportunist]

What good is text message 2 factor auth if people are stupid enough to use their cell phone to access the web page...

Re:Most also refuse to implement 2FA

[Zero__Kelvin]

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

Re:Translation: PCI is now meaningless rubber stam

[roman_mir]

One of the payment processors we use (FirstData) started enforcing no TLS1.0 over half a year ago now. This broke compatibility with quite a few browsers, including some on a bunch of android devices.

However where it comes to PCI compliance it was always a joke and it never had any credibility in the first place. It's been a rubber stamp since the beginning. Even the enforcement I am talking about is fictitious, we only have to ensure that during the scan we are 'compliant' but not in the time between the scans. Besides, all you have to do to certify is answer 'yes', 'yes', 'yes' or 'no', 'no', 'no' to a few hundred questions, pass an online scan and you are done.

Re:Translation: PCI is now meaningless rubber stam

[rubycodez]

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:Translation: PCI is now meaningless rubber stam

[rubycodez]

Level 1 PCI compliance is tougher than that, auditors actually review and record configuration files. Client's answers are verified

Not really sure

[Anonymous Coward]

... will push back the mandatory implementation ...

Not really sure what the difference is, so my interpretation is 'US multi-nationals declare protecting the customer as too expensive (promise quarterly growth instead)'.

... EMV chip & PIN cards in the US ...

Hasn't the rest of the world switched to this already? Once again, rampant capitalism does not deliver the best answer.

And some complain about Apple's Cook's statement

[Anonymous Coward]

Didn't Cook say something like the US doesn't have the talent to make Apple's stuff? Sounds like the US doesn't have the talent to implement Chip-and-Pin credit card transactions. Maybe it needs to be purchased from a European outfit that's been doing it for a long time with success. And there's got to be a secure way to make credit card purchases from Internet based merchants.

So any beds?

[Anonymous Coward]

Any bets on which major banks aren't compliant but have to much power for PCI to do anything about? Most of them?

Re:Translation: PCI is now meaningless rubber stam

[Anonymous Coward]

If vendors can't comply, businesses can't comply. And if you think you understand what this means, you probably don't, and probably don't work in the industry.

Re:Translation: PCI is now meaningless rubber stam

[WaffleMonster]

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:Translation: PCI is now meaningless rubber stam

[rubycodez]

>> 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:Translation: PCI is now meaningless rubber stam

[plover]

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 the bad guys copied our crappy mag stripe cards from your systems, we don't care if you were audited, pay up."

With EMV transactions, copying the transaction and card data is useless to a thief, because it can't be reused (well, at least now that they've plugged the known holes in their overly complex and crappy protocol.) But even so, EMV is truly the punchline to the old joke about "an elephant is just a horse designed by a committee." At least now it's functional, though, and quite secure. (Except for the card not present transactions, phone transactions, paper transactions, web transactions, stored recurring transactions, and pretty much anything that isn't Chip and PIN. The committee hasn't finished designing that elephant yet, but my guess is it will look like a blue whale when they're done with it.)

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).

That has not been true for a decade or two

[aepervius]

We all have bank card which are like credit card except with a chip and pin and are accepted in all shop. A lot of shop accept CC too, mainly shop where you can buy good with a big price. For example all mediamarkt accept CC.

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:That has not been true for a decade or two

[houghi]

There are also pre-paid cards without a swipe strip. Just a chip. And the bank card is basically a Debit Card.

We've done it, they can also.

[rickb928]

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 - too little too late, unless it generates revenue.

Re:Translation: PCI is now meaningless rubber stam

[rubycodez]

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