Posts Tagged ‘tokenization


There Are No ‘Silver Bullets’

For the last time, there are no single ‘silver bullet’ solutions to perfectly securing cardholder data and their related transaction flows.  As my blog shows, I get comments from all sorts of people saying otherwise.  However, whether you are talking about Chip and PIN, end-to-end encryption, data encryption or tokenization, none of these technologies offer the complete solution to stopping credit card fraud.

Chip and PIN

Chip and PIN was developed to address the problem of face-to-face transaction fraud.  It does not solve the problem of cardholder data being breached in back office systems where most breaches take place.  The attackers know that somewhere in the transaction flow process, someone has to have the cardholder data.  Chip and PIN does not address the back office and never will.  It is not that Chip and PIN is a bad idea, it is the fact that implementing Chip and PIN does not, in and of itself, solve the issues faced with breaches.

End-To-End Encryption

End-to-end encryption requires that each end uses the same encryption process.  So the first problem is that each acquiring bank or service provider will likely have their own particular implementation of end-to-end encryption meaning that interoperability will not exist.  So those merchants with multiple processors will likely have problems with end-to-end encryption unless they use separate systems.  However, that is minor compared to the next issue.  The other problem is that there are a lot of ISOs and service providers in the transaction flow that require access to the transaction making end-to-end encryption not quite as easy as one might think.  However, the biggest problem with end-to-end encryption is that it only protects the cardholder data from one endpoint to the other endpoint.  It does nothing about protecting the endpoints themselves or the environment outside of the endpoints.  As a result, the endpoints and the environments outside the endpoints become the targets.  While the endpoint at the processor or acquiring bank is likely fairly well protected, the endpoint at the merchant is probably the weak link and therefore the merchant is still the target.  The most likely target here is doctoring the card terminals or POS software so that the attacker can gain access to the cardholder data before it hits the encryption process.  End-to-end encryption does nothing to prevent the tampering of the endpoints.  As with Chip and PIN, end-to-end encryption only addresses a part of the problem.

Data Encryption

Data encryption is great for protecting the data when it is stored as well as when it is in transit.  However, unlike end-to-end encryption, under data encryption when data is in transit there are multiple points where the data is decrypted and encrypted as it moves through the authorization and payment processes.  Any one of these points could be compromised and the data encryption defeated.  Cardholder data that is stored encrypted still has the threat of being compromised either at the point it is encrypted or if the encryption key be compromised.  If data is only encrypted during transmission or if it is only encrypted when stored, the data is susceptible to compromise wherever it is not protected.  As with end-to-end encryption, data encryption can solve a portion of the problem, but not the entire problem.


Tokenization is the act of creating a value, the ‘token’, and using the token as a way to reference the actual cardholder data.  Tokenization is great for merchants because it allows them to keep their old systems running unmodified by having the system believe it is getting back the PAN when in fact it is just a token.  However, the cardholder data still has to be transmitted in order for a token to be generated, so the merchant is still not out of scope.  Worse yet, if the transmission is not protected, then the data stream is susceptible to compromise.  As with all of our other solutions, tokenization is also not a complete solution.

The bottom line is that none of these technologies individually is the answer to our security issues with cardholder data.  However, if they are used together, they can provide a formidable defense against compromise.  But why is that?  As with all good security solutions, it involves defense in depth.  Since there is no single, ‘silver bullet’ that can solve the problem, we have to look at multiple solutions that, when put together, create a defense in depth approach to provide as much security as possible.

By using Chip and PIN in conjunction with end-to-end encryption, data encryption and tokenization, we create a gauntlet of protection.  However, as I always like to remind people, security is not perfect and even this solution is not a ‘silver bullet’.  There are controls and monitoring required ensuring that endpoints remain secure, encryption keys are protected and that endpoints are not tampered with.  However, such an approach would go a long way to minimizing the threat of compromises.


Advice To Merchants

Barring the card brands developing a truly secure card processing process, the PCI DSS and related standards are likely to be with us for quite a while.  That said, what is the future of complying with the PCI DSS?

For merchants, if you are not seeking out point-of-sale (POS) solutions that do not store cardholder information, you should be as soon as you possibly can.  That includes finding card processors that do not require you to store cardholder information and can provide you access to cardholder information when you need it for resolving disputes and chargebacks.  According to Robert McMullen, CEO of TrustWave, the majority of breaches TrustWave investigated occurred with POS systems.  So the rational approach to resolving this problem is to get rid of the cardholder data stored on these systems.

The problem with this is that most merchants, large or small, think that they need to store this information for some reason.  If you are a merchant in the United Kingdom, France, Italy and other select European countries, then you do need to have the PAN unencrypted, however it only is required on an original printed receipt, it is not required to be stored anywhere else.  So, all merchants need to put POS solutions in place that do not store cardholder data.  You do not need it and it puts you at risk if you do store it.

The next thing merchants need to do is to find a card processor that does not require the merchant to store cardholder data.  This can be a processor that uses tokenization or whatever, but the bottom line is that the processor does not return cardholder data to the merchant’s systems.  These processors typically provide secure Web-based systems that allow the merchant to view all of their transactions processed and, if necessary, provide a method to decrypt the PAN for dispute research and chargebacks.  Merchants need to restrict access to the processor’s applications to only those people that absolutely need access to perform their job.  These people should be reviewed at least quarterly to ensure that they continue to require access.

For those of you that just cannot get rid of cardholder data, there is the option of hashing.  Hashing allows applications such as fraud discovery, member tracking, rewards programs and similar functions to continue, they just do not have access to the actual PAN.  A hashed PAN results in the same hashed value, so research and analysis of PANs can still occur.  It is just that if you need to see the real PAN, you will have to go to the processor’s system to obtain the real PAN.

The travel industry, in particular hoteliers, are really behind the eight ball on PCI because of their need to keep the PAN for sometimes years because of the way reservations work.  However, this is where tokenization can earn its keep.  If a hotel takes a reservation and gets back a token when the credit card is authenticated, then the hotel can use the token however many times in the future for check in and check out.  Again, there is no reason for the hotel to need to retain the actual PAN.

The bottom line to all of this is that there are ways to minimize your organization’s PCI compliance efforts just by getting rid of the data in the first place.  So, stop putting forth efforts to comply and get with the movement to get rid of the cardholder data in the first place.  I have had a few clients go down this road and PCI compliance is now a piece of cake.  Their networks are still in scope for transmission, their applications in some cases do process cardholder data, but there is not storage which makes them much, much less of a target.

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

June 2023