Whenever you send or use data, it presents another opportunity for attackers to get their hands on it. We can reduce the risk of data breaches by limiting how we use and expose sensitive data.
We have a bunch of different ways that we can limit the exposure of data, but today we’re going to talk about the process of tokenization. It’ll be easiest to understand if we run through an example.
The problems with storing and securing sensitive data
Let’s say that you run an online store. To make future transactions smooth for your customers, you want to store their credit card number, so that they don’t have to go through the hassle of typing it in every time.
One option would be to store their credit card information in a database on your servers. This would make it super easy for them to make future purchases, so everyone should be happy, right?
Unfortunately, this would be a security nightmare for a small ecommerce store. Do you really want the responsibility of defending that data against attackers? You would have to secure and monitor it yourself, and you would need to make sure that everything was done perfectly. This is a big ask for a small store, so it’s not really practical. All it takes is one slipup and the store would have a big breach on its hands.
On top of the security challenges, you would also have to consider Payment Card Industry Data Security Standard (PCI DSS) compliance. Storing credit card numbers in a way that complies with the standard is a significant burden for businesses.
Thankfully, tokenization gives us another option.
What is tokenization?
The challenge of the arrangement described above is that you are responsible for securing and transferring highly sensitive information. With tokenization, you can limit how that sensitive information is used, or even pass on much of the responsibility to a third-party who specializes in securing this type of information.
Let’s say a customer sets up an account and enters their credit card details. With tokenization, instead of storing the valuable financial data on your servers wth the rest of your customer records, you send that data straight to a tokenization system, alongside authentication information about the customer.
The tokenization system then generates a token, which is basically just a random number that is mapped to those particular credit card details. The token itself isn’t actually valuable, but it can be used to lookup the credit card information from the tokenization system. If an attacker gets their hands on a token, they don’t instantly have the sensitive credit card number.
It’s kind of like how a casino chip is a representation of money, but not actually money itself. At the casino, you can hand it in and exchange it for cash, but you can’t just buy candy at 7-11 with casino chips.
The token and the credit card details are recorded in the tokenization system’s card data vault. When a new credit card is stored, the Tokenization system generates a new token and sends a copy of the token back to your website’s server, where it can be stored alongside the other customer information. Your website never stores the credit card details, just the non-sensitive token, which eases the security and compliance burden.
Making a purchase
When the customer goes to make a purchase, you send their authentication information alongside the token to the tokenization system. The tokenization system verifies the authentication information, and if it’s valid, it then looks up the customer’s credit card information, and then sends the credit card information to the credit card processor.
The customer can then complete the purchase, without having to re-enter the entirety of their credit card information.
Tokenization deployment models
Tokenization can be deployed as an outsourced solution, where a third-party provider offers the tokenization system and takes on much of the responsibility. This is a great solution because it minimizes the security and compliance burden that organizations face.
It can also be deployed as an in-house solution, which gives organizations more control. However, it means that they are responsible for setting up their own tokenization systems, securing them, and meeting compliance obligations. While organizations still need to store and secure credit card numbers under this deployment model, the use of a tokenization system can help to limit the number of system components that must comply with the PCI DSS.
Hybrid solutions are also possible, offering a middle ground in terms of control and responsibility.
