Hacker News Reader

Comment by witheld | Hacker News Reader

If it’s anything like American McDonald’s those card readers should be hooked up over the network- not USB. There shouldn’t be a trivial way to use them as card skimmers, the software loaded on them, doesn’t just like hand out card numbers it processes the transaction.

Now, if they are hackable, and if they’re networked, or if you’re in America, your target is the Ethernet ports strategically hidden around the store. Look under and behind soda machines, inside cabinets in the lobby used to store napkins and stuff, randomly on the walls in the playplace etc

I don’t know about skimming cards from those ethernet ports, but you will have full access to the entire POS system which includes ordering and business data and the backend server.

View on HN

Even if they completely screwed up all the security in a way that would never pass compliance testing broadcasting all card info for every transaction to the network in the clear, with EMV cards all you’d get are EMV tags that are useless for anything but taking that one payment on that one terminal at that one time for that one amount.

You couldn’t use anything you harvest to make a new transaction on the cards, or even replay the transactions you saw.

(Mag-stripe is different, don’t use that!)

Yeah - I'm fairly certain payment terminals, USB or otherwise, do not provide credit card numbers in clear text. Any card information is encrypted on-device, then sent to the payment gateway - and the readers usually have some sort of anti-tamper stuff to at least prevent them from being opened up and the encryption key compromised or the hardware hijacked.

FiPay (which is one of the pieces of software you can run with Verifone terminals) can be configured to return a credit card number back, but, it's only for legacy point of sales applications that need to have a number for whatever reason.

Even after moving everything to our Verifone vault, we still had those fields in our point of sales database, even if all of the numbers were '4111 1111 1111 1111' and the expiration dates were 2099+. We would pass the "proper" things down for the receipt as text fields (AID/TID/etc) to be printed on the receipt and stored with the transaction log.

EMV tags gives you parts of the card number (so you can tell the kind of card or put the last 4 on receipt) but you don’t get the full number anymore like with mag-stripe.

Why would you spend money on switch ports for patching unused outlets?

The card readers are processing transactions? Wouldn’t there be a giant mainframe doing that somewhere?

It’s a combination of both sides. It’s something like this:

For EMV the terminal and the card generate a request, and send it to the payment processor/bank.

They say yes/no and send back some stuff needed to complete the transaction. At this point there would be a hold on your card.

The terminal and card verify that and finish things, preparing proof of the final transaction.

That’s sent to the processor again who confirms the transaction took place. This is when the money is taken and the hold disappears.

Final proof from the processor is sent back to the terminal so the system knows everything went through. Now you get your receipt.

The nitty gritty of everyday things like this can be so interesting sometimes

I learned a lot of neat stuff about this process and other things around it as a side benefit of some of the tasks I was given at a job.

It was fun to learn, and to see how they solved some of the problems that would come up that you might not think about.

Of course the side effect is you also learn just how insecure older CC tech was. I think almost everyone sort of notice that at this point, but once you start learning the details… it’s bad. Basically electronically writing down CC numbers like they might have in the ‘60s, assuming people are good and trustworthy.

It's a bit tricky with different payment flows possible for all kinds of scenarios.

While at some point the transaction will get to "a giant mainframe somewhere" to get processed, it may or may not be during the process that a customer sees. It may be a "online" transaction where it's essentially that the terminal prepares a transaction message, the chipcard signs it, and then forwards it to issuing institution for authorization (including but not limited to checking availability of funds); or it may be permitted, within certain limits and depending on configuration, to have the chipcard sign the transaction and then deliver it for processing some time later (e.g. at end of day) so that either you can enable transactions in places which do not have internet access, or simply for processing speed for small amounts, taking on some limited risk for customer convenience.

Reply on news.ycombinator.com