Payment Card Security

The recent breach of payment card data from US Target stores piqued my curiosity about exactly how credit and debit card security works. Many of us use these cards nearly every day if not several times per day to pay for goods and services both in person and online. Yet how many people understand the security of these instruments that permit access to our financial resources?

There are two basic types of payment cards, credit and debit. Both of them serve as your identification and means of authentication for authorizing a transaction between you and a merchant. The cards all conform to the ISO/IEC 7813 standard. For identification, they have your name and account number both printed and encoded on the magnetic stripe. There are several mechanisms that provide authentication. Which one(s) gets used depends on which type of card it is and how you are using it. You can use the cards in person at a point-of-sale (POS) terminal or you can make an online/telephone/mail-order (i.e. "card not present") transaction.

If you are physically at the merchant's checkout register, the card is "what you have". If it is a debit card, then the PIN is "what you know" and you have two-factor authentication. If it is a credit card, the merchant should verify your identity against a government-issued photo ID (e.g. driver's license) and also compare the signature on your credit card to the one on your receipt or the digital signing pad. I think of this as a crude quasi-biometric that weakly qualifies as "what you are". (That's probably another post to rip that idea apart.) So in practice, credit cards are effectively one-factor authentication.

Interestingly, most credit cards have a PIN number too, but that's only used for ATM cash advances. I think most people use a debit card at the ATM, so it's kind of useless. You'd think they would have required that at POS terminals for two-factor authentication, yes? Credit cards have been around far longer than debit cards. I suspect the PIN came later and now it's too expensive to mandate an update to the entire infrastructure (e.g. IPv6 upgrade). Also, federal law limits your fraud liability to $50 and the big companies (Visa, etc) waive that to $0. I'm guessing with their massive resources, it's cheaper to take the chance and maintain good relations with the customers, i.e. a calculated risk.

If you are making a "card not present" purchase, then a merchant should require you to provide the CVV2 code (the 3 or 4 digit code on the back of the card). This code can be used in the transaction with the payment processor to verify that the card number given is legitimate. This replaces the use of the CVV1 code which is only encoded on the magnetic stripe which is not used in this case. Since all the data provided is on the card, this is one-factor authentication. Some merchants still do not require the CVV2 code. I guess they're just passing the buck to financial institution if the transaction turns out to be fraudulent.

No matter which type of card and transaction you're doing, the steps are fundamentally the same. You provide the card (or its data) to the merchant. They communicate this data along with the proposed amount of the transaction to their payment processor for authorization. Most of the card-issuing institutions do not deal with this directly, but farm it out to third parties who have the ability to authorize the transaction to occur between the merchant and your account. There are many institutions, processors and merchants that all have to work together seamlessly in order to provide you with a consistent purchasing mechanism. In regards to security, the Payment Card Industry (PCI) Security Standards Council formed in 2006 to provide security requirements and best practices for all these participants. They offer the Data Security Standard (version 3.0 as of Nov 2013) that provides a framework of security requirements, testing procedures and implementation guidance for all aspects of payment card processing.

We don't have any technical details from the Target breach (and we probably won't), but we can learn a few things from their public relations handling. They have a web page dedicated to the issue including an FAQ. According to the FAQ, they found some type of malware on their point-of-sale systems. I take that to mean the actual swipe terminals or the interface between them and the payment processor. There was some initial confusion about "CVV information" being acquired. This is a terminology nightmare. Read something like this Wikipedia entry and then tell me what they're talking about. I believe what was acquired was the CVV1 code which is on the magnetic stripe. The CVV2 code is not on the stripe, only physically printed on the back of the card. There is no way to capture that electronically (unless you want to talk about cameras planted under the POS terminal). The CVV1 code cannot be used for fraudulent online purchases, but it can be used to reconstruct a clone of your card for fraudulent in-person purchases.

There was also concern over captured PIN data from debit cards. Target later confirmed that the encrypted PIN data was also acquired. Your PIN gets encrypted right in the keypad terminal and has to be transmitted to the payment processor. Also PCI DSS requirement 3.2.3 says that PIN data (encrypted or not) should never be stored. In fact, there is an entire separate document all about PIN Security Requirements. However, it has to reside in some memory buffer long enough to get transmitted from the POS terminal to the processor. That's probably where it got captured. The data is encrypted with Triple-DES which was the precursor recommendation for "strong encryption" before AES was published. The Target FAQ says that the decryption key is only possessed by the payment processor and has never been on any Target system ever. This implies PKI and Target only has the payment processor's public key. So this is as well protected as anything encrypted with Triple-DES. Unless the NSA was behind this, I doubt the thieves can do much with that. Nor do they need to because you can opt to use a debit card but pay as a credit transaction which does not require PIN entry.

And now we're back to my earlier question about why credit cards do not require PIN use. How many more large-scale incidents like this will it take before we bite the bullet and introduce credit card PINs? Perhaps we use the European-style "chip and PIN" smart-cards? This enhances security because the PIN is only used as an input to the chip on the card to unlock access to your encryption keys that then protect the interaction between card and terminal. That's a lot smaller window of opportunity for PIN capture.

Definitely a story to keep following as it develops due to its large scale and high visibility. This is another great example of the tradeoff between security and usability. Do we keep things simple like they are and avoid a potentially high-cost upgrade of the infrastructure? That will result in more breaches, more bad public relations, etc. Or do we pay a relatively one-time cost and go for a more secure solution? Also consider that some due care should be expected on the part of the customer. We should learn to keep an eye on our accounts. Most institutions will offer to send you emails or text message alerts if anything suspicious happens. Since this is all about money, the answer comes down to money as well. Whichever path is deemed to have the lesser overall cost will win.

This post maps to CompTIA SY0-301 exam objectives 2.1, 2.5 and 5.2.