Has Tokenization Come of Age?
By David Dorf-Oracle on Jul 16, 2009
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.
"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.
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."