Like encryption, tokenization seems to have a mystic quality surrounding it. And like end-to-end encryption, tokenization is seen by merchants as a way to avoid being bothered by that pesky PCI compliance process. However, even with tokenization, merchants still have to comply with certain parts of the PCI DSS.
Before we discuss the risks and compliance requirements, let me explain tokenization. In a nutshell, tokenization is the process of taking sensitive data as input and returning a “token” that represents that sensitive data as output. The token typically has no relationship with the sensitive data it replaces and can be shorter or longer than the original sensitive data. The token is typically made up of a variety of upper- and lower-case alphabetic, numeric and special characters depending on the algorithm used. An important thing to remember is that tokenization does not imply encryption. However, encryption may be used for tokenization as can one-way hashing. When encryption is used as a way to tokenize sensitive information, the system receiving the token never has the capability to decrypt the token.
The way tokenization works for credit card processing is that the merchant’s point of sale (POS) system takes the cardholder data, either from a card swipe or manually input, and passes it to the credit card networks for transaction authorization. Once the transaction is authorized, a 16 character token is generated by the processor and is passed back to the merchant’s POS where the token can be stored in place of the PAN. This means that for credit card processing applications, the token is 16 characters long. In addition, the token can contain the last four digits of the PAN for transaction reference. The original cardholder data, i.e., cardholder name, PAN and expiration date is stored on the processor’s system for reference.
Note that in my example above I used POS as the system accepting the token. There is no credit card terminal involved. It is not that tokenization does not work with a credit card terminal, it is just that tokenization best pays for itself when used with an application that stores sensitive information and the end user does not want to store that sensitive information. Since most credit card terminals are not configured for storing the PAN after authorization, there really is no point in using tokenization.
One feature that tokenization can provide is the ability to process recurring transactions. In a recurring transaction scenario, the processor provides a mapping capability between tokens and the original cardholder data. On a recurring transaction, the merchant passes the token back to the processor and the processor looks up the token and then generates a transaction based on the cardholder data associated with the token.
Depending on the tokenization method, another potential feature is the ability to analyze card usage. In some tokenization solutions, a given PAN will always produce the same token value. As a result, not only is the PAN protected, but it can still be used for analysis purposes such as fraud analysis and loyalty programs.
As with any technology there are risks associated with tokenization. As we saw with end-to-end encryption, the endpoints in the tokenization process are at risk. Because there has to be a way to get the cardholder data into the process, the merchant’s POS is the most likely point to attack. The problem with POS systems is that they can typically provide a “target rich” environment to be leveraged either from their operating system or their applications. While the PCI DSS has requirements to address these potential targets, ensuring security across the full range of targets requires a level of diligence that most merchants just cannot provide on a consistent basis.
Another threat shared with end-to-end encryption is the tampering of software used to process transactions. While the PA-DSS certifies that an application properly processing and storing cardholder data, it has limited applicability as to whether an application is surreptitiously storing or transmitting cardholder data prior to starting the tokenization process. As a result, it is relatively simple to introduce tampered with software that could gather cardholder data without the merchant knowing.
To mitigate the risks of tokenization, merchants should consider the following actions.
- Purchase your POS software from a reputable vendor. This is not a perfect solution to the problem, but doing this should be better than buying it off of eBay or downloading a free open source solution. Yes, you save a few bucks, but is that worth having every one of your customers that uses a credit card being compromised? Probably not.
- Ask your supplier of POS workstations about what they do to test these systems to ensure that they operate as expected and are not routing cardholder data to Timbuktu as well as your bank. Ask them to provide those procedures in writing and review them to ensure they appear adequate.
- Use serialized tamperproof tape on the seams and doors of your POS workstations. Require that at every Manager shift change the new manager on duty is required to log their review of the devices, inventory the devices and notate if any have been tampered with. If a device does appear to have been tampered with, it should be taken out of service until a new, secure device can replace it.
- If using self-checkout systems, make sure to have those systems under both video and employee monitoring.
- Review video monitoring if any manager notates that a device may have been tampered with to determine if you can identify possible suspects that may have tampered with the device.
- Patch your POS workstations and application as soon as possible to minimize their susceptibility to attack or compromise.
- If the vendor of the POS solution will perform updates, make sure that you or someone in your organization schedules the updates. If anyone shows up at a location to “update” your POS and it was not scheduled by your organization, contact law enforcement.
- If updates will be done by the vendor remotely, make sure that someone from your organization initiates the remote access and they observe the remote update process. At the end of the update process, the person should terminate the remote session of the vendor.
At the end of the day, tokenization is not a bad solution for those environments where investing in all new POS is not an option or where the merchant might still want the ability to do PAN analysis. However, tokenization has risks just like any other solution. Granted, those risks might be fewer, but there are still risks. And it is important for merchants considering tokenization to understand those risks before blinding accepting them.