The Green Sheet Online Edition
May 09, 2011 • Issue 11:05:01
What tokenization is and isn't
Tokenization is a heavily promoted technology in the Payment Card Industry (PCI) Data Security Standard (DSS) space. Vendor claims range from stating that tokenization helps reduce the scope of PCI to insisting that it makes PCI compliance problems go away. The first claim is fairly accurate; the second is false.
When a solution is caught in a wave of hype and fashion it can be hard to separate fact from fiction. Hopefully, this article will clarify what tokenization can do.
What does tokenization do?
First, tokenization is not snake oil. It is an example of good security principles put into practice. People go wrong when they exaggerate its effect until it becomes likened to a "magic pill."
The principle behind tokenization is simple. The best way to handle security concerns, such as the theft of stored data, is to avoid the problem altogether. By far the best way to protect cardholder data that you store is to stop storing it. No one can steal what you don't store.
That's fine in principle, but for many merchants there's a downside to not storing cardholder data like primary account numbers (PANs): their businesses need that information on hand so they can do things like recurrent billing.
Tokenization gives merchants the benefits of storing data, without the security costs. The benefit of storing PANs and other sensitive information is that merchants can then reuse the cardholder data for subsequent transactions by passing it back up to the gateway or processor.
But since we're talking about subsequent transactions, the gateway or processor has already handled the same cardholder data before. If the gateway or processor stores the details, what it needs from the merchant isn't the sensitive information itself, but rather a suitable reminder so it can pull the information out of its database.
In effect, instead of the merchant storing and then resending sensitive information like the cardholder's name, card number and expiration date, the merchant can just identify the customer, provide the amount of the new transaction and ask the processor to look up the account details.
How does it work?
In practice, the processor and the merchant agree to label a particular customer with a unique "token" (typically a 16-digit number), and all the merchant needs to store is the token, not the PAN and other identifying information.
The merchant then reuses the token every time he or she would otherwise have reused the sensitive information. The processor knows that when the merchant sends up that token, it needs to go look up and load that particular customer's details.
A few things to note:
- Tokenization naturally works at the account level, not the transaction level, since transactions are not perfect repeats of earlier ones (especially when you take into account things like time-stamps).
That isn't a problem, because the details of how much to charge, etc., are simply not that sensitive.
- It is critical that the token not be a disguised PAN: it needs to be essentially a random nonsense number that's only useful as a label.
That way, if the merchant gets hacked and the tokens are stolen, it isn't anywhere near as much of a problem as having the PANs stolen, because the attackers can't possibly extract the PAN from the data they've stolen.
- Tokenization relies on the real information being stored at the gateway or processor, so it shifts the burden of security from the merchant to the gateway or processor.
The idea is that these entities have the size and sophistication to do a superior job of protecting that sensitive data.
- The idea of using a 16-digit token is so that it can be treated like a PAN in a merchant's existing computer system.
Thus the merchant doesn't have to undertake a significant system upgrade. The real meaning of the token only comes into play once it hits the gateway or processor.
It is critical to note that tokenization does not eliminate PCI responsibilities for merchants. Merchants are still accepting payment cards and must continue to comply with the PCI DSS. This becomes obvious when you think about it, because tokenization doesn't replace the need to get the cardholder data into the system in the first place.
How will merchants benefit?
There are very real benefits from tokenization, though, for most merchants. These include:
- Merchants and their customers enjoy a substantial improvement in security when tokenization is employed.
- Tokenization simplifies PCI compliance for the average merchant. It does this by reducing the scope of PCI because merchants can now (hopefully) answer no to the question "Do you store cardholder data?" This also means that merchants can either answer "not applicable" to a range of messy questions about cardholder data security or avoid the questions altogether by qualifying for a simpler version of the Self-Assessment Questionnaire.
This last point should make it clear that tokenization doesn't do much for merchants if, for different reasons, they continue to store PANs in systems other than those set up for payments.
The payoff from tokenization is being able to stop storing sensitive cardholder data. There is only a tiny benefit in storing the data in one place instead of two; 99 percent of the payoff comes from going from one storage place to none.
I recommend that merchants (or the ISOs, merchant level salespeople and banks acting on their behalf) keep the following points in mind when evaluating companies that provide tokenization:
- Look for a solution provider who understands that tokenization shifts a big part of the data security burden to the provider but does not eliminate merchants' responsibilities in this regard.
- Don't trust a vendor who says tokenization makes PCI go away. Anyone who says that is willing to put you at risk and misinform you just to make a sale.
With these simple guidelines in place, merchants, ISOs and others have an opportunity to use tokenization to simplify and secure an important part of their businesses.
Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. (www.panopticsecurity.com). He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at email@example.com or 801-599 3454.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.