[Disposal8433]

You can make fake debit/credit card transactions on a $2 USB card reader. All the specs are here and the protocol is public and documented (IIRC 5000 pages in a lot of PDF, it's a pain in the ass to read).

But to validate those transactions, you must send them to the bank over the internet, and you'll get a visit from the feds/FBI/whatever if you do it.

There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.

[lelanthran]

> There is no real protection on card readers (most use Linux with a small shitty password).

Sure there is: only signed binaries can run, executable filesystem is read-only, data filesystem has noexec bit set, root login is disabled, crippled busybox misses a lot of functionality, keys are loaded from a secure area on bootup, master key injection only available when loading at the factory, bootup itself is more or less secure, tamper detection blanks the chip, etc.

Sure, if you have a cheap non-EMV certified Android terminal imported from Asia it'll probably use a standard Linux, with a rw root filesystem, with root login enabled *and* sudo enabled for the username used to execute applications, tamper-detection is non-existent, screen-casting not locked down, ports are all openable and busybox is more or less complete.

Source: Me. I developed (and still sometimes do) EMV applications for card acquisition for a few years. Even in dev mode (which requires the vendor to provide IDs of the developers), these things are very much locked down solidly.

[cluckindan]

The OP device tried to mount a USB volume and would have started dropbear if it had been found (presumably in PATH). Maybe maybe maybe…

[timewizard]

> Sure there is: only signed binaries can run, executable filesystem is read-only, data filesystem has noexec bit set, root login is disabled, crippled busybox misses a lot of functionality, keys are loaded from a secure area on bootup, master key injection only available when loading at the factory, bootup itself is more or less secure, tamper detection blanks the chip, etc.

Sounds good. Has anyone been hired to attempt to attack the device and find vulnerabilities?

[lelanthran]

> Sounds good. Has anyone been hired to attempt to attack the device and find vulnerabilities?

In the company I work with, yup. I'm not sure about the rest of the industry, but the security in place ensures that even the developers of the EMV applications are treated as hostile actors.

The certification process itself does do a little bit of malicious attempts too (try to get the terminal to do something out of spec, like during pin-entry, etc).

[dijit]

How does the binary signing work?

I’m not looking to hack anything, but it sounds cool to have signed binaries only on linux!!

[lelanthran]

Varies from vendor to vendor; signed-binaries-only is part of the certification process but the exact mechanism itself is not (or maybe that has changed, not sure).

The way it worked in 2003 (when I first wrote EMV applications) was, when we have a binary that we are ready to deploy, we ship that binary to the manufacturer (Schlumbeger(sp?), at that time), if it passes cert-testing, they sign it and ship it back and that's what we would program the terminals with.

The way it works now is pretty much the same - we build an APK bundle, send it to the manufacturer (Verifone, Pax, etc) and after signing they make it available on their appstore which their terminal can access.

[_djo_]

Varies from manufacturer to manufacturer. This is Ingenico's approach, for instance: https://ingenico.com/en/products-services/services/security-...

[shakna]

Whilst I'm sure they use something else, Linux does have an experimental extension, "Integrity Measurement Architecture" extension that allows you to sign and verify RSA keys against every binary.

[zoobab]

ah good to know, I wanted that feature back in 2018 :-)

[account42]

> Even in dev mode (which requires the vendor to provide IDs of the developers), these things are very much locked down solidly.

Probably different vendors but this has not been my experience.

[pabs3]

Have you considered using dm-verity instead of signed binaries?

[lelanthran]

> Have you considered using dm-verity instead of signed binaries?

Why? I don't see any benefits.

In any case, the developers don't get a say in what is used to secure the terminal. The manufacturer decides that, then they get the hardware+firmware certified.

The terminals the developers get are already certified and locked down.

[pabs3]

Authenticating the block device before it reaches the Linux kernel filesystem code.

[Y_Y]

If I buy a device it sure as shit better give me root.

If a payment system is relying on my local privilige on some random-ass device to authenticate a payment it deserves every garbage request it gets.

[account42]

In many cases you are not buying these devices, you are only renting them.

[lelanthran]

> If a payment system is relying on my local privilige on some random-ass device to authenticate a payment

What makes you think it does?

[fragmede]

> If I buy a device it sure as shit better give me root

how's that been working out in practice? change the ring tone on your washing machine, dryer, and microwave already?

[Y_Y]

Those are all mechanical. I could if I fancied, but they're inoffensive and I have more pressing calls for my attention.

[MintPaw]

I didn't even know there were mechanical microwaves.

[wkat4242]

Never seen the ones with a mechanical egg timer as the time control? Those usually even have a mechanical bell.

Of course the microwave generator itself is not mechanical :)

[miki123211]

> The protection comes from the contracts and regulations between the shops and the banks.

While the comment is not quite true (see sibling replies), this part is spot on.

This is also why crackpot theories about people walking around with portable card readers and stealing money from contactless cards are false. Yes you can walk around and make those transactions, what comes after (and the setup you had to do before) is the problem. I'm not even sure whether you could get the money out before being caught and shut down. With how many people these days have push notifications for their transactions, I highly doubt that.

[stephen_g]

I did somehow have two different cards (an Amex and a Visa) compromised at the same time about two months ago, and I do wonder if it was some kind of skimmer setup - if it was just one of them then I'd assume it was just some online store I'd used it at that had been hacked, but I've not used both those cards on the same sites.

I got a notification asking me to confirm a transaction on the Visa and then looked in my app and found they'd actually got another transaction pending at a hotel. I called them up and the hotel said they would "kick out the guests" and refund me. Not sure why they didn't want to call the police on them, because when I called later they said I should report it to the police, but all of the transactions had been refunded so I literally had zero loss and there was nothing really to report... It was them who'd provided the services and suffered the loss, the hotel should have had the police remove them!

Anyway, on the same day the Visa had been used at the hotel, I also had some fraudulent transactions on the Amex, although most of them seemed to be automatically refunded by the vendor themselves (so maybe it was flagged by the vendor's anti-fraud mechanisms and refunded to avoid a chargeback from American Express) before I cancelled the card. They'd tried three times with a similar amount and they'd all refunded.

The other weird thing was that the hotel that the Visa was used at claimed that it had to be a card-present transaction or in a digital wallet, but I didn't get any notification about it being enrolled in a digital wallet and I always had the physical card with me. So not sure if that was mistaken or BS or if they managed to somehow fake the digital wallet.

But yeah it didn't work out for them because I caught the transaction the same day they'd checked in to a hotel with the card and then both were cancelled that day...

[ummonk]

Depending on how reputable the hotel was, it's possible they were in on it and the guests weren't real.

[NoahZuniga]

Maybe they wanted you to call the police, because the money was taken from your account fraudulently.

[stephen_g]

The hotel refunded the pending transaction, so they are the party that suffered the financial loss. If they hadn't done that, then the credit card company would have done a charge-back on the disputed transaction and made me whole, and I wouldn't have suffered a loss in that case either. The first question the police forms for reporting fraud or cybercrime are "how much have you lost" - they don't care if it's 'nothing'.

It's the hotel that has to clean the room, has lost consumables, and has lost revenue from it not being available to be booked...

[rcxdude]

Well, the issue is that you need a merchant account to send the money to, and it's quite hard to get one without identifying yourself, and it takes a bit of time after the transaction to actually get the money because of chargebacks and the like. So you can't just pull the money out directly. But that's true of basically any credit card fraud: what you do instead is buy something from someone who takes credit cards. Which is entirely possible with contactless, you can e.g. proxy a connection from a reader to a victim card, it's just that the limits and difficulty of lining up the time of the transaction with someone walking past make it not particularly useful (compared to just stealing or skimming the card details).

[jojobas]

Didn't people manage to present a remote card (i.e. in a mark's pocket) to a legitimate terminal through an NFC tunnel of sorts? Limited to no pin required amounts, but still.

[champtar]

I remember when contactless was introduced in France, someone from the CB bank card group (https://en.m.wikipedia.org/wiki/CB_Bank_Card_Group) said that contactless was secure because you are insured. At that time France was already using chip+pin for a while.

At the end of the day the money only goes from one bank account to another, account can be frozen, charge reversed, ... So you just need to secure the POS enough that user feel safe to use it and there is a low number of people that can hack them and are willing to risk prison.

[girvo]

> Yes you can walk around and make those transactions, what comes after (and the setup you had to do before) is the problem

I mean with the amount of stolen card details routinely traded and used successfully (at least for a while) and with how little crime like that is investigated or punished in some jurisdictions, I dunno...

Still it's not quite as simple as "taking the money from your card" like said crackpots think.

[MyPasswordSucks]

> I mean with the amount of stolen card details routinely traded and used successfully (at least for a while) and with how little crime like that is investigated or punished in some jurisdictions, I dunno...

There's a huge difference between me using your credit card to buy stuff off Amazon (chance of success: somewhere between "doubtful" and "near-definite" depending mostly on geographical factors and your particular bank), and me walking around with a hacked card reader and stealing money out of your account by dialing in phony transactions directed to my account (chance of success: somewhere between "zero" and "also zero, but with a decimal point followed by more zeroes").

[mihaaly]

Aren't the contracts and regulations holding back the honest people only? But not those who violate contracts and regulations, like the dishonest ones?

[glitchc]

> There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.

I'm afraid that's not true. Merchant terminals have secure hardware embedded inside to store the bank and interchange keys. If those keys leaked, someone could spoof legitimate transactions.

[kuschku]

> If those keys leaked, someone could spoof legitimate transactions.

You mean, whenever those keys leak. It's not that hard to do, see e.g. https://media.ccc.de/v/32c3-7368-shopshifting#t=2207

[glitchc]

Yeah it's definitely an arms race. Interestingly, technology in the States lags behind the rest of the world. Every other country has moved on to chip and PIN, 2FA, obe time tokens and asymmetric cryptography. Whereas in the US, one can still find 3DES signatures and unencrypted authorization codes usable for a time duration (read: multiple transactions).

It seems that the banks here are okay with a certain percentage of shrinkage as long as merchants don't have to upgrade and consumers are not inconvenienced. The banks prefer to eat the cost to maintain large fraud and dispute resolution departments. Whereas elsewhere in the world they're much smaller and mainly focused on correspondent banking. It's really interesting to see that the "customer is always right" policy has such a strong influence on the financial sector.

[csinode]

I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware. (That does seem to be difficult/impossible in this specific case, but it means research in this area is relevant.)

[rockbruno]

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.

[literalAardvark]

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.

[Aurornis]

Sending money to an arbitrary different account isn’t going to happen from the terminal reader itself.

Banks don’t have wide open protocols where anyone can submit a credit card transaction and have it go to arbitrary accounts.

Remember that credit card companies eat the cost of the fraudulent charges. They’re not going to make it easy for those to occur.

[thwarted]

Credit card companies eat the cost of fraudulent charges that they can not pass on to/blame the merchant for.

[Aurornis]

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.

[literalAardvark]

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.

[lelanthran]

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

[nine_k]

Arbitrary account, no. An arbitrary merchant, yes.

[account42]

That typically doesn't even need root access though but only a numeric PIN. Of course rout access might let you conceal what you are doing better.

[Arrowmaster]

You should read up on the wonderful system they call ACH.

[kortilla]

That’s precisely why credit card readers aren’t attached to it

[lelanthran]

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

Not from the card reader.

[cesarb]

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.

[clait]

I was victim on this attack in Argentina. Paid a taxi with my card, and got charged 50x the amount shown on the display.

[weaksauce]

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.

[cesarb]

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.

[mrngm]

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

[account42]

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.

[bdangubic]

2 times just this week I was asked to swipe, “issues with the chip reader” (CVS and Wegmans)

[jamwil]

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.

[joefife]

Seems surprising to me. I've not swiped a UK card in many years. Honestly can't remember the last time.

It's curious you're seeing so many stripe fallback incidents. Is this a USA issue?

[girvo]

That's wild to me, the last time I had to swipe my card here in Australia was sometime in the early 2010s!

Heck a lot of the terminals here can't swipe a card at all

[SoftTalker]

In the USA, gas station pay-at-the-pump were the last major holdouts, but it’s been a while since I saw a pump that didn’t use chip or tap to pay.

My HSA debit card, issued last year, still doesn’t have a chip.

[kccqzy]

Old automatic vending machines and old municipal parking meters still require swipes.

[Symbiote]

In some regions, credit/debit cards no longer have magnetic strips.

If I travel to the USA I'll be unable to use these old vending machines and parking meters.

[pornel]

> unless it's changed recently

In Europe it's changed 15-20 years ago, when EMV-capable terminals became required, and acceptance of magnetic stripe cards got phased out soon after.

Since Apple Pay became a thing a decade ago, we don't even get US tourists confused by inability to swipe their cards anymore.

[account42]

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.

[mrngm]

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.

... such as this one: https://www.paxtechnology.com/a77

[cwillu]

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

[nine_k]

Someone with a root access to a card reader could just make it collect CC details with every transaction, no caches needed. It could also make certain transactions "temporarily fail", while siphoning a certain amount of funds to another, legit-looking, merchant under the hood.

[jhugo]

> could just make it collect CC details with every transaction

Only if the card is swiped (magnetic stripe) rather than tapped or inserted. EMV doesn't expose the full card details to the merchant; the card signs a payload with its internal private key and transmits it.

And the OP's root access wouldn't give card details in any case, because they didn't get root on the part of the reader that processes the transactions.

[reaperducer]

I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware.

That's happened at least several times already.

I believe breached PoS terminals were what happened in the big Target hack.

[lelanthran]

> I believe breached PoS terminals were what happened in the big Target hack.

The problem is that PoS terminals are not EMV terminals. EMV terminals have been through a certification process, and the hardware part of that certification ensures that the vendor only runs signed-binaries.

Honestly, even if you could write and sideload (or even replace) the applications on the EMV terminal, I do not see a way to get them to a) run, and then b) send money elsewhere.

[adolph]

This story about a physical card reader checker to detect skimmer devices was interesting and posted here a couple years back.

https://tech.target.com/blog/cybersecurity-easysweep

https://news.ycombinator.com/item?id=36788831

[christina97]

There are much easier ways to skim cards than hacking the terminal.

[account42]

Not without leaving physical evidence.

[stef25]

> You can make fake debit/credit card transactions on a $2 USB card reader

Not asking "teach me how to do this" but could you explain in a little more detail ?

[quesera]

I believe GP is confused.

You can read a card (stripe) with one of those cheap readers. The magnetic stripe is not encrypted and you can extract the card number (PAN), expiration date, and cardholder name. Some other less important bits too. You cannot extract the CVV this way, but that is not required for transactions.

Most cards are EMV now. That data is encrypted and it's read/write. These keys can leak, putting you back into a similar state as if you'd read the card via magnetic stripe.

But no amount of card reading gives you the ability to submit transactions to the network. For that, you'd need merchant credentials for their gateway or processor, and you'd usually need to have a presence on the merchant's network (to get through the upstream firewall).

These are all achievable things. Doing so gets you the ability to create transactions against the card. These transactions will be submitted to the network and approved or declined. If approved, funds will settle from the issuing bank to the merchant bank, possibly in multiple steps.

I'm oversimplifying a bit, but the essential point is that funds will settle to the merchant's bank account, not yours. You can cause some headaches, but you cannot steal money.

The compromise of a credit card terminal is only interesting because it gives an attacker the ability to steal the card details for all cards that are subsequently used at the compromised terminal. They can be saved and retrieved later, or sent out to a C&C server, etc. Then these card details can be used for all the usual types of credit card fraud.

[account42]

Wouldn't the concern being redirecting the money to a different merchant account? Of course that would mean you are easily tracked down when found out but I'm sure you can find a way that some schmuck who doesn't actually know anything about you ends up with that role.

Then again, changing the merchant account is usually only protected by a numerical PIN so you wouldn't need root access. Maybe it would be to send the original requested amount to the expected merchant account but also do a separate smaller transaction to your own account?

[quesera]

The configuration of the settlement bank account happens at the processor. If you want to change it, you need to talk to customer service and fill out a PDF form, with signatures and other human verification processes.

If it were possible to change the settlement account via an online portal or similar, then you'd need the user login credentials for that portal. In which case, compromising the card reader has no additional value.

[fragmede]

this is all true, but if you've compromised a merchant deeply, it doesn't seems impossible to run a $1 charge as a (bad) customer and then give that customer (you) a, say, $1,000 refund.

[quesera]

You can only void existing transactions, so the money would be returned to the same card, and the amount would be limited to the originally captured amount.

It is possible to create a "push" transaction too of course. Visa Direct, Mastercard MoneySend, etc. But that requires a separate merchant account, and should not be possible from the card reader or POS.

If you've compromised deeply enough to be in the AP system, you can create arbitrary payments, but that's well out of scope for this thread.

[stef25]

> if you've compromised a merchant deeply

Then you could just complete a normal transaction on their website and introduce your account in to their system that way, no real need for a compromised terminal?

[rswail]

How exactly are you going to get the diversified IPEK to generate the necessary keys to create the HMAC for the transaction that will be authorized by your merchant acquirer?

The BDK for your merchant acquirer is held by them in an HSM or equivalent. The IPEK is device specific, derived from the BDK based on the terminal ID.

The individual keys for the HMAC are generated for each transaction and are cryptographically linked to a transaction ID and the IPEK, so that the acquirer can determine whether there are missing messages.

Card readers that comply with the latest EMV chip/contactless standards require a secure element that maintains the crypto information and only allows specific requests from the non-secure element and only provides encrypted blobs for transmission between the acquirer backend and the secure element.

https://en.wikipedia.org/wiki/Derived_unique_key_per_transac...

[bogantech]

> But to validate those transactions, you must send them to the bank over the internet

Not how it works at all, banks don't have some open API on the internet for processing card transactions

[tialaramex]

I agree that this isn't how it works.

The first thing to understand at an even higher level about payment cards is that they have always had two separate and barely related components, Authorisation and Settlement.

Authorisation is concerned with whether this specific transaction has been approved in some sense by a card issuer. Authorization today is relatively high tech, there's somewhat decent cryptography, tamper resistance, uniqueness = they really care - and that's because when Authorization problems occur the banks might lose money, which they hate.

Settlement is "just" moving the money from one customer to another. $123.45 from Jim Smith to Terrible Goose Inc, done. This is very mid-late-20th century technology, we're not talking pieces of paper and scribbly hand writing, but fixed width ASCII fields on magnetic tape is fine - it's the customer's money so the banks don't care more than legally required.

Settlement replays are how you get "accidents" where a big store's customers all get charged twice for a whole day - the associated Authorizations can't be replayed, that's the banks money at risk - but the settlements aren't protected.

Merchants can, and some do, choose not to care about Authorization. In a huge business it could make sense to eat say 2% of sales as undetected fraud (ie you never receive payment) rather than have any transactions fail. If you operate a food truck using a terminal to take $1000 per day on your iPhone the people who supply your terminal may not let you opt out because that's risk they don't want. But if Jeff Bezos or Doug McMillon makes more without Auth he's turning it off.

[quesera]

This terminology is not quite right for the US. I'm assuming you're from elsewhere due to the "s" in authorization. :)

In the US, the two steps for the merchant are Authorize (optional) and Capture. If both steps are performed, it's a dual-message transaction. If you skip Auth, it's a single-message transaction.

Settlement of funds is a multiparty bank-bank-bank operation, in which merchants are not directly involved.

[nine_k]

It's over the Internet, because you're not going to run a dedicated fiber to every card reader. But it's not over the unprotected internet; your card reader will establish a VPN connection of sorts, or at least talk via an encrypted channel (think TLS) is you use e.g. a Square terminal.

Not that a random person can hit these endpoints, unauthenticated, and try to run a transaction.

[salawat]

Correct. In point of fact, payment cards/merchant networks are quite literally just that. You get a credential, and that credential can be revoked if you get up to something sufficiently heinous to warrant the ostracizing.

People would be surprised if they really took the time to learn how much of life is just operating on good graces.

[NoahZuniga]

I mean, maybe they don't have an open API, but they sure do have an API on the internet. Surely the payment terminals are communicating with the issuing bank in someway, perhaps over an interface of some kind.

I believe what this comment is getting at is that making fake transactions is useless without a connection to a bank that will execute them.

[charcircuit]

>and you'll get a visit from the feds/FBI/whatever if you do it

Is there any proof to this statement or are you just trying to scare people? I think it's possible there are bigger groups that would have their attention and a single fraudulent transaction would just be noise.

[Nextgrid]

In his scenario I don't understand where he'd send the transaction to begin with?

In a typical scenario my understanding is that you get the terminal from your acquirer - this is your broker to the card networks. When the terminal makes a transaction, it does some crypto magic using its own keys (that identify it to the acquirer), sends that to the card which does more crypto magic using its own keys, and finally the result of that is sent to the acquirer.

If you do this flow yourself with fake keys you'd get the card to sign a transaction for your fake terminal's key (assuming you know the card's PIN of course - unless you're happy to forego any CVM), but you have no acquirer that would accept said transaction, so I don't see how you could commit a crime here even if you wanted to? You just got some meaningless bytes back.

And of course, if you have an actually valid terminal key that is trusted by an acquirer and do all this, you've effectively just made a normal payment - if the person was willingly paying you then no crime either, and otherwise it's no different than using a legit terminal to bill someone without their knowledge.

[cyberax]

> And of course, if you have an actually valid terminal key that is trusted by an acquirer and do all this, you've effectively just made a normal payment - if the person was willingly paying you

You can charge more than the displayed value. But that's pretty much it.

[_1tem]

What if you live in a country where Visa/Mastercard works but is way out of the jurisdiction of the feds?

[Toritori12]

I thought most POS devices stop accepting "offline" payments.

[sgjohnson]

Maybe today, when the line between a Credit and a Debit card has gotten significantly blurrier (except in the US).

I definitely remember making an _offline_ payment with an AMEX card at a restaurant in the UK some 10 years ago.

Also, most airlines that take payments on board also run the terminals in offline mode.

There must be some mapping of BIN codes and whether to allow an offline transaction.

[glitchc]

It's up to the merchant to decide if they want to support offline payments and to what limit. The terminals certainly allow it. Your transaction will be stored in a secure way (either encrypted or in a secure element) until the terminal reconnects.

The way the rules are set up though, the risk of a failed offline transaction is almost entirely borne by the merchant. In most cases the merchant is unwilling to accept this risk and disables the feature.

[sgjohnson]

I guess for a restaurant it basically always makes sense to accept offline payments. I wasn’t aware that they might not be able to process card payments when I ordered.

I don’t typically carry any cash on me, and, well, if their terminals go down before I’ve closed my tab, they assume all of the risk anyway.

[tough]

I remember doing offline debit card payments 10y ago in a flight

they would pass the card with one of those old engraving things lol

[pjerem]

I think it’s still pretty frequent even nowadays. I have payment cards with systematic authorization and and others without and I can totally see the difference.

Transactions with the cards requiring authorization will take several seconds while with my other cards it will be instant most of the time.

It depends on the configuration of the terminal : most merchant will allow offline (or asynchronous) transactions up to a certain amount when there is an important flux of customers waiting to pay.

I’m also pretty sure (that’s speculation at that point but I felt it in my experience) that some cards have more chances to have instant (offline) transactions than others. The more « premium » the cards the less I saw the "waiting for authorization" screen. Especially for small amounts.

[Delk]

I remember paying at a bike repair shop that used a physical card imprinter [1], some, I don't know, 15 years ago?

[1] https://en.wikipedia.org/wiki/Credit_card_imprinter

[Nextgrid]

It also depends on the card. The card can decide and even stores a running counter of how much has been processed offline, after which it will want to go online to check and reset its counter.

[LeonM]

> Also, most airlines that take payments on board also run the terminals in offline mode.

Anecdotal, but most airliners I have recently flown with seem to have switched to online POS terminals, though they do still seem retain offline payment functionality as a fallback. I've seen payments being made, only for the flight attendant to return back to the passenger a few minutes later to inform that the payment was declined. This was over the ocean, so definitely no ground communication.

Airplanes for commercial flight all have VHF/HF or satellite connectivity, the've had that for a long time already. It's used for functionality like ACARS, voice connectivity, remote monitoring / diagnosis, etc. I can imagine this can also be used for payments and other low-bandwidth functionality.

Most airplanes also have WiFi access points on board, even when not offered to passengers. Typically these use hidden SSIDs. Speaking to an airplane tech once I know these are used for flight-crew handheld devices such as the POS terminals and iPads.

I happen to have a few friends that are pilots (all working for the same company) and they told me that their entire fleet already has Starlink terminals retrofitted, though they aren't offering that to passengers yet.

I guess what I'm trying to convey here is: the era of airplanes being 'offline' is already behind us.

[supertrope]

United Airlines requires credit cards to be linked to their app before takeoff. I assume this lets them run an authorization test charge to identify bad cards. https://www.united.com/en/us/fly/travel/inflight/save-a-form...

[account42]

Passenger WiFi is already not that rare, all that is missing now is for prices to come down to reasonable levels.

[TacticalCoder]

> There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.

Wait wait wait... Aren't these EMV cards smart cards using the Java smart card technology? I thought these were heavily using encryption, including PKCS.

They're using challenge/response protected by the PIN no!? If I am not mistaken if you insert a card in a totally compromised reader you cannot clone the card: that alone is already quite an amazing feature compared to where we're coming from with the magnetic stripes ones (and the date to sunset for good magnetic stripes in the EU has already been set IIRC).

A fully compromised reader could trick you in stealing your PIN (so that an accomplice could then later on steal the card physically) and a compromised reader could also trick you into signing a 2 EUR transaction while it's actually wiring 2 000 EUR out of your account but I think that's about it!?

It comes to this: either the card can be cloned from a compromised reader or it cannot. I don't think that someone inserting it's card and getting its PIN intercepted means: "Bad guy can do countless transactions for days on until the account is empty".

If I'm right, that's a very far cry from "protection comes from the contracts and regulations between the shops and the bank".

AIUI a compromised reader can fake one big transaction or maybe a few transaction in quick succession but as soon as the owner pulls its card, they cannot do anything anymore?