When it comes to ensuring that only authorized personnel are allowed into systems remotely, one of the best ways is to use a token. When it comes to keeping Credit Card Holder Data protected, one of the best solutions is tokenization. Many options exist for token use as well as for tokenization. We will discuss the basics of tokens, tokenization, and token service providers (TSPs) below.
Tokens – What are they and why are they a thing?
To understand the need for tokens, you must first understand some security basics.
The Difference between Authentication and Authorization
OWASP defines Authentication as the process of verification that an individual, entity or website is who it claims to be.
Authorization is what that person is allowed to access once they are authenticated.
When authenticating, there are 3 factors that can be taken into consideration:
- Something you know: This is by far the most common authentication instrument. Username and password is an example of something you know. Ideally, this information exists only in your mind and cannot be discovered without you telling someone.
- Something you have: This is where tokens come in. You must physically carry a token and reference it when it is time to log in.
- Something you are: This is where biometrics comes in. Biometrics assesses something uniquely you. Most often that thing is your fingerprint, but it can be from your eye as in retinal or iris scans, or your hand geometry. Less common methods check your ear shape, facial recognition, or even your voice.
Assess your PCI compliance
Multi-factor Authentication
To be reasonably sure a system is authenticating the right person, you need to use a combination of two or more of these factors. You may have heard it called “Two Factor authentication”, but that is a misnomer, since you may use more than two factors, however, two factors is the norm. Most commonly, it is something you know and something you have; a password and a token. That way, if a person’s credentials (user name and password) are lost, stolen, or otherwise compromised, the person with those credentials still can’t authenticate without the token. The login sequence goes something like this:
- User ID ________________
- Password ________________
- (if the user ID/password combination is valid)
- Enter token number
- Authorized
If done properly, both the password AND the token must be presented for authentication.
Tokens
There are many different examples of tokens:
- Card: Card tokens cards contain a chip in them that needs to be read.
- Fob with Chip: A small chip that might hang on your key-chain, usually used for physical access to a restricted area.
- USB fob: The authentication information is on the USB drive
- Electronic fob: A small device that contains a number generator that changes the number periodically concurrently with the authentication server.
- Software token: Software resides on a mobile phone and works the same as the electronic fob.
There are many options for tokens, they are all things are physical items with unique data on them. In the case of the electronic tokens, it’s ever-changing data. The end goal is having a second factor for authentication.
Here is a handy reference for determining multi-factor authentication. You MUST have at least two factors from different columns to qualify as multi-factor.
Something you know, have, are:
Know |
Have |
Are |
| User Name | Token card | Fingerprint |
| Password | Token USB | Iris scan |
| First pet’s name | Electronic fob token | Retinal scan |
| Street you grew up on | Mobile phone token app | Ear shape |
| Mother’s maiden name | Facial Recognition | |
| Place you met your spouse | Typing pattern | |
| Favorite movie/book | Voice |
Often, people require multiple things you know and call it multi-factor authentication. For instance, you might need to enter your user name and password and then give the name of your first pet on a follow-on screen. The problem is that all three things are something you know (located in the same column above), which is a single factor. This would NOT be an example of multi-factor authentication.
Tokens vs Tokenization
The Oxford dictionary’s definition of Tokenize is: “To substitute a randomly generated identifier for (a sensitive piece of data) in order to prevent unauthorized access.” In the context of this article, the sensitive piece of data we are concerned about is credit card data. Tokenization removes credit card numbers, known as Primary Account Numbers (PANs), and expiration dates from a merchant’s server. This way a merchant’s servers add a layer of protection to the customer’s card data.
If the merchant’s data is compromised, no cardholder data exists in the merchant environment and cannot be part of the compromise. All the hacker can get is the token number, which cannot be used independently to charge the card. In the event a merchant’s data was compromised, there aren’t even reporting or notification requirements if security token numbers were stolen.
It works like this:
- The customer enters/swipes/inserts card for payment
- The payment card data goes directly to the Token Service Provider (TSP) which stores that data in a “Data Vault” and gets authorization for the transaction through normal channels
- The TSP returns a Token number to the merchant which is used for the transaction and stored on the merchant’s server
The token corresponds to all the card data held at the TSP, so all storage of sensitive data is done by the TSP effectively transferring risk from the merchant to the TSP.
Token Service Providers (TSPs)
Token Service Providers are able to specialize in the Payment Card Industry’s Data Security Standards (PCI-DSS) and compliance with those standards. They have their own separate set of rules they must follow and their own Report On Compliance (ROC) issued by the Payment Card Industry Data Security Council (PCI-DSC). They create a very secure environment in which to store the card data they are sent by merchants.
By comparison, many merchants aren’t really sure of the PCI-DSS requirements and don’t have time to learn them because they are running a business. Although some companies do it, adding staff for this purpose can be prohibitively expensive. By engaging a Token Service Provider, you make the Card Data Environment (CDE) much smaller. This also has the effect of significantly lowering the scope of PCI compliance since it so significantly lowers the amount of data that has to be protected. That in turn lowers the cost of protecting the data, the cost of PCI assessment, and the time spent on PCI assessment. TSPs have made it very easy for personnel writing code to integrate the TSP code, freeing up your development team for more software development!
Tokens vs. Encryption
If a merchant stores Card Holder Data (CHD) and wants to comply with the PCI-DSS, they have to encrypt certain card holder data. When they display that data, they have to mask it.
Encryption involves using complex algorithms (math processes) and a key to encrypt. That involves key management because the algorithm is common knowledge and the only thing keeping the data secure is the key. Cryptographic key management is a big deal in data security.
Of primary note is the fact that encrypted data can be decrypted back to its original format. Learn more about protecting system components in CDE through encryption in our related blog.
Masking on the other hand is unencrypted data that is merely hidden from view. A masked PAN might look like this: **** **** **** 1234
The whole PAN is there in the program displaying it, it is merely changed for display purposes.
Tokens are actually randomly generated replacement strings. Tokens can NOT be decrypted. The bad guys could never ‘crack’ a token. It has no mathematical relationship to the PAN. They are a replacement string. Their only tie to the Card Holder Data is in the Data Vault at the TSP which connects the Token to the CHD. A token can retain the same format as the original data and look like a PAN, or they may be alpha-numeric in nature and look nothing like a PAN, for example:
84h63m90-65b1-678a-8264d20bh3873
This table provides a comparison between the 3 ways of handling sensitive data we just discussed:
| Tokenization | Encryption | Masking | |
| Reversible | No | Yes | Un-necessary |
| Managed “in-house” | No* | Yes | Yes |
| Recurring costs | Yes | No | No |
| Can be used on any data set | Yes | Yes | Yes |
| Effect on PCI scope | Decreases scope | Provides compliance | Increases risk |
| Required to notify customer if data is compromised | No | Yes, unless you can prove it was encrypted | Yes |
*In-house tokenization is discussed below.
In-house Tokenization
As mentioned above, tokenization CAN be handled in house. Most small businesses and even some larger businesses would have to bring on additional staff and resources to manage this portion of their card data handling. In addition, while it does still help secure your sensitive data, it puts all the pieces necessary to make that data available on the same network.
According to some comparative reports, the operation costs of in-house payment tokenization outweigh the overall cost of having a token service provider. I highly recommend you do your own comparison if considering this option.
The Cons of Tokenization
While Tokenization is a very good solution with a lot of upside, it is not perfect. There are a few potential pitfalls to watch out for:
Collisions
It is possible for the same token to be issued to different cards, charging the wrong card.
Chargebacks
If there is a problem with a transaction and it is challenged, in order to investigate, the merchant needs to coordinate with the TSP to identify the necessary information to resolve the chargeback which may take longer that you like.
Randomization
You must ensure tokens are randomly generated and not created using any kind of reversible algorithm. Being able to “solve” a token completely defeats the purpose of the token.
Replaying
Your TSP must have a system in place that prevents the re-use of tokens. If tokens are reusable, the token acts the same as the original card data which puts you in the same position you were in before tokenization.
TSP compromise
Because they are storing so much sensitive information, TSPs can be attractive targets for hackers to go after.
All of these potential issues can be mitigated with careful selection of a reputable TSP. Due diligence is key here!
In Summary
While the concept of tokenization and using a token web service provider may seem a little daunting at first, it is a cost effective method of safeguarding your client’s sensitive data, reducing your PCI scope, and lowering your company’s risk in the event of a data breach. Don’t hesitate to contact RSI Security for expert cybersecurity solutions or PCI compliance advisory services.
Our PCI DSS services include:
- Onsite security assessments and full report on PCI compliance (ROC)
- Assistance with Self Assessment procedures and reporting (SAQ)
- Attestation of Compliance (AOC) certificate
- Risk Assessment
- Network Penetration Testing
- Vulnerability Scanning
- Gap Assessment
- Patch Management (PCI DSS Requirement 6.2)
- Employee Education & Cybersecurity Awareness Training services
Stay Secure!
Download Our PCI DSS Checklist
Assess where your organization currently stands with being PCI DSS compliant by completing this checklist. Upon filling out this brief form you will receive the checklist via email.