What Would PCI Say About Filming Payment Cards? We Shouldn't Use That Type Of Language

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

Words matter. When one uses terms like "two-factor authentication," "sensitive authentication data" or "high vulnerability" in the context of PCI DSS, the words convey a very specific meaning. Each term conveys specific information, and misuse leads to confusion and errors. A recent payment vendor move—using Webcam footage of payment cards supposedly to deliver some card-present-like advantages—misused some important payment-card terminology. The product also raises new security problems. Confusion is bad, but increased risk is far worse.

If increased risk is not enough, using video to capture payment-card information means that retailers would have to absorb all the cost of complying with every PCI requirement without the benefit of lower interchange fees. One also has to wonder if using video cameras to validate cards means retailers will need to search for rogue video devices the same way they must test for the presence of rogue wireless access points today. Speaking of videos, another bad-guy trick could be harvesting legitimate cardholders' videos and selling them like stolen primary account numbers (PANs). This technology could result in an entirely new secondary carders market.

In the world of payment cards, the incorrect use of industry-specific terms risks misleading anyone who is not a payment-card expert, whether intentionally or accidentally.

This point is important as retailers and vendors struggle to apply all manner of 21st Century technological wizardry to circumvent the restrictions of a mid-20th Century technology: the magnetic stripe card. Each technology struggles to meet the needs of a Web-based consumer-payment market. One outcome of this struggle will be new technologies and approaches that in turn introduce their own particular layer of risk to the transaction. Another outcome is one retailers address every day: PCI DSS.

Frank Hayes' recent column on emerging technologies to support E-Commerce (together with the thoughtful reader comments) noted that in the payment-card industry, "card present" has a specific meaning. (Related story: "Does Card Present Make Sense Any More? What Should It Look Like In A Year?") It relates to reducing the risk (and, therefore, the cost) of a card transaction.

Anytime an issuer receives an authorization request based on reading a card's mag stripe, that transaction has lower risk than if the card information is entered manually. This principle holds when the card is physically present at the point of sale but the mag stripe is not read or when the card is not present, for example, mail order/telephone order (MOTO) or E-Commerce transactions.

The term "card present" means a lot more than the payment card is physically present at the POS. Card present means a lower risk transaction. It means the merchant swiped the card on its POS terminal, which read the mag stripe and sent the contents to the card issuer as part of the authorization.

Reading the mag stripe matters for two reasons. At the POS, the merchant can compare the name on its card-reader screen with that embossed on the card. If they don't match, the retailer can confiscate the card, reject the transaction or call in a Code 10 authorization. Then when the authorization request gets to the issuer, it can use additional, critical data elements contained only on the mag stripe.

For example, the mag stripe contains the card verification value or code (CVV for Visa; CVC for MasterCard). When the issuer receives a card-present authorization, the CVV/CVC can tell it if the card is the one issued. A mag stripe encoded only with information from a cardholder statement, for example, would not contain the correct CVV/CVC. Obviously, the CVV/CVC can only be analyzed when the mag stripe is read and sent to the issuer.

As an aside, many merchants and even some QSAs who may not know the card business well mistakenly confuse the CVV or CVC with the security codes written on the signature panel (the CVV2 or CVC2, respectively). The addition of the "2" is another industry-specific designation that is important. The CVV2/CVC2 is not on the mag stripe, and it has a different but related purpose in reducing fraud—specifically when the card is not present.Relying on a video image of the front of the card is a long way from "card present," and it may actually introduce additional risks and merchant costs. For example, the transmission of the image itself would be in scope for PCI, and I would consider it electronic cardholder data. Storing it means the merchant now has all the cost of complying with every PCI requirement without the benefit of lower interchange fees. If a service provider stores the data, then it, too, has to be PCI compliant (which the merchant will pay for, one way or the other).

I question how (not if) the bad guys will defeat the system by, say, inserting other video images. For example, how long will it be before a bad guy takes a surreptitious video of a card at a retail location and transmits that instead? (This possibility has me thinking about my colleague Randy Will's comment about buying some duct tape to cover the video camera built into my laptop.)The security codes mentioned previously are only the latest fixes that the industry has had to make to adapt a 60-plus year-old technology that wasn't even invented for banks. For example, the card brands added holograms to the front of cards to deflect counterfeit plastic. Then, issuers printed the first four digits of the PAN on the card to help merchants detect a (criminally) re-embossed card. Address verification was developed to reduce risk in MOTO transactions, and it was successful as long as the bad guys didn't steal the cardholder's billing statement. This brings us back to the CVV2/CVC2. Issuers rely on these codes, and they are neither encoded on the mag stripe nor embossed; rather, they are simply printed on the card.

In case you haven't figured it out yet, protecting those security codes is the intent behind PCI Requirement 3.2, which forbids storing them either electronically or on paper. I would point out that this particular requirement is not the only artifact of our present payment-card technology, and here I include Chip-and-PIN cards, too. There are about 280 other artifacts: the rest of the PCI DSS (and maybe PA-DSS and PCI PTS, too).

Unfortunately, the two most talked-about and promising technologies—tokenization and point-to-point encryption—will at best reduce a retailer's PCI scope. In every situation I can imagine some part of the card-present process is still in scope, and there may be less benefit for MOTO and E-Commerce environments. That means retailers will continue to deal with PCI compliance.

One hope I have is that retailers and vendors considering (hawking?) emerging technologies of all types will understand they operate in the context of a 60-plus year-old technology. Only the card issuers can change that situation. The technology has served all parties well, and it has proven remarkably adaptable—although it is near the breaking point. If you don't believe that, consider PCI DSS.

My other hope is that newcomers will understand the power—for good or ill—of their words, especially words used in this particular context of payment cards. There can be no excuse for sloppiness ("dual-factor" authentication using two user IDs and passwords is not two-factor authentication), carelessness (when a vendor encrypts "sensitive card data" does it mean cardholder data or sensitive authentication data that cannot be retained?), incompleteness (in PCI, vulnerabilities with a CVSS score of 4.0 or greater must be remedied for PCI compliance regardless of whether the particular scanner labels it "high" or "medium") or, in the worst case, even lying.

What do you think? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].