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.
The american reliance on magstrips is crazy. Over here(Poland) I don't think I've seen a magstrip-compatible terminal for years, they just don't have the swipe part anymore, it's been removed from terminals and cash registers ages ago.
American here- most retail terminals here support NFC and chip- I haven't used magstrip in a retail environment for years- even mom-and-pop shops support NFC. Most gas stations accept chip, but not many accept NFC yet, though I'm seeing it more and more. Some gas stations still only accept magstrip.
We still have the stupid policy in restaurants where you hand your card to the server and they walk away with it (their terminals are usually chip), which is something that a lot of foreigners freak out about.
>>which is something that a lot of foreigners freak out about.
Well yes, we're being told by our banks specifically that if you give anyone your card and they walk away with it, they won't cover you for fraud. The card has to stay in your sight at all times. In fact if you are in EU and you find a business that does this, you can report them to Visa/Mastercard and they will get a warning if not outright lose their terminal.
> We still have the stupid policy in restaurants where you hand your card to the server and they walk away with it (their terminals are usually chip), which is something that a lot of foreigners freak out about.
And rightfully so! What is stopping them from copying the PAN, expiry date and CVV2?
I wouldn't give my card to anyone - that's what portable (wifi/BT) terminals are for.
What stops a server with a good memory from looking at your card as they put it in their terminal and remembering it for the 30 seconds it takes to walk away and note it down? They already reliably remember fairly complicated table orders which have got to have more bits of entropy than a credit card number.
Credit cards handle risk very differently than we do for account passwords. They expect numbers to leak regularly, but the downside of a leak is bounded in a way that password leaks often aren't, and the issuers and merchants eat those losses as a cost of business.
Here in Canada, servers never touch your payment cards. They hand you the wireless card terminal and you insert it yourself. Or you pay on your way out at the front counter at a standard terminal.
Even at drive-through restaurants, the cashier hands you the entire corded terminal through the window (well, most of the time contactless payments are used, in which case they simply hold it out for you to tap your card until they hear a beeeep). During Covid, most places mounted them on the end of a stick, and that practice has continued even once social distancing requirements were lifted.
I use my phone it doesn't even show the number, but you can cover the number in case of random servers who can remember 16 digits effortlessly in 2 second
No security is perfect but that's no reason to skip basic easy precautions
US merchants have widely accepted magnetic stripe card payments for many decades more than the rest of the world. It's a pretty typical example of a first-mover disadvantage: More legacy systems to deal with.
That said, the switch to chip and contactless is happening pretty rapidly, in my experience, with an also entirely expected long tail of merchants that will probably hold on to their legacy POSes as long as technically possible.
In Russia no one swipes their cards, and swiping doesn't work if you try, but the terminals do have the swipe part and the cards do still come with magstripes. There's a separate magstripe reader, usually built into the cashier's monitor, at places that use magstripe cards for loyalty and gift cards.
I'm wondering why they don't use the payment terminal's reader mode for this. I know it can be done – Rimi shops in Baltic states handle both magstripe and NFC loyalty cards through the terminal (just regular Ingenico ICTxxx line terminals, like many shops in Russia use).
I suspect this has to do with the POS software Russian stores use being inflexible or bank SDKs being restrictive. Probably the latter, as I've seen some kiosks that take card payments just pop up a Windows window with the Sberbank logo and transaction status instead of showing that in their own UI.
The US market has been historically different for other reasons.
The big one is liability. In the US the cardholder is rarely liable for fraud charges. Which is why the minutiae of credit card security mechanisms just kind of doesn’t matter to us.
But from my understanding, in Europe and places like India, the cardholder is usually liable. Which also explains why cardholders seem to be a lot more anxious about these things in those countries and don’t really understand how Americans don’t care too much, say, that a waiter can walk off with your credit card at a restaurant.
Not claiming one system is better than the other… actually no, maybe I’m biased but I’m happy that the US system places liability on businesses rather than consumers. Which is why most US customers don’t care about these things and freely use their cards for everything.
> in Europe and places like India, the cardholder is usually liable
I suppose it depends on what you mean by "usually" but no, in the EU generally you just go to the police station which has a form for declaring credit card fraud and the bank often reimburses you before receiving it. Your replacement card is free on this situation. It is up to the bank to get their money back if they want to bother.
I don't know of a situation where you wouldn't get reimbursed by your bank.
The US market also has a lot higher margins to absorb any fraud - they have higher fees (since fees are capped to 0.2-0.3% in EU) and historically have had higher credit utilization. So they decided that "friction" costs more than fraud.
They just have a chip like any other card? I bought a mastercard gift card some time ago and it just came with a pin. In fact I think gift cards don't even have a swipe part at all, and my own visa/mastercard cards still have it but I have it disabled through my online bank account - so I assume any magstrip transaction for those cards would be just rejected entirely.
I have 2 gift cards and one additional "LunchPass" card issued this year in Poland, all three are magstrip only.
The magstrip readers are not removed from the terminals, even the newest smartphone-like have them, you just don't know where to look. Of course, sometimes cashiers are surprised that my card is magstrip-only and they are double-surprised when I show them where is the magstrip reader on the terminal they use :)
Although you can disable the bits in the service code pertaining to the cards ICC capabilities, in theory there's a good chance that the track2 equivalent data on the chip is different from the track2 data on the magstrip. That would make it easy for the issuer to determine that the track2 has been modified and reject the transaction and/or flag the account for fraudulent activity.
Yeah, whenever I try to swipe my card, it instantly tells me to use Chip and PIN. I think it's just to provide rapid localized responses, but who knows if some banks are misconfigured and overly trusted the magstripe data to block magstripe transactions.
You can see whole credit card number in the iron oxide encoding in the picture of the whole backside of the card with electrical tape covering the signature. The author seems to have wiped away the iron oxide but enough residue is left behind that you can still read it.
> the bits stating the card has Chip-and-PIN can be turned off from the magstripe
This is true, but it's not the last line of defence, right? The bank could still reject the transaction if it sees a chip card used to do a magstripe transaction on a chip-capable reader. That relies on the reader providing that information to the bank, though, and while I believe the EMV protocol can do that, I don't know if that's used for magstripe transactions (talking purely reader to bank here, not reader to card).
I don't think it can be fairly considered a security issue that the “I'm a chip card, why are you swiping me” bit is on the magnetic stripe. It's obvious that doesn't protect against modification, but it's not supposed to! Hell, it's probably only meant to be a reminder anyway, as you can subvert it by making the card reader think the chip isn't working.
I long for the day I can carry my phone or watch without needing keys or wallet. The fact that most adults carry at least 3 things (keys/phone/wallet) at all times in 2022 is crazy.
I agree it would be convenient. But consider the new dangers: 1) pickpocketing would suddenly be 3x as profitable and 3x as easy, 2) lose one thing and you've lost everything, 3) if one thing stops working, everything stops working, 4) venues where you have to give up your phone means carrying extra cash in.... a wallet, 5) cybercriminals can now steal much more from you without ever getting near you, 6) I imagine there will never be a universal standard for these things so changing vendor will be quite difficult.
I can theoretically leave my home with just my smartphone. I can use it to pay fare at the local train station, get directions to restaurants, read the news, pay for food and coffee, and even lock / unlock my apartment.
I do still bring my wallet and keys, because I'd hate to run into a scenario where my phone does get lost, stolen, or damaged, leaving me stranded without a way to get home. But the concept is definitely there, and for someone less paranoid than I, it's definitely possible to live a life of convenience.
1) so lose the keychain and evenly distributed your keys in all your pockets to minimize the percentage of personal items lost per successful pickpocket
I’ve long wanted to do this, as a kid I added NFC (at the time, simply RFID) door locking to my 1989 jetta so I didn’t have to fumble for keys. It turns out I do live in the future. I don’t lock my house, so that’s one less key right away, but there are some keyless door locks on the market if you still need them, and those could probably be automated with something like home assistant. I have a tesla that uses a phone for a key. Work has a key card, it’s a proprietary system but I could shrink one into a ring or something. I don’t carry cash, but instead use a magnetic wallet on my phone from popsockets (apple makes one too) for physical cards, although I mostly use apple pay. No digital driver’s license here yet however, so I needed a place to keep cards anyway. In Seoul the metro pass is a simple NFC sticker that you place on the back of your phone. So, no keys for me! Everything is built around the phone, which is fine until I lose access to it…
My personal example of this, allowing me to cut down on my daily carry:
- Cards stored in Apple Wallet
- Health/Vehicle insurance card available via an app
- Driver's License available via state-issued app
- FlexNT NFC implants located in both of my middle fingers, allowing me to lock/unlock my house using Home Assistant + a scanner I built based on an ESP32 & PN532.
Sure, I'm more reliant on the device in my pocket - which can definitely be an issue if it's dead. However, I work from home and am rarely in situations where that predicament would arise.
That day is closer than you may think. I sometimes only have my phone with me as i can pay using only it (something like Google/Apple pay, but through my bank's app) and can unlock my front door thanks to Home Assistant. Both of those (should, I don't have one) work with a smart watch.
Can’t help you with the keys or ID (yet), but I exclusively use the stored cards on my Apple Watch for payment. It is so reliable (in Norway) that I haven’t brought my wallet on normal days in 2+ years.
Even on vacation in Northern Europe (Belgium, Netherlands, France, Germany) and on a business trip to the US (California+Texas) this year, I very rarely had to use the physical cards. NFC just works. Everywhere.
I still bring the cards on important occasions or when going further than a normal drive, though - a testament to the fact that the day you’re longing for is not _quite_ here yet.
It’s a great idea until the battery in your devices fail and you’re stranded somewhere with no ID, no way to communicate, and no money for a train ticket.
I could leave my keys at home, but most days now I'm traveling with my security keys, partly to keep them away from my desk at home and partly in case I might need to login to a secure account while out and about.
I'm not sure this is useful for credit cards at all - ever since the deadline for chipped cards to roll out passed, my issuers all decline swipe transactions. Even at middle of nowhere gas pumps that don't have chip readers, I found two during my last cross-country trip, swiping the card will get a decline response.
Many places in USA, you can 'fall back' to magstripe by inserting the chip and having it fail to read 3 or 4 or 5 times. The reader will prompt for a swipe after the threshold of failed attempts is reached. I'm really tough on my cards and when the chip dies this becomes my routine everywhere until the new one comes in the mail.
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.