Aren't credit cards nowadays basically physical private keys? IIRC transactions are one-time payloads signed specifically for that operations, so intercepting that won't help you if I'm not mistaken about how cards work nowadays.
Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance. And maybe even send the money to a different account.
Which is why they won’t have a public API that allows running transactions that send money to arbitrary accounts.
If someone altered the terminal to charge more (a hypothetical suggestion above), they could recoup that money from the merchant’s account because they have an agreement in place.
You can’t run arbitrary transactions to arbitrary accounts (the other proposed attack above) because there isn’t an agreement in place.
Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.
> Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.
I've got a couple on my desk right now; there's nothing I can do with them to steal money, even though they're in dev-mode.
> Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.
That would be something I'd like to see. The terminals I have worked on do not store merchant details. A merchant ID is stored on the terminal, with the ID mapping to an actual merchant account on the backend.
In order to have the merchant account on the backend, you need to be a customer of that terminal supplier. If you are a customer, they know:
a) Where your terminals are deployed
b) Your real details
c) The terminal's ID and the terminal's serial that maps to that specific merchant ID.
So, let's say we do change the merchant ID from `12` to `24` on the terminal. The request goes up with `transaction(<amt>, 24, 'sr-12345')`, and then the backend rejects because terminal sr-12345 is not mapped to merchant 24.
Lets say we also manage to fake the serial number. Then the transaction is approved, but can be easily reversed because merchant 24 is a customer and we have:
1. Their bank account number
2. Their physical address
3. The company registration number
4. Verified ID copies of the owner, directors, managers, etc.
5. Their money (from their transactions).
So, yeah, I'd love to know more about how they execute this hack; it would require complicity on the backend to a large degree.
> Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance.
Not supposed to be possible on a certified terminal. The certification tests this particular case (the transaction is a hash of the keys, amount and a few other things. The display of the swipe/tap/insert screen and the pin-entry are under control of the certified kernel, so the userspacve application has no control of the amount that is displayed).
> And maybe even send the money to a different account.
I've heard of it happening here in Brazil. In the simplest variant, something is glued on top of the screen to hide the higher digits, making the value appear to be lower; supposedly, some more advanced variants of the scam have a damaged or tampered screen.
unless it's changed recently that only applies to tap and chip payments (which you should always prefer to avoid card skimmers) and not the old slide the ~~barcode~~ magnetic strip kinda payment.
Does anyone still use the magnetic strip? I think it's been over a decade since I've seen a credit card without the chip, and terminals have been able to read the chip since forever. I think the last few times a store tried to use the magnetic strip on my card (because the chip failed to read due to a bad contact), the transaction was simply rejected due to not using the chip.
Yes, occasionally when refueling a shared car owned by a company that distributes those cars all over The Netherlands. It's common here in leased car fleets as well, where the user gets a magstripe card to refuel (and needs to provide details about current mileage and if the car was a replacement car).
I used it recently because my bank denied the contactless and chip payments I tried before that. Surprisingly the mag stripe worked - and this is with card issues from a EU bank where mag stripes have been an historical artifact much longer than in the US.
USA was very late to adopt chip/tap terminals, even relative to Canada. I could be wrong but IIRC it was only when Apple Pay came along that tap-enabled terminals began to hit critical mass.
It's always incredible to see few people in the US uses the tech that's available until Apple makes it a thing, and seeing that play out over and over.
This is the same everywhere though. See, e.g. incredibly late fibre rollout in many well off EU countries because they already had copper in the ground everywhere vs. developing countries that never had that legacy infrastructure inertia.
What I'm talking about is a lot of those terminals supported tap to pay well before Apple Pay became a thing. The infrastructure was there, the technology was there, you could use it if you cared to do so. Most people just didn't know it was even an option. Google Wallet supported tap to pay years before Apple Pay was even announced. Tap to pay credit cards existed years before then. Nobody gave a shit about the technology until Apple announced Apple Pay and suddenly it became a big deal for vendors to actually check if their POS systems had it enabled or not.
I remember using Google Wallet years before Apple pay existed. When Apple Pay was announced so many cashiers thought they didn't support tap to pay credit card transactions despite me using it at those locations for years. What was really annoying was a lot of vendors turned off the feature while they "investigated" supporting Apple Pay, and didn't turn it back on for another year or so after they slapped the Apple Pay logo on the exact same terminals.
Note that is for the merchant side, not for the customer side - my EU-issued card still has a working mag stripe (got a chance to verify that it works this year).
And on a tangent about confused customers - I wish where to tap was as obvious as where to swipe. It varies by reader and sometimes that contactless logo is hard to see.
Not to mention the (usually mobile) terminal designs where only the merchant sees the amount entered, usually doesn't flip it to show it to the customer, and the customer needs to tap it on their side without first seeing the amount entered.
“which you should always prefer to avoid card skimmers” could use a disambiguation comma between “prefer” and “to”; I misread it several times before the intended meaning clicked.
