Evan Schuman's StorefrontBacktalk

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 wconway@403labs.com.