Comments on Visa’s Tokenization Best Practices

By Adrian Lane

If you are interested in tokenization, check out Visa’s Tokenization Best Practices guide, released this week. The document is a very short four pages. It highlights the basics and is helpful in understanding minimum standards for deployment. That said, I think some simple changes would make the recommendations much better and deployments more secure.

From a security standpoint my issues are twofold: I think they fell far short with their recommendations on token generation, and that salting should be implemented differently than they suggest. I also believe that, given how prescriptive the advice is in several sections, Visa should clarify what they mean by encrypting the “Card Data Vault”, but that’s a subject for another day. First things first: let’s dig into the token generation issues.

The principle behind tokenization is to substitute a token for a real (sensitive) value, so you cannot reverse engineer the token into PAN data. But when choosing a token creation strategy, you must decide whether you want to be able to retrieve the value or not. If you will want to convert the token back to the original value, use encryption. But if you don’t need to this, there are better ways to secure PAN data than encryption or hashing!

My problem with the Visa recommendations is their first suggestion should have been simply to use a random number. If the output is not generated by a mathematical function applied to the input, it cannot be reversed to regenerate the original PAN data. The only way to discover PAN data from a real token is a (reverse) lookup in the token server database. Random tokens are simple to generate, and the size & data type constraints are trivial. This should be the default, as most firms should neither need or want PAN data retrievable from the token.

As for encryption, rather than suggest a “strong encryption cipher”, why not take this a step further and recommend a one time pad? This is a perfect application for that kind of substitution cipher. And one time pads are as secure a method as anything else. I’m guessing Visa did not suggest this because a handful of very large payment processors, with distributed operations, actually want to retrieve the PAN data in multiple locations. That means they need encryption, and they need to distribute the keys.

As for hashing, I think the method they prescribe is wrong. Remember that a hash is deterministic. You put in A, the hash digests the PAN data, and it produces B. Every time. Without fail. In order to avoid dictionary attacks you salt the input with a number. But the recommendations are ” … hashing of the cardholder data using a fixed but unique salt value per merchant”! If you use a static merchant ID as the salt, you are really not adding much in the way of computational complexity (or trying very hard to stop attacks). Odds are the value will be guessed or gathered at some point, as will the hashing algorithm – which subjects you to precomputed attacks against all the tokens. It seems to me that for PAN data, you can pick any salt you want, so why not make it different for each and every token? The token server can store the random salt with the token, and attacks become much tougher.

Finally, Visa did not even discuss format preservation. I am unaware of any tokenization deployment that does not retain the format of the original credit card number/PAN. In many cases they preserve data types as well. Punting on this subject is not really appropriate, as format preservation is what allows token systems to slide into existing operations without entirely reworking the applications and databases. Visa should have stepped up to the plate with format preserving encryption and fully endorsed format-preserving strong cryptography. This was absent fromnot addressed in the Field Level Encryption Best Practices in 2009, and remains conspicuous by its absence.

The odds are that if you are saddled with PCI-DSS responsibilities, you will not write your own ‘home-grown’ token servers. So keep in mind that these recommendations are open enough that vendors can easily provide botched implementations and still meet Visa’s guidelines. If you are only interested in getting systems out of scope, then any of these solutions is fine because QSAs will accept them as meeting the guidelines. But if you are going to the trouble of implementing a token server, it’s no more work to select one that offers strong security.

No Related Posts

Can anyone direct me to a source which isn’t as technical as this? People on here seem to know their stuff - I’m just scratching the surface, as it were. I’d really appreciate it if someone could point me in the direction of a reputable source of info (ie, not Wikpedia!)

Thanks in advance


By Simon

@Mark - I guess ‘absent’ is the wrong word, as you point out section 11 mentions the need for peer review. But seriously, this is what I call ‘punting’ on the subject. This is not an endorsement. Visa is not standing behind FPE or FFSEM. If you are a customer, how do you know if a vendor is selling a secure product or snake-oil. 99% of customers, heck, 99% of the QSAs will not have the capability to seriously analyze format preserving encryption for effectiveness. How many people on the planet are qualified to perform cryptanalysis format preserving encryption?

Your firm was obviously pro-active in this regard and got a _legitimate_ expert to endorse your methodology. Why does Visa or PCI not step up and endorse? Waiting indefinitely for NIST or pushing this off for ‘independent security evaluation’ just clouds the issue. And to finish my rant, why not mention it under tokenization, where it’s a _must_ have feature?

Thanks for the clarification!


By Adrian Lane

The VISA document on Data Field Encryption does treat Format Preserving Encryption. I suggest you read best practice item 11 on “any method used to produce encrypted text of the same length and data type as the original cleartext”.

By Mark Bower

So true. I actually tried to email NIST 12/7/2009 to ask about approval status of AES FFX Mode, but the email address they say to send questions to was bad. #< #5.7.0 smtp; 550 5.7.0 <>... User unknown> #SMTP#

By Lucas Zaichkowsky

@Lucas - thanks for the comment and no disagreements. I do have two comments in response: I think that FPE variants are secure, but they get used because the payment processor or merchants really want to have their cake and eat it too, meaning try to get systems out of scope while still having the PAN data. Second, is there any indication that NIST will _ever_ respond to evaluation requests on the effectiveness of FPE variants?


By Adrian Lane

The recommendation to use a unique salt value per merchant makes sense. It greatly reduces rainbow table effectiveness since one would have to be created for each compromised merchant. At the same time, storage space requirements of the merchant are minimized. For that single merchant, each request to produce a “multi-use token” will produce the same hash value. That token will be used for features such as recurring billing, easier return process, and customer card on file.

The recommendation to use a “known strong cryptographic algorithm” is in line with the PCI standards. It makes the intent of the requirement/recommendation known while at the same time providing flexibility. Strong Cryptography is defined in the PCI Glossary of Terms as, “Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or

By Lucas Zaichkowsky

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.