When I first heard about credit card number tokenization, I couldn't believe I missed such a simple solution. I was so focused on complex encryption that I didn't "think out of the box." Since then I know of several retailers that selected that solution, and several others that have chosen to stay with encryption.
So what exactly is tokenization? I came across an interesting article in which Shift4's Randy Carr uses a princess analogy to explain the concept:
"Say you have a castle with a princess, and all these bad guys keep riding up trying to kidnap her. The way the industry has approached security is to put a moat around the castle, bar the doors and windows and put archers on the roof. Why don't we just remove her from the castle?'"
Once an authorization is received, a token is generated that replaces the actual credit card number. The token follows the constructs of credit card numbers, so it meets validation requirements in existing applications. From an application's point-of-view, the token looks just like a credit card number.
For all subsequent interactions with the acquirer, the "token middleman" converts tokens to credit card numbers. This allows the retailer to claim no credit card numbers are stored in its databases, yet still be able to process charge-backs and returns. The security onus is back on the gateway, off the retailer's premises.
Companies such as BluePay, EPX and MerchantLink are using this approach to help retailers meet PCI compliance.
But how is this different than encrypting the credit card number? Couldn't a token simply be a secure hash of a credit card number? Yes it could, but the elegance of the token is that it mimics the format of credit card numbers so that existing applications work as is.
Of course when a card is swiped, the credit card number needs to be protected until it can be tokenized, so some encryption is still necessary. But that's transient encryption, so keys are temporary and require very little management.
As Shift4 says, "They can't steal what you don't have."
Subscribe via RSS
Subscribe via Email
Comments (2)
I understand the application of this method in the PCI arena. The data is in flight and needs to be protected. However many organizations have large amounts of sensitive customer information that is at rest on storage devices. Government regulations require this data be protected. The dominant approach is to encrypt this data. Or could the token approach be adopted? What are the tradeoffs for data in flight versus data at rest? Encryption vs Tokenization?
Posted by John | July 22, 2009 6:40 PM
Posted on July 22, 2009 18:40
John, good point. I often tell retailers that they should look at security at the enterprise level, not just focus on POS. In that case, it makes sense to have a single keystore (like a HSM) that can be used for encryption across many different systems. Encryption is certainly more versatile, but also more disruptive. I think when a retailer just wants to solve their immediate PCI needs, then tokenization is a great approach. If they are looking to secure lots of different types of data, like PII, then general purpose encryption should be considered.
Posted by David | July 23, 2009 7:18 AM
Posted on July 23, 2009 07:18