The word “tokenization” is being used far too broadly to describe a variety of payment security methods that perform different security functions.
There’s been no standard mandating how tokenization is deployed or even what defines a token itself.
“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 even saw one article recently that 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.
This sort of confusion is dangerous because it means merchants 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 definition, encrypted data is potentially decryptable.
So, rather than encrypting data, tokenization was designed as 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. Tokenization works differently than encryption because each individual token is created when a transaction takes place, making it organically random with no mathematical pattern to be unlocked.
Tokens were designed to never maintain a one-to-one relationship with a card (although we 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 unencrypted. Also, because tokenization is alphanumeric, there are enough possible permutations that they will never be repeated within even the largest payment ecosystems (collisions, in industry parlance).
For a token to be truly secure, it should only be linked to a single card number only for a single transaction – not linked to the card as a constant. 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 truly tokenization at all. 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 was created to protect merchants from becoming victims of a data breach. Business needs require some merchants to store transactional information after the initial transaction is processed to allow for returns, refunds, etc. For example, hotels would typically store card numbers from the time an initial reservation was made until after the final checkout. This meant keeping hundreds – if not thousands – of card numbers on file. However, by creating tokenization, Shift4 proved that sensitive, vulnerable card data doesn’t actually need to be stored, even in card-on-file environments.
The introduction of tokenization meant merchants were able to continue their business practices and simplify the customer experience without the looming fear of a data breach. They could rest assured that all of their sensitive card data – not to mention their brand – was safe from malicious cybercriminals.
Employing a model of the consumer-based token that any retailer can accept gives their token universal value – and therefore universal risk. If one of these consumer-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.
My point isn’t to tear down consumer-based tokens like those PayPal, Samsung and Apple have been successfully assigning for years. 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 an encryption or cryptographic hash than they are to the arcade token of old.
The good news is that this isn’t an either/or scenario; these technologies can work together to accomplish greater security. Tokenization can and does tokenize – according to the original definition – 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. As we recently saw with the Apple vs. FBI media storm, encryption is always vulnerable, which is why organically random tokenization values will always be more secure.
Customers experience a “wow factor” when merchants accept mobile wallet and other card-based “tokenization” solutions. This is good for business; however, merchants have to make sure that they aren’t putting their business at risk of a data breach in the process. In merchants’ minds, tokenization equals security for them, but in this case, not all “tokenization” is created equal. Merchants should ensure that the tokenization solution they rely on for security is one that was designed to secure the merchant and not just their consumers. Be smart and stay secure.
J.D. Oder II is
