Tokenization Makes Payment Card Use Safe
Patrick Mutabazi
SmartCards and Technology Solutions Advisory - Innovation & EmergingTechnology| Government Solutions Consultant| Founder & Executive Director| SmartCards Engineer| Data Engineer| QA Auditing Facilitator and Auditor
Data security is paramount to many businesses, none more so than the credit card processing industry. Customers need to know that personal payment information is secure at the time of transaction and merchants need to make sure the data stays secure. Data security breaches are everywhere. Identity theft and stolen card numbers are just a few of the many consequences of poor security. As a merchant, how do you ensure that you are protecting yourself? One solution is using tokenization when processing credit card transactions at your business.
What is tokenization and how does it work?
Tokenization is not a new concept at all – it has origins dating back thousands of years. Historically, when someone has needed to protect a currency or a valuable item during a transaction, they’ve used tokenization by replacing that currency or item with something representative that’s less valuable. A good live example of this today is the use of casino chips in Casino's as a substitute for real money.
When dealing with payment cards in today’s business environment, the looming spectre of a cyber attack is something that could, and should, prey on one’s mind. Losing a database that contains payment card details is the worst case scenario for many businesses as it can ultimately lead to your customers’ card information being exploited by criminals.
Payment Tokenization is a process by which the Primary Account Number (PAN) of a credit or debit card is replaced with a surrogate value called a token. De-tokenization is the reverse process of redeeming a token for its associated PAN value. The security of an individual token relies predominantly on the infeasibility of determining the original PAN knowing only the surrogate value.
In simple terms, Tokenization is the act of switching out sensitive data (i.e. card member information, account numbers, etc.) with a random number equivalent or other piece of data (the token) that cannot be used or exploited anywhere else. It’s like building a randomly generated treasure map or reference number that leads back to the data which is stored securely somewhere else, but only when the right decoder is present (de-tokenization). Take the map key away and you just have a map that can’t be translated into anything useful, or reveal where the treasure (the sensitive data) is.
It is the process by which credit card numbers are replaced with a randomly generated string of alphanumeric characters,called tokens to protect against data theft during a transaction. As only the token not the actual account number passes through the payment system, the only thing that is susceptible to theft is that token. In the system, the token is used to process the payment but outside that system it is meaningless and worthless if stolen.
In other words, Tokenization involves taking in cardholder data and returning a token, a string of letters, numbers and characters that represents and stands in place of the original data. Each token serves as a pointer for cardholder information, which is securely stored offsite in a cloud-based database. Since tokens do not contain cardholder data, they are essentially immune from the threat of hackers and identity thieves.
The process is similar to EMV (Europay, Mastercard, Visa) or embedded chip cards. They both use new payment standards and supporting technologies to prevent fraudsters from either accessing or replicating vulnerable mag-stripe data. Card information that is stored on the chip is encrypted offering two forms of protection. Whereas EMV chip cards were created to address card counterfeiting, tokenization was built/created to remove card data entirely from digital devices and infrastructure. Not only does this reduce the security vulnerabilities, it also allows issuers additional control of payment devices in the digital channel. EMV and tokenization together reduce or eliminate fraud in the Card-Present and Card Not Present channels with minimal to no impact to the cardholder.
Tokenization for security
Tokens on their own are worthless. So even if a hacker steals the information out of a tokenized terminal, they would only get random numbers. There is virtually no chance or pattern to get the real information referenced by the tokens when they’re without the original, intended system. This tokenization system itself is also secure with security best practices.
To give an example of how it works; You swipe your credit card, which has a card number of 2222 4432 5643 6674. This is then run through a random number generator that makes a token of A537 8JR3 04ST 921F, which has no correlation because it is made up randomly. Only the token data is stored in the server at the business and transferred through the payment process. Tokens are usually the same length and format as the original account number, so it appears to be the same as standard payment card number to the storage, processing, and transfer systems using it.
Tokenization Versus Encryption
What are the differences between tokenization and encryption? Encryption is designed to mask the data through an algorithm while it is being transmitted. However, the original data is sometimes stored on the networks, creating a security vulnerability. Each time the card data is passed through a system, it is encrypted, decrypted, and re-encrypted, and the vulnerability to hacking increases. Tokenization, on the other hand, doesn’t store any of the information in the system and the token is completely randomly generated, so there isn’t a specific way to decode it. In other words, tokenization takes away the need for merchants and websites to store sensitive data on their networks that can be stolen by hackers/fraudsters.
What Tokenization Means For Customers and Merchants
Basically, tokenization means more security and minimal differences in experience of use. Customers will still use their card and the transaction will act just like a non-tokenized one on the surface. All of the differences are behind the scenes, so customers will not experience any sort of learning curve or a new way of using their payment cards. For merchants, they can use the tokenized transactions just as they would a non-tokenized one. Refunds, exchanges, and transactions will appear just the same although they are doing their part to protect themselves and their customers.
Security is always going to remain a hot topic as long as breaches continue to occur. Hackers and criminals are never going to go away in the progressively digital age, but back-end processing technology can continue to fight by making it harder for them to walk away with the information they’re looking for. Using tokenization puts the best line of defence in front of payments technology, beating hackers and criminals at their own game.
Why use it?
Recommended by LinkedIn
The benefits of tokenization to banks/merchants include:
Tokenization and PCI compliance
Tokenization reinforces the overall objectives of Payment Card Industry Data Security Standards (PCI DSS), as well as specific requirements. Most importantly, it addresses PCI requirement 3: “Protect stored cardholder data.” By returning only tokens in response to merchant requests, cardholder information need not be stored on the merchant system. Nor do merchants have to worry about ensuring that the method of encryption used is of adequate strength and complexity. Since the merchant is not required to encrypt the token, there are no encryption keys to manage.
PCI requirement 3.4 mandates that all cardholder data be rendered unreadable anywhere it is stored using one of several forms of strong encryption. One of the methods suggested is the use of truncation. Since only the last four digits of the card number are used in the token, the tokenization process meets this requirement in every sense.
Since the merchant is not using encryption to derive the token, the tokenization process renders requirements 3.5 and 3.6 having little or no relevance. Requirement 3.5 states that all encryption keys should be protected against disclosure and misuse. The token is sent to the merchant, rather than derived by the merchant using encryption keys. Tokenization reduces the need for comprehensive key management and also reduces the potential points of attack in a system.
Tokenization: The Next Wave in Digital Fraud Prevention
In the digital payments realm, tokenization replaces all the coveted card account data that’s being hacked and sold on the black market with secure digital tokens. These tokens have absolutely no value to thieves/fraudsters. That’s because only the major card networks who provision the tokens are capable of decrypting them. What’s more, tokens are unique to the devices and e-commerce merchants they are provisioned for.
Say, for instance, a Visa cardholder adds her credit card to Apple’s Passbook so she can begin to use Apple Pay. Upon receipt of the request, Visa creates a unique token and sends it to the cardholder’s Apple Pay-compatible device. When the cardholder uses her device to transact, the phone passes the token to the terminal or e-commerce merchant. So even if a crook managed to both steal and decrypt the token, he or she would also need to have access to the very device from which it originated to make any use of it. This all but eliminates the black-market value of stolen payment tokens.
This is proof as to why tokenization has support from all corners of the industry – from card brands to merchants to issuers. Now thanks to Apple’s highly visible use of the technology inside Apple Pay, even consumers are excited about the benefits of tokenization. More importantly, tokenization promises cardholders enhanced security without asking them to do anything special to obtain that extra layer of safety.
A weakness in the system
Tokenization is not immune from strong criticism. The author Slava Gomzin – in his book Hacking Point of Sale: Payment Application Secrets, Threats, and Solutions (Feb 2014) – dedicates a section to tokenization titled the "Fallacy of Tokenization". Gomzin argues that tokenization has a huge drawback that it cannot overcome in that “it cannot protect sensitive authentication data as the payment processor and acquirer have to have the original data in order to authorise the payment.”
Gomzin claims that Tokenization is only suitable for the storage of sensitive cardholder data and does little or nothing for protecting data that is processed and transmitted.
The fact of the matter is that the original credit card numbers still have to be stored somewhere. They are either outsourced to a vendor to store or the numbers are stored in token vaults within internal systems. Either way the protection of those systems remains critically important. However, from the point of view of retailers, at least the protection of this data becomes somebody else’s problem once payment details are tokenized.
Examples of credit card tokenization today?
Apple Pay. If you purchase an iPhone 6, 6Plus, iPhone 7 and 7Plus and load your credit card information onto the device, each of your credit card numbers will be tokenized and stored on the phone’s secure element. When you make purchases with it, the token will be used in place of your card number. This is just one reason that Apple Pay is expected to become one of the safest ways to use your credit card.
Samsung Pay. On the Samsung phones i.e. S6, S6 Plus, S7 and S7 Plus, Samsung also replaces "sensitive card data" with token payments. The retailer receives only a device-specific token and a dynamic, one-time-use security code. Only the bank and payment network ever have access to specific credit card information. The credit card data is not kept anywhere on the device. So like Apple Pay, Samsung Pay is also a safe way to pay using a credit card.
In a nutshell, the process provides undecipherable, unique tokens for each transaction. Merchants store the token, not the card number and the tokens can be used for future transactions as well as returns or refunds. The system allows merchants to reduce their scope of PCI Compliance, and lessens the burden of transmitting, processing and storing payment data.
Tokenization greatly reduces the risk of fraud by removing confidential credit card information/data from the payment network.
Thanks to tokenization, emerging alternatives to secure element-based NFC, like Host Card Emulation (HCE) have been endorsed as secure by payment brands, finally opening the door to independent, bank-owned mobile payment apps.
Banks and Payment providers can now use HCE and tokenization to create their own payment apps without necessitating access to complex mobile storage and chips. Combining tokenization with techniques to encrypt and hide security keys and sensitive data in the code of mobile apps helps secure HCE-based wallets on Android devices.
The road to including tokenization technology is fast and straightforward for all involved parties. Tokenization has no impact on physical retail NFC terminals, on the processing side of payments or on the perceived consumer purchase experience. In addition, there is no need for merchants to invest in new hardware or software and, for issuers, implementing tokenization has little impact on their existing back-end technology. So there are very few reasons for mobile payments innovators not to embrace tokenization to improve their security.