Credit card security is comically poor. Off the top of my head:
1. An NFC-enabled EMV card will happily reveal its entire account number and expiration date over NFC with no authentication whatsoever. I don’t know whether the CVV comes along, but I wouldn’t be surprised if it did.
2. (As mentioned in the article) issuers accept transactions from EMV (chip)-capable readers that nominally originate from EMV-capable cards without requiring the chip to be used. So what’s the point of the chip? (Note that this allows a card to be cloned without even touching the card - see #1.)
3. The information leaked in #1 is enough to buy things online (as long as the CVV2 can be found or guessed). Wtf?
4. For some reason I can’t fathom (presumably just laziness), if your card number is stolen, the chip stops working until a replacement shows up.
5. Fancy merchants can arrange a subscription that survives a lost card or even a fraud report against that merchant. But these subscriptions can’t be seen or cancelled on the cardholder website or even by customer service.
But somehow all this comes with fairly stringent PCI requirements, which supposedly represent best practices, despite the entire system design being a case study on worst practices.
> An NFC-enabled EMV card will happily reveal its entire account number and expiration date over NFC with no authentication whatsoever.
EMV was enabled with the intention of replacing magnetic stripe payments quickly. Together with 3DS on the online payment side, this would have effectively made a card number by itself worthless. Unfortunately this hasn't happend (except for mobile wallets using tokenization like Apple and Google Pay), but given that (at the time entirely reasonable!) assumption, I'd cut the original designers some slack.
Another reason: How would you even implement authentication? There are millions of terminals out there, operated by at least hundreds of different service providers. What key would you use for authentication and how would you hide it in a way that wouldn't eventually be leaked from legitimate terminals?
> issuers accept transactions from EMV (chip)-capable readers that nominally originate from EMV-capable cards without requiring the chip to be
Some issuers do, some don't. That's not the protocol's fault.
> 3. The information leaked in #1 is enough to buy things online (as long as the CVV2 can be found or guessed). Wtf?
At merchants not using 3DS, that is true – but these merchants also bear the full liability for any fraud happening. In the end, it's a prototypical security vs. usability/conversion tradeoff, in the same way that US credit cards don't have PINs, while almost every other market does.
I'm willing to cut the original designers some slack. I'm not really willing to cut the industry slack for not fixing it. It's been years. Heck, EMV had been widely deployed in Europe for years before it showed up in the US.
> Another reason: How would you even implement authentication? There are millions of terminals out there, operated by at least hundreds of different service providers. What key would you use for authentication and how would you hide it in a way that wouldn't eventually be leaked from legitimate terminals?
There's no need. Just have the chip have an entirely different account number that only works for EMV transactions. This wouldn't even need updates to existing card readers.
> Some issuers do, some don't. That's not the protocol's fault.
This is the payment card industry, which has an entire tome of moderately onerous requirements that everyone must follow. Surely there could be a new requirement for issuers to verify that the transaction is authenticated properly.
> Just have the chip have an entirely different account number that only works for EMV transactions.
Issuers can certainly do that, and some do (e.g. Apple Card).
Some use cases don't handle that very well, though, e.g. booking a hotel online and then presenting the physical chip card for verification, comparing the last four digits printed on the card with those printed on the receipt for a refund, and others.
But there is already something that is different across all interfaces (chip, magnetic stripe, human-readable printed card number): The CVC. Practically, this makes "cross-channel skimming" pretty hard.
I do not recall all details, but EMV implementation in USA was different in terms of configuration applied, especially in terms of what data was required to auth the transaction, mainly due to some intercorporate politics iirc
>At merchants not using 3DS, that is true – but these merchants also bear the full liability for any fraud happening
As far as I know, the merchant always bears the full liability for fraud, whether you use 3ds or not. The sales pitch for 3ds is simply to reduce the chances of fraud.
Also, you do don't even necessarily need the CVV to buy with a cc online. Depends on the merchant.
> As far as I know, the merchant always bears the full liability for fraud, whether you use 3ds or not.
This is very much untrue. If a merchant initiates the 3DS flow, liability for fraudulent transactions shifts from the merchant onto the issuer. Here's documentation from Stripe[1] on the matrix of possible flows and the resulting liability shift, and docs from Adyen[2] on card networks that support liability shifting with 3DS.
> [...] found a global pattern that allows me to accurately predict American Express card numbers by knowing a full card number, even if already reported lost or stolen.
> This means if I were to obtain your Amex card and you called it in as lost or stolen, the moment you get a new card, I know your new credit card number.
I suspect this has already been exploited in South America with at least one North American banks' Amex cards. Can't get into too much detail, but the pieces fit.
It’s not really that simple, and it’s likely that these attacks would fail CVV/3DS/etc, so it’d be hard for a reasonable merchant to be tricked regardless.
"I also determined that the CSC (essentially behaves like a CID or CVV2 on the magstripe) for a lost or stolen card continues to work for a newer, predicted card. An attacker would be able to use a stolen card's CSC with the predicted card number and expiration to make actual purchases."
Also...ask any merchant if they've ever NOT been left holding the bag for a fraudulent purchase. The only time that happened for me was when I could prove it was fraud by the actual cardholder, and even then, the banks would often deny the counterclaim anyway.
ISTM it’s only criminally hilarious if you catch Amex doing something fraudulent or illegal themselves. But it sure would be entertaining to have a big civil lawsuit on the basis of incompetent security practices.
I don't see how this is specific to AMEX. When my USAA Visa got cancelled because of yet another merchant system leak, they sent me another card that was just sequential with the cancelled one up to the 15th digit (the 16th is a check digit).
>>3. The information leaked in #1 is enough to buy things online (as long as the CVV2 can be found or guessed). Wtf?
At least in EU you can't do that anymore - all online transactions are required to implement 3D secure so you have to confirm the transaction some other way in addition to your card details.
> 2. (As mentioned in the article) issuers accept transactions from EMV (chip)-capable readers that nominally originate from EMV-capable cards without requiring the chip to be used. So what’s the point of the chip? (Note that this allows a card to be cloned without even touching the card - see #1.)
I would think the issuer could refuse the transaction higher up in the process, but it's faster and fewer packets going back and forth if the POS terminal could reject the swipe up-front and tell you to insert the chip.
That’s like saying you think a server can reject a wrong password on the backend, but it’s faster and fewer packets going back and forth if the client JavaScript just verified the password before sending POST. This is nuts. At least there’s nothing fundamentally wrong with a card reader also rejecting the transaction.
(It’s also not fewer packets. Although it does require the backend to know whether the card reader can read a chip, and I don’t know whether the reader reports this as part of the transaction. OTOH there are rather severe penalties assessed on merchants with non-chip-capable readers, so something up the stack has at least some idea.)
A better comparison would be the client JavaScript rejecting a four-character password, because it knows the backend policy requires at least eight.
Done right (without e.g. checking for "key down" events to thwart password managers...), this could could actually improve security somehwat by avoiding whatever the user entered (maybe a low-entropy PIN?) hitting the network or backend, besides providing for a faster error response and thereby nicer UX.
> It’s also not fewer packets
It avoids an entire round trip to the issuer's backend and back, which are often still somewhat expensive and slow, given the legacy systems and connections involved.
> It avoids an entire round trip to the issuer's backend and back, which are often still somewhat expensive and slow, given the legacy systems and connections involved.
Not if done both client-side and server-side.
Right now, if I swipe my magnetic stripe, then terminal will reject it if the stripe has the magic bit set. If the magic bit is clear, the terminal will (eventually, but usually while the customer waits) send a message to the network saying that the card was present and asking for authorization. The network responds. No additional round trip would be needed for the network to deny authorization if the chip was not used.
> That’s like saying you think a server can reject a wrong password on the backend, but it’s faster and fewer packets going back and forth if the client JavaScript just verified the password before sending POST. This is nuts.
I don't think it is nuts. The terminal doing the rejection accounts for the "oops the customer did something wrong" case of swiping the card when the issuer wants them to use chip. It's better to tell the customer this now than run an entire transaction.
But checking on the far end that the transaction meets all of the issuers rule accounts for the fraud case of "someone has maliciously rewritten the magnetic stripe data to try to go around the requirement to insert the card." Since, hopefully, this happens far less often than the first case, it is an acceptable path.
> 2. (As mentioned in the article) issuers accept transactions from EMV (chip)-capable readers that nominally originate from EMV-capable cards without requiring the chip to be used.
Last time I tried swiping my card — and that was ages ago — the terminal displayed something to the effect of "this card has a chip, please insert the chip".
> 3. The information leaked in #1 is enough to buy things online (as long as the CVV2 can be found or guessed). Wtf?
3DSecure is a thing and its job is to prevent this exact situation.
So credit card security is comically poor, but only in the US. You were somehow still using the magstripe until recently and probably still do sometimes at places that didn't upgrade their readers in time.
> Last time I tried swiping my card — and that was ages ago — the terminal displayed something to the effect of "this card has a chip, please insert the chip".
I think it's configurable depending on merchant risk tolerance. I've seen cases where the terminal lets you swipe after three failed chip reads, for example.
Almost every terminal will fall back to mag-swipe if the chip fails to read 3 times. I had an Amex with a faulty chip and had to do this every time. Terminal (every single one) would refuse to allow me to pay with a swipe initially, insisting on chip -- but once the chip failed 3 times, they'd all happily take the swipe.
The terminal may try, but in Europe since about a decade ago most card issuers will reject stripe transactions on a terminal with a chip reader when the card also has a chip, to prevent downgrade attacks.
> Last time I tried swiping my card — and that was ages ago — the terminal displayed something to the effect of "this card has a chip, please insert the chip".
The problem is that the way the terminal knows "this card has a chip" is that information is encoded on the magstripe. So rewriting the magstripe can just disable that functionality. I assume the merchant could configure their terminals to insist on using the chip no matter what, but it's extremely rare in the US.
One thing I don't get is how other countries require chip+pin for all transactions, but a high percentage of the US terminals I read are comically unreliable for using the chip. If we switched to "always require chip", half my typical transactions would fail because of broken chip readers. Why is there such a discrepancy in the quality of the terminals here vs elsewhere?
Huh? I don't know what's the situation now because I hardly use the chip any more, I mostly tap (the card itself, we no longer have Google Pay), but I don't remember a single time when the chip wouldn't work. The terminals around here look like any mass-produced electronic device, nothing special about them. Though they are old — I do sometimes see newer fancier all-touchscreen ones when I travel to other countries.
There's also one weird model with a secondary keypad on a curly cable that they usually put on the counter, with the main unit somewhere out of sight. It has a small screen and can accept taps. But if you want to use the chip, you have to hand your card over to the cashier to have them insert it into the main unit.
> So rewriting the magstripe can just disable that functionality.
That feels strange to me. If I were designing this protocol, it'd have to first ask the issuing bank whether using the magstripe is ok.
> Huh? I don't know what's the situation now because I hardly use the chip any more, I mostly tap (the card itself, we no longer have Google Pay), but I don't remember a single time when the chip wouldn't work.
Wow. My main card doesn't have tap capability, so I'm forced to use the chip all the time. Read failures are extremely common. I even have my own protocol for when it fails: take it out and shove it back in while holding it firmly to the left edge of the slot. If that doesn't work, try again holding it against the right edge of the slot. Sometimes, it's just sloppy alignment in the slot and doing one of those will fix it. If normal, left-aligned and right-aligned all fail, that makes three attempts so the machine will give up and have you swipe it anyway.
It's happened with every chip card I've ever had. Even with ones that were a couple days old. The cashiers often say "yeah, that chip reader has been acting up" so I know it's not me. There's even a subway sandwich place I go to frequently where one day they had a whole brand new POS system with new readers, and it failed on me, and the cashier said "yeah, brand new system and it almost never works."
The Safeway POS grunts this very annoying alarm sound and shows CHIP MALFUNCTION on the screen, and it's just a standard part of my shopping experience now.
> 3DSecure is a thing and its job is to prevent this exact situation.
3DSecure ticks all the boxes for what you're not supposed to do. Popup window: check, put in your banking username and password while using a merchant site, not your bank's site: check.
I think I've seen a 3dsecure prompt once, maybe twice. I tried to enable it so I could buy fron Aliexpress without calling my card issuer and asking them to turn off all fraud protection on my account for an hour, but that still doesn't work, when I want weird junk direct, gotta call in.
Other verification methods I’ve seen: specific characters from a 3DS-specific password (old nationwide.co.uk), in-app approval notification (wise.com), Swedish BankID app verification (ICA banken, Handelsbanken).
For #5, AMEX asks you if you want to override this, at least for business cards. It’s all or nothing though. But if you want all subs or recurring billing to terminate on a lost or stolen card it is an option.
1. An NFC-enabled EMV card will happily reveal its entire account number and expiration date over NFC with no authentication whatsoever. I don’t know whether the CVV comes along, but I wouldn’t be surprised if it did.
2. (As mentioned in the article) issuers accept transactions from EMV (chip)-capable readers that nominally originate from EMV-capable cards without requiring the chip to be used. So what’s the point of the chip? (Note that this allows a card to be cloned without even touching the card - see #1.)
3. The information leaked in #1 is enough to buy things online (as long as the CVV2 can be found or guessed). Wtf?
4. For some reason I can’t fathom (presumably just laziness), if your card number is stolen, the chip stops working until a replacement shows up.
5. Fancy merchants can arrange a subscription that survives a lost card or even a fraud report against that merchant. But these subscriptions can’t be seen or cancelled on the cardholder website or even by customer service.
But somehow all this comes with fairly stringent PCI requirements, which supposedly represent best practices, despite the entire system design being a case study on worst practices.