8 ms·

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 o

• isoprophlex 4y ago
  > [...] 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. Criminally hilarious.
  • amluto 4y ago
    > Criminally hilarious. 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.
  • Scoundreller 4y ago
    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.
    • atyppo 4y ago
      They wouldn’t have fixed this since 2015? Seems highly dubious to me.
  • iancarroll 4y ago
    Amex is already legally responsible for fraudulent charges on your card, so if they want to make the numbers predictable, why not?
    • jjeaff 4y ago
      Actually, the merchants are fully responsible for fraudulent charges. So Amex has little incentive to be secure.
      • iancarroll 4y ago
        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.
        • tyingq 4y ago
          "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.
  • jeffbee 4y ago
    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).
• Scoundreller 4y ago
  > 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.
  • amluto 4y ago
    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.)
    • lxgr 4y ago
      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.
      • amluto 4y ago
        > 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.
• gambiting 4y ago
  >>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.
  • ComputerGuru 4y ago
    It's a legal requirement for EU vendors but the cards themselves (or at least some of them) can still be used without 3DSecure.
    • lxgr 4y ago
      No, issuers need to enforce 3DS as well (for payments within the EEA), unless there is an applicable exemption.
• lxgr 4y ago
  > 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.
  • amluto 4y ago
    > I'd cut the original designers some slack. 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.
• grishka 4y ago
  > 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.
  • iudqnolq 4y ago
    > 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.
    • pinko 4y ago
      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.
      • kalleboo 4y ago
        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.
        • pinko 4y ago
          Ah yes, my comment was totally US-centric, which is dumb of me.
• themagician 4y ago
  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.