March 1, 2016

Executive Insight: Setting the Record Straight on Tokenization

Executive Insight: Setting the Record Straight on Tokenization

I watched an interesting and entertaining Twitter dialogue unfold late last month between two payments industry experts. Ian Kar, who covers the payments industry for online news publication Quartz, was covering PayPal’s earnings call when he heard PayPal CEO Dan Schulman make a pretty bold claim:

Tokenization 101
Shift4 introduced the term tokenization to the payments industry at the Transaction Security Summit in Las Vegas in 2005. When our executive team conceived of the technology the year before, we related it to an arcade token. Tokenization exchanges a credit or debit card number, which like a quarter has universal value, for a token that has value only within specific parameters and a specific location, much like an arcade token used to play games in a specific arcade. At that time, my altruistic and admittedly naïve younger self pushed for Shift4 to release tokenization to the industry without a patent. I saw the value it held in addressing the greatest risk to payment data in those days – securing post-authorization card data for long-term storage – and I knew how much the industry needed an answer to that persistent, rising threat. Adoption was rapid and far-reaching – to the point that tokenization can now be considered an industry standard.

Unfortunately, despite becoming an industry standard, tokenization had no standard to mandate how it was deployed or even how it was formed. EMVCo and PCI have both attempted to standardize tokenization over the past few years but neither has succeeded, in part because even they can’t agree what tokens should look like and how they should function.

Blurring Use of the Term “Tokenization”
Just take a look at recent payments news in almost any publication, and you will see an ongoing conversation about what is being called “EMVCo tokenization,” 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 confusion within the payments industry about tokenization is dangerous because it means that merchants are at risk of being led astray from the very tokenization solutions they need to secure their business. The problem is that the word “tokenization” is being used far too broadly to describe a variety of payment security methods that perform different security functions. Point-to-point encryption as a token? Absolutely not. In fact, tokenization was specifically designed not to be encrypted data, because encrypted data – by definition – is decryptable.

Tokenization Defined
Tokenization was designed as a random, globally unique, transactional, alphanumeric value that replaces payment card data. 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. This ensures that tokens aren’t predictable and cannot be reversed. 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). Tokenization is not encryption, so it can never be unencrypted. Also, because tokenization is alphanumeric there are enough possible permutations that we will never see a repeated token (collisions in industry parlance) within even the largest payment ecosystem.

Tokenization should reference a specific card number only for a single transaction – and not remain linked to the card as a constant. This varies from what you may have heard about recently in discussions about tokenization in reference to those security features driven by mobile wallets and credit or debit cards, such as EMVCo tokenization. Although referred to as tokenization, these services aren’t tokenization at all, but instead are consumer-based token services that seek to protect the cardholder, not the merchant. (The same is true for the PayPal reference tokens that prompted this whole post.) Having a token that always 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’s Purpose
So, what exactly was tokenization designed to do? First and foremost, it was designed to protect merchants from becoming victims of a data breach. Business needs require merchants to store transactional information for a period after the transaction is processed to allow for returns, refunds, etc. In hotels, for example, card numbers often had to be stored from the time an initial reservation was made until after the final checkout when any additional charges (a minibar purchase, for example) might have to be added. For a major e-retailer, the card-on-file database could reach into the millions of cards as consumers selected the “save this card for future use” option – and these cards are essentially stored indefinitely. Tokenization was designed to allow merchants to continue these business practices, simplifying the shopping/checkout experience for their customers without exposing themselves, their brand, and their clients to the dangers of maintaining a huge database of card numbers (a target that became irresistible to cybercriminals in the early 2000s).

By replacing these card numbers with random tokens, Shift4 was able to alleviate this risk. We trademarked the expression They Can’t Steal What You Don’t Have® to explain the benefit to merchants. Tokens could be used only by that specific merchant to process refunds, recurring payments, etc., but outside of their environment (and their specific connection to Shift4’s data centers), held absolutely zero value. 

Since introducing tokenization in 2005, Shift4 has processed more than 6.5 billion tokenized transactions. I could post a list tomorrow that included each one of these tokens and hackers would be no closer to breaching Shift4 nor any of our merchants’ systems because of this list. This is due to the nature of tokenization and the limits we placed upon it when we designed the technology. I wish that the same could be said for these other “tokenization-in-name-only” solutions.

Different, But Complementary
The same consumer-based token (the EMVCo model) can be used across all retailers that accept that payment instrument, giving the 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.

Now, don’t get me wrong. I am in no way bashing on 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 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.

Fortunately, these technologies can work together to accomplish greater security. Shift4’s TrueTokenization® 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 are seeing currently with the Apple vs. FBI media storm, encryption is always vulnerable, which is why the organically random TrueTokenization values will always be more secure.

Merchants that accept mobile wallet and other card-based “tokenization” solutions are delivering modern technology and a “wow-factor” to their clients. This is good for business. However, they must ensure that in so doing they do not put their business at risk of a data breach, which is bad for everyone involved. The risk of calling these new technologies tokenization at all is that Shift4 has been successfully using TrueTokenization for over a decade and we have seen incredible success with it. In merchants’ minds, tokenization equals security for them, and in this case, that isn’t necessarily true.

While we’re not going to launch into a public relations battle with the likes of Apple or PayPal over the use of the term, my warning to merchants is to ensure that the flavor of tokenization you are using protects you and not just your customers.