Credit Card Processing in 700 Words or Less
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.
Comments