Not all Tokens Are Created Equal – Cross Domain Tokenization Creates Major Risks
Tokenization has taken hold as the best way to remove toxic data from organizations’ business and IT environments. But not all tokenization solutions provide equal protection. Many tokenization solutions are designed and implemented without taking customers’ organizational structure and business needs into consideration. Whether it’s an incorrectly implemented on-premise solution or a tokenization service provider that doesn’t follow best data security practices, fraudulent use of improperly tokenized data is a real threat. In particular, the problem of cross-domain tokenization creates scenarios that put an organization’s data security at risk. What is cross domain tokenization and why should you care? What potential fraudulent activity is created with cross-domain tokenization? How do regulatory bodies influence your choice of tokenization provider? What tokenization solutions exist to avoid fraud in your data environment?
Understanding Cross Domain Tokenization
Cross-domain tokenization occurs when a token generation process mathematically creates the same token for a specific value, which is reused across multiple domains. Let’s take as an example a parent company that provides tokenization for payment processing for multiple subsidiaries (domains). The token generated for a unique Primary Account Number (PAN) for Subsidiary A, is the same token that is generated for Subsidiary B for the identical PAN. In this situation, the token in effect becomes the actual payment card number and can be used across multiple subsidiaries for payment processing. Why is this a bad idea? It creates the potential for fraudulent use of the tokens across all the subsidiaries.
Fraud Potential with Cross-Domain Tokenization
Think of it this way, if we create a unique token for every theoretically possible PAN, then all we have done is create a new representation of a sensitive data set. Should a hacker figure out how to present these tokens for payment with one company, they would theoretically be able to present the same tokens at a different company for payment. In cross-domain tokenization, the tokens used in one organization match with the same tokens for payment cards in another domain, and fraudulent use is a very real risk.
Keep in mind that, even though cross-domain tokenization presents fraud issues, the environment is tokenized and the original PAN data is still safe. The important point to remember with cross-domain tokenization is it’s more of a fraud issue than a data theft issue.
The Culprits of Cross-Domain Tokenization
There are two main culprits of cross-domain tokenization: payment processor service providers that also supply tokenization, and custom-made, on-premise tokenization solutions. Tokenization Service Providers and Payment Processors can introduce cross-domain tokenization situations when they use the same token-to-PAN mapping schema for all the merchants they are servicing. For example, Merchant A and Merchant B are both using Payment Processor Z. Processor Z takes a unique PAN and generates the same token for every merchant. So, in this instance, the same token is generated for a PAN used by both Merchant A and Merchant B. If a token from Merchant A’s vault is used at Merchant B, it could be processed for a fraudulent payment because it represents the same PAN. The solution is to always generate unique token/PAN combinations for each Merchant and store them in separate vaults.
The second potential culprit with cross-domain tokenization are in-house developed and on-premise tokenization solutions. In these cases, tokenization software is used as an internal service to support payment processing for multiple entities, such as business units. Similar to the service provider case, the on-premise solution is generating the same token for the same PAN to use across multiple domains, resulting in possible improper payment processing. To avoid cross-domain tokens, the tokenization software needs to be updated to generate vault-specific values for tokens. In other words, each domain or business entity needs its own vault with unique tokens for each PAN.
How to Avoid Cross-Domain Tokenization
When selecting Service Providers and Payment Processors to perform your tokenization, ask about their cross-domain tokenization and cross-vault contamination policies. Before committing to a tokenization vendor, perform a Proof of Concept with the service providers to ensure that the resulting token and PAN data is unique to each data vault.
For tokenization solutions developed in-house, use a crypto-graphically secure random number generation process to create tokens. After a token is created and before the token/PAN pairing is committed to a vault, run a validation process to ensure the token/PAN pairing does not already exist in any vault used by other business units.
With on-premise solutions by a third-party provider, ensure that the vendor clearly documents how their software avoids cross-domain tokenization and cross-vault contamination. There should be settings and configuration capabilities available for you to customize to avoid cross-domain tokenization in your specific environment—use them!
Data Security Standards Exist for a Reason
As you evaluate tokenization solutions, it is important to have a partner that is involved with the regulatory bodies that define standards for tokenization and data security. With a constant stream of new requirements from the Payment Card Industry, EMVco, and guidance from NIST and the Federal Reserve, your environment could be at risk if you use tokenization solutions that do not meet or stay up to date with the quickly changing data security landscape. TokenEx is actively involved with the standards committees to ensure that the TokenEx Cloud Security Platform meets or exceeds data security requirements across industries and regulatory compliance obligations.
TokenEx is committed to securing all types of our customers’ sensitive data with unlimited flexibility. Contact TokenEx to learn how to keep your organization’s sensitive data secure while reducing your payment tokenization and PCI compliance costs.