By J.D. Oder II, CTO and SVP – R&D, Shift4

J.D. Oder
J.D. Oder

“Tokenization” is now a household name in the payments industry, and has become a widely-accepted method of protecting card data. However, while it has become the industry standard, it remains anything but standardized.

Tokenization 101

Introduced by Shift4 in 2005, tokenization quickly caught on because it addressed the persistent, rising threat inherent in securing post-authorization card data for the long-term. Tokenization works in the same basic way that an arcade token does. In an arcade, a quarter, which has universal value, is exchanged for a token that works only within that arcade. With tokenization, a credit or debit card number (globally valuable) is exchanged for a token that also has value only within specific parameters and locations.

Though the term has become ingrained in our collective lexicon, there is currently no universal standard to mandate how tokenization is deployed or even what defines a token itself. EMVCo (the body that manages and maintains EMV specifications) and the Payment Card Industry Security Standards Council (PCI SSC) have both attempted to standardize tokenization over the past few years, but neither has succeeded. These two organizations, which purportedly share the ultimate goal of greater payment security, can’t even agree on what tokens should look like and how they should function.

To make things worse, the term is being used far too broadly to describe a variety of payment security methods that perform different security functions. “EMVCo tokenization” has become a particularly hot topic in the payments industry. It can refer to both mobile payment tokenization (à la Apple Pay) and card-based tokenization. I recently saw one article that even extolled the virtues of point-to-point encryption as a tokenization solution. It’s enough to make almost anyone’s head spin — especially those of us who know what tokenization really is and the specific problem that it solves.

More Than Semantics

This isn’t merely a question of semantics; it can spell real danger for merchants, who

are at risk of being led astray from the very tokenization solutions they need to secure their business. Point-to-point encryption as a token? Absolutely not. Tokenization was specifically designed not to be encrypted data, because by its own definition, encrypted data is potentially decryptable.

Tokenization works differently than encryption because it is organically random with no mathematical pattern to be unlocked. Unlike encryption, tokenization is a random, globally unique, alphanumeric value that replaces payment card data after bank authorization so the data stored in merchant systems has absolutely zero value outside of their environment. Tokens were designed to never maintain a one-to-one relationship with a card (although Shift4 later built additional secure technologies that allowed for tokenized merchants to still track card usage for analytics). This ensures that tokens aren’t predictable and cannot be reversed or decrypted. Also, because tokenization is alphanumeric, there are enough possible permutations that they will never be repeated within even the largest payment ecosystems (there is no risk of collisions, to put it in industry parlance).

The security of tokenization lies within the fact that it refers to a single transaction and is not permanently linked to the card. This varies from what you may have heard about tokenization in recent discussions that reference security features driven by mobile wallets and credit or debit cards, such as EMVCo tokenization. Although they are referred to as tokenization, these services aren’t actually tokenization at all — by its true definition, at least.

Instead, they are consumer-based token services that seek to protect the cardholder, not the merchant. This is a noble undertaking, but slightly misguided, since having a token that references the same card number has, in essence, done nothing more than create a new card number that is just as vulnerable to attack as the original data; this is not what tokenization was designed to do.

Tokenization In Name Only
Depending on their business needs, some merchants still need to store transactional information after the initial payment is processed to allow for returns, incremental authorizations, recurring billing, etc. For example, hotels typically store customer data from the time an initial reservation was made until after the final checkout. Prior to tokenization, this meant keeping hundreds — if not thousands — of card numbers on file, which led to a glut of data breaches.

The looming fear of a data breach was lessened with the introduction of tokenization, as we proved that sensitive, vulnerable card data doesn’t actually need to be stored, even in these card-on-file environments. Merchants are able to continue their business practices and simplify the customer experience with greater confidence. They can rest assured that all of their sensitive card data — not to mention their brand — is safe from malicious cybercriminals. Even if a comprehensive list were released tomorrow that included the billions of tokenized transactions since 2005, hackers would be no closer to breaching a merchant’s systems. That’s because of the nature of tokenization. Conversely, if one of these consumer-based-tokenization providers released their full list of tokens tomorrow, you can bet there would be an instant increase of fraud among merchants that accept them. After all, their “tokens” are universally accepted — and therefore universally dangerous.

Complementary Solutions for Data Security

It’s not that consumer-based tokens have no place in the world. Companies like PayPal, Samsung and Apple have been successfully assigning these tokens in the wild for years now. They do offer a certain level of protection to cardholders at the point of purchase and have — knock on wood — been relatively effective in preventing mass-scale breaches. My contention with these technologies is simply that they should not be called tokenization. They are much closer to encryption or a cryptographic hash than they are to the arcade token of old.

Fortunately, merchants don’t have to pick one or the other. In fact, these technologies can work together to accomplish greater security. Tokenization — according to the original definition — can and does tokenize the consumer tokens that are received from a mobile wallet or other payment instrument. This prevents the merchant from having to maintain a database full of sensitive cardholder data, even if that data in this case is an encrypted surrogate of the original. As we saw with the Apple vs. FBI media storm, encryption is always vulnerable, which is why organically random tokenization values will always be more secure.

Merchants want to make it as easy and convenient as possible for customers to say “yes” and make that purchase, so they are eager to accept mobile wallets and other card-based token solutions. But remember, not all of these solutions offer true tokenization, which provides the highest level of security and protects both merchants and their customers.

About the Author

J.D. Oder II serves as Shift4’s CTO and SVP – R&D. J.D. is a Certified Network Engineer with more than 15 years of experience. He leads Shift4’s systems operations and development efforts as well as the security and compliance teams. J.D. is the architect of the DOLLARS ON THE NET® payment gateway solution. He is credited with introducing tokenization to the industry in 2005 and was also an early adopter/member of the PCI Security Standards Council. 

Comments are closed