Credit Card Processing in 700 Words or Less

Published: 2014-07-03
Last Updated: 2014-07-03 19:06:14 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

When PF Changs published an update about it's breach earlier this week, a few readers asked about the use of "encrypted terminals". Aren't all credit card transactions "encrypted"? The quick answer is: yes. But not all transactions are encrypted all the time.

To answer some of these questions, I figured I will use this diary as a TL;DR edition to credit card processing. There are a number of terms that are often confused when it comes to credit cards, and how they are processed.

If you enter a credit card on a web site, the process is typically pretty straight forward if implemented correctly: The credit card reaches the web server via SSL. The web server then typically hands the card to a payment processor (again: via SSL) and receives a confirmation code back that can later be used to identify the transaction. The confirmation code is often shared with the customer and doesn't require an specific safeguarding. It may be used to void the transaction. But this would also require the merchants credentials in addition to the code, so the customer can't void it without the merchant's approval.

The merchant does not need to store the credit card number. As should not store it at all. However, the credit card number is still exposed in memory while it is being processed and careless coding often leads to data like credit card numbers being logged. So while the card can't be read off the wire, it can still be read off the server if the server is compromised.

Now what about repeat billing? Does your phone company need to store the number so it can charge your credit card once a month? No. In addition to a confirmation number, the credit card processor can hand a token back to the merchant. The merchant can now use this token to apply additional charges to the card. This token is only good for a particular merchant. If it is stolen, an attacker could charge the account, but any funds would go to the merchant the token was stolen from, not to the attacker. More interesting: The token is linked to your account, not your credit card number. If you receive a new credit card number (e.g. after your card was compromised), the merchant is still able to charge the account. This is very convenient for recurring payments like utility bills.

Where things get actually more interesting these days is retail scenarios. Many people still think that handing your card to a clerk is more secure then typing it into a website. However, what happens is essentially the same thing as when you type it into a website, with the exception that the clerk swipes the card at a PoS system, that may be compromised (just like your PC may be compromised when you type in the number). 

The best defense against a compromised PoS system is to encrypt the number in the reader, before it hits the PoS system. Some readers support this feature, and it requires that the reader be used with a specific processor who holds the decryption key. You (as owner of the PoS system) have no idea what card was used, neither has the pw0n3r of the PoS system. A popular implementation of this technique is the Square reader that can be plugged into the audio jack of a cell phone to turn it into a credit card reader. Since the phone is considered un-trusted, the CC data is encrypted inside the reader and then passed encrypted to Square. 

Why doesn't everybody do that? Two reasons: Some merchants like to "see" the CC track data to identify the customer and use it for purchase tracking. Secondly, this option is a bit more recent and older systems don't support it.

Where does "Chip-and-Pin" fit in? Chip and Pin does not encrypt any data. It just authenticates the terminal. In this case, if the card is stolen, an attacker can not produce a fake card that could be used at a chip and pin terminal, and skimmers will have a harder time reading the information. But a card number stolen from a compromised Chip-and-Pin PoS system can still be used online or to create a non Chip-and-Pin card.

I hope this clears up some of the questions regarding recent breaches.

Johannes B. Ullrich, Ph.D.

Keywords: credit cards pci
4 comment(s)


As you noted, Chip-n-PIN does nothing to protect a card from being duplicated and used in a non-Chip-n-PIN terminal, like pretty much all ATMs or from being used online (also known as card-not-present transactions). And all Chip-n-PIN cards still have a mag stripe for use in things like ATMs.

So why are banks in the US promoting it? Easy, to enhance their profits. Once the deadline goes into effect, the liability for any fraudulent card-present transactions that are NOT Chip-n-PIN falls back on the merchant, not the bank.

Today all card-present transactions are presumed to have been validated by the merchant so the liability for a fraudulent card-present transaction falls on the bank, not the merchant. And the cost of the new terminals and their implementation falls on the merchant, not the bank.

Despite Target trumpeting how they are spending $100 million to implement Chip-n-PIN to protect their customers, they are facing the same deadline for the conversion as everyone else. I have no doubt that hundred million was already a budgeted project to protect themselves from card-present chargebacks for fraud. At best they're doing it a little faster than originally planned.
I always wondered why so many merchants require a separate "loyalty card" for discounts; I assumed they had the credit card information needed to link a regular customer to a particular transaction.
I'd guess it's more because a "loyalty card" is locked to an individual or family and also grants opt-in permission. With card numbers changing all the time any more, it's rarely a long-term identifier. When the card is replaced the merchant loses the link to the customer.

Performing data analytics and using a full card number as the unique key needlessly brings the analytics system into PCI scope.
A few things to keep in mind:

An EMV card cannot be duplicated, at least by criminal elements. While it is still possible to create a magstripe-only copy of the card from the information gleaned, no transaction should be possible from such card, as the CVV (not CVV2, CVV) information cannot be obtained in the EMV processing, it is no longer present and, even more important, the issuer makes the final call whether to accept a swipe transaction from a card that was issued with an EMV chip. If an issuer accepts a swipe transaction, they should normally ask the merchant to speak to the cardholder

So the statement is in fact misleading, it is not "that easy" to fake a transaction based on an EMV-issued card

Also, something to ponder about:

PCI DSS is the result of a risk assessment performed by payment brands, and once a merchant agrees to accept card payment, it becomes a risk for the payment brands. Fulfilling PCI compliance is required for the merchant in order to protect the card data, which belongs to the issuers. With this perspective in mind, I see no point in ranting about liability shifts...

Diary Archives