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.
PCI Guru 
Hello – wondering if you have seen Issuing Banks apply tokenization using a card processor, so that only the tokenized PAN is passed within the FI’s internal systems in order to reduce PCI DSS scope?
That is one way to control scope although it might not reduce it as much as you might think. At the end of the day, there is no way an FI can reduce scope like a merchant can with tokenization and end-to-end encryption (E2EE). That is because this is business an FI is in and what you are paying an FI for, to manage and secure this information.
PCI have now released their Tokenisation Guidance document:
Click to access Tokenization_Guidelines_Info_Supplement.pdf
One tokenization solution that my company is looking at may address those risks that you mentioned, and I would like your opinion on where any additional risk would be present. The solution is comprised of an external card swipe, that uses asymmetric keys, to encrypt the PAN, etc before handing it off to the register. The payment app on the register encrypts the encrypted card number via an SSL key, sends that off to the processor, who unencrypts both the SSL and the original encyrption, and sends back a token with the authorization code. In this setup, unless I’m missing something, we never see the card number on our system, and our CDE should only be the original card swipe device. The overall risks should be minimal and should theoretically remove everything else from scope.
Classic mistake. The PCI DSS makes you responsible for the processing, transmission and storage of cardholder data. While storage and transmission are out of scope in your example, the terminal is still processing that data from the swipe and encrypting it. If I compromise the terminal and put a widget between the swipe and the encryption process, then you have a problem. This is the new threat and a very real one as we have seen a number of instances where this has occurred over the last few years.
While there is little you can do about this before you get the terminal, there are a number of things you can do once the terminal is installed. You should be configuring and monitoring your network to ensure that there is no traffic going somewhere you would not expect. This means limiting IP routes inside and outside your network. It means ensuring that you have procedures in place to address any surprise terminal change outs, i.e., if the store is not aware of a terminal change out, then it should not happen and they should notify corporate. It means establishing processes to ensure the security of the terminals so that they cannot be tampered with. It means having incident response procedures in place to respond to anything that might indicate that one or more terminals are compromised. It means having video surveillance to determine when terminals might have been tampered with.
Your POS register also encrypts the swipe, but at that point it’s no longer considered cardholder data because it was already encrypted by the terminal.
So to add another scenario, if we use an iframe to redirect the user to authorize.net to generate a token, our initial app that had the iframe will still be in scope and part of our CDE and anything that connects to that app server is still in scope?
The requirements in SAQ A are the absolute minimum you can get with either a redirect or iFrame.
So if we, as a merchant, hosts a web application that redirects payment processing to a 3rd party, we are eligible do to SAQ-A? I thought that since the redirect is coming from a web server at our site that we can “impact” the security of the payment transaction and thus must do an A-EP. The reason i am asking is because our developers said that we can do SAQ-A becasue authorize.net said so if they use the Accept Hosted payment form. https://developer.authorize.net/api/reference/features/accept_hosted.html
Thanks
Not that I am a fan of SAQ A because of the security implications, but your developers are correct. That said, remember, if that redirect EVER changes to a bad site, it’s on YOUR organization and not authorize.net which is why you want to scan it, pen test it, and monitor it. All things that are NOT required in SAQ A. So I am with you that A-EP might be a better fit, but the Council says otherwise.