You always want to ensure that only authorized users are allowed to access your systems & resources. Before the issue of authorized access is handled, you have to tackle the issue of 'Authentication'.
It is Authentication, where you use the TOKEN...
So what is authentication?
It is the process of verification that an individual, entity or website is who it claims to be.
How do you do that?
You do authentication based on three factors: What you know, What you have, What you are.
Something you have, is where 'tokens' come in the picture. Your users must physically carry a token and reference it when it is time to log in. There are many types of token to make available to your users, such as:
-
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.
TOKENS 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.
-
What is Tokenization?Tokenization is the practice of substituting a randomly generated identifier for a sensitive piece of data, so that any unauthorized access to original data could be prevented.
For example, your credit or debit card number and corresponding 'Expiry Date' is always tokenized, whenever and wherever you make any transection using them. The merchant where you are doing so, never gets to know what was actual number and expiry date of your debit/credit card. What they get in their records is only a 'Token' provided by the 'Token Service Provider (TSP).'
Thus, tokenization adds a layer of protection to your card number (known as PAN) and its data.
What would happen is the merchant's server is compromised (attacked by hackers)?
Nothing!
None of important data about Debit/Credit Card 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.
To understand it better, let us revisit how a transaction is made:
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 actually practically stores that data in a “Data Vault” and gets authorization for the transaction through normal channels.
-
Then 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.
As you see, here the role of Token Service Providers is very critical. TSP are able to specialize in the 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.
In most settings, it is always advisable to with the services of TSP, rather than going for doing whole tokenization in-house.
-
How Tokenization is different from Encryption?You already know that encryption involves using complex algorithms (math processes) and a key to encrypt. That involves Key Management because almost everyone knows the algorithms and the only thing that is keeping the data secure is the key. Cryptographic key management is a big deal in data security.
Extremely important fact is that encrypted data can be decrypted back to its original format.
TOKENS are never encrypted form of your Credit/Debit Card Numbers (PANs), they cannot be decrypted. Because they mean nothing...Tokens are actually randomly generated replacement strings. What is there to decrypt? Nothing
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, e.g.,
CARD NUMBER: 5847-5369-0087-1257
Token: 5487-2489-9654-1751
Or, they may be alpha-numeric in nature and look nothing like a PAN, for example:
CARD NUMBER: 5847-5369-0087-1257
Token: 84h63m90-65b1-678a-8264d20bh3873
-
Since we have already covered tokenization, why not to throw a little light on 'Masking'?
Masking becomes imperative for merchants who have implemented the in-house tokenization. They already have all the credit card data with them, they don't need to tokenization all the time, like Banks.
They would then present the Debit/Credit Card data in all displays with 'Masking'. In such cases, it would look like:
CARD NUMBER: 5847-5369-0087-1257
Masked number: xxxx-xxxx-xxx-1257
But never forget that this in-house tokenization approach has resulted in a HUGE RISK, as far as the scope of PCI-DSS is concerned.
-
Thus, when it comes to keeping Credit/Debit Card Holder Data protected, one of the best solutions is tokenization. Although no technology can guarantee the prevention of a data breach, a properly built tokenization platform can prevent the exposure of sensitive data, stopping attackers from capturing any type of usable information, financial or personal.
-
Kindly write 
your comment on the posts or topics, because when you do that you help me greatly in 
designing new quality article/post on cybersecurity.
your comment on the posts or topics, because when you do that you help me greatly in designing new quality article/post on cybersecurity.You can also share with all of us if the information shared here helps you in some manner.
This Article Was Written & published by Meena R, Senior Manager - IT, at Luminis Consulting Services Pvt. Ltd, India.
Over the past 16 years, Meena has built a following of IT professionals, particularly in Cybersecurity, Cisco Technologies, and Networking...
She is so obsessed with Cybersecurity domain that she is going out of her way and sharing hugely valuable posts and writings about Cybersecurity on website, and social media platforms.
34,000+ professionals are following her on Facebook and mesmerized by the quality of content of her posts on Facebook.
If you haven't yet been touched by her enthusiastic work of sharing quality info about Cybersecurity, then you can follow her on Facebook:
Click Here to follow her: Cybersecurity PRISM