Quantcast StorefrontBacktalk » Blog Archive » Visa’s Retail Token Advice Of Token Value
advertisement
advertisement

Visa’s Retail Token Advice Of Token Value

Written by Evan Schuman
October 8th, 2009
Like this story? Share it
To share this story with people in your social network, please click on the network icons below.

Visa on Monday (Oct. 5) issued a document to ostensibly help retailers figure out how best to navigate the new encryption and tokenization landscape. But as a practical matter, the document did little beyond rehash conventional wisdom and long-standing Visa and PCI best practices. It felt more like a quintessential psychologist’s advice session: “Dr. Visa, what should we do about tokenization?” “That’s an excellent question, Mr. CIO. What do you think you should do?”

The document danced around the key issues about which retailers would truly love strong guidance from Visa, ranging from whether tokens could ever conceivably be considered out of PCI scope to whether retailers are actually encouraged to retain such tokens on their own servers.

The only explicit advice that Visa’s document gave spoke to issues that have, for all practical purposes, already been decided. For example, the document touched on the encryption technique that many vendors are inaccurately calling end-to-end encryption. Visa has chosen to call that approach—where the card data is encrypted or turned into a token a split second after the card is swiped—Data Field Encryption. (It’s not the catchiest term, but let’s give points to Visa for refusing to use the inaccurate end-to-end name. At least Data Field Encryption is descriptive and accurate.)

It took the position that Data Field Encryption is viable and worthy of evaluation. That would have been helpful a year or two ago, but it’s such a foregone conclusion today as to be of little strategic help.

“While no single technology will completely solve for fraud, Data Field Encryption can be an effective security layer to render cardholder data useless to criminals in the event of a merchant data breach,” said Eduardo Perez, global head of data security at Visa Inc. “Using encryption as one component of a comprehensive data security program can enhance a merchant’s security by eliminating any clear text data either in storage or in flight.” A true statement, but it’s hardly one that will prove especially enlightening for retail chain IT execs. Their questions are mostly “which approach” and “how should it be deployed.” Alas, advice there was not offered.

One of Visa’s leaders on the encryption and tokenization debate is Jennifer Fischer, a Visa senior business leader. Fischer said scope issues eventually would be worked out. But she cautioned against retailers putting too much faith into, well, anything. “We don’t want encryption to be viewed as a silver bullet. Both encryption and tokenization may enable a merchant to reduce their scope.” A journalism professor once drilled into my head to never use a phrase containing the verb “may” if it could just as accurately be changed to “may not.”

(Related story: PCI Columnist David Taylor offers his own take on the Visa report. Is it a tacit endorsement?)

In another nod to the psychologist analogy, the Visa document tried to sound sympathetic to the plight of retailers while avoiding offering any concrete guidance. “The implementation of any Data Field Encryption must be done in a strong and secure way to prevent the compromise of card data.” (As Harvard Law Professor Arthur Miller once quipped when presented with a similar truism: “Do you actually get paid for giving answers like that?”) The sympathy came in the next line: “With industry standards still in the development phase, that goal can be particularly challenging.”

One of the key issues behind tokenization is the optimistic claim that tokens—properly maintained—might be considered out of PCI scope. Although the Visa document didn’t explicitly say whether tokens could ever be out of scope, it hinted that this possibility is unlikely. “No single technology can completely solve for fraud. Accordingly, Visa views Data Field Encryption as a complement to, rather than a substitute for, PCI DSS compliance requirements.”

It’s hard to see how tokens—as currently envisioned—could ever be considered out of scope given the fact that they start out as card numbers and can—at whim—be converted back into card numbers. Most tokens can’t be unencrypted or reverse-engineered per se, but lists are maintained to permit the token to be re-associated with the original card data. So if it starts out as having all of the data and can again have all of the data at the whim of the retailer, it seems difficult to envision how tokens could be beyond Visa’s or PCI’s jurisdiction.

George Peabody, the director of the emerging technology advisory service at Mercator Advisory Group, pointed out another concern associated with tokenization. Although much of the debate today is focused on whether tokens should be maintained by the retailers directly or sent away where a third-party vendor can handle the protection, the token approach can handle a lot more data than simply payment codes. For convenience, such tokens could also store and protect “all of the metadata surrounding the payment,” including SKUs, time of purchase, shopping history, what coupons or discounts were used and many other CRM details, Peabody said.

“Enterprise security people need to be thinking about what’s adequate when they’re judging tokenization vendors. They better be looking at what is convenient and what isn’t,” Peabody said. Presumably, a retailer that is using a vendor to store and protect the tokens outside of the retailer’s network would want to keep nothing in the token beyond the critical payment details, making sure that SKU and other information is not there. But if the chain is handling such tokens internally, it could be very efficient to use the token techniques to consolidate lots of helpful details.

But here’s the danger with such a scenario. If a retailer chooses initially to store the tokens itself and then, perhaps a year or two down the road, opts to outsource, will the team remember to go back and strip away all of the non-payment data? Will anyone bother? It’s a huge risk, because the tokenization vendors are also likely working for some of that chain’s largest rivals and those retailers also have the ability to access that data. Is that not a huge temptation? How much would an unscrupulous Rite Aid manager pay for access to that kind of CRM data about Walgreen’s customers? It only takes one debt-ridden employee of that token vendor to enable such a nightmare scenario.


advertisement

2 Comments | Read Visa’s Retail Token Advice Of Token Value

  1. Steven Kendus Says:

    The best practices for data field encryption announced by Visa work toward developing a standard approach while offering guidance to payment solution providers. As Schuman points out, the document rehashed conventional wisdom and long-standing Visa and PCI best practices. However, there is definite value in the fact that Visa is actually weighing in and looking to provide some guidance. The five key implementation objectives outlined in the document provide some validation to tokenization approaches that are currently in production. Likewise, their stance that no single technology can completely solve for fraud has merit. Existing solutions that use both end-to-end encryption to encrypt card data from the point of sale, and tokenization on the back end of the transaction support their stance.

  2. Michael Cherry Says:

    Does VISA realize that lawsuits are coming and psychologists don’t get sued? I believe both of the following almost contradictory statements:
    1. Customer submitted credit cards are radioactive and they need to be immediately encrypted as they are swiped.
    2. Data centers that store data-at-rest can be designed to automatically identify and block breach attempts. Database encryption and the associated key management headaches are unnecessary.

    Michael Cherry, Cherry Biometrics Inc.
    Vice Chair, Digital Technology Committee
    National Association of Criminal Defense Lawyers

Leave a Reply

Newsletter

Quickly catch-up on the latest in E-Commerce and Retail Tech with our free weekly newsletter, with urgent bulletins as news merits.
advertisement

Most Recent Comments

Kill All The Passwords

This article does mention, but does not give enough attention to, the fact that the attacks discussed are only feasible when the encrypted password file can be copied and subjected to an offline attack. The trick is to have authentication performed on a separate, much more strongly secured host - such as an Active Directory Domain Controller, or a Kerberos server, or a NIS+ server, or even using something as banal as an LDAP-over-SSL authentication dialog. In these environments, the odds of the "password file" being stolen and subjected to an offline attack go to near zero, and only online attacks may be carried out by the attacker. With sensible exponential backoff between failed password attempts, lockout after a modest number of failed attempts on a single account, and pattern detection, that minimum 7 character password is quite secure enough. Passwords aren't dead yet for security purposes, and they will be with us for a very long while to come for practical purposes. The trick is to employ them correctly. Read more...
The possibilities you describe are years away from being implemented at best, so for the moment passwords are an ugly reality. Luckily, password managers can easily manage hundreds of passwords of any length. The only thing a user needs to remember is the master password. It seems like an easier task to educate users on how to use password managers rather than implement complex security technology on a global basis. Read more...