-
P400
LOADING...
#About Tokens: Challenges, Solutions, Importance, Precautions
#What is tokenization?
Tokenization is the process of replacing sensitive parts of the original data set with non-sensitive data and storing the sensitive parts in a secure location, on a trusted medium, and out of reach of cyberattacks.
#What is token?
The non-sensitive replacement is called a token. A token refers to a set of alphanumeric characters that prevents sensitive user data from being compromised.
#Why is tokenization so important?
A tokenized system is considered a safe harbor for sensitive data. Even if such a system were to face a potential data breach, there is no valuable information that could be intercepted or stolen, because the sensitive data has already been tokenized and transferred to a more secure destination.
The tokens themselves, essentially, have no value and cannot be misused to cause significant harm.
#Can a token be reprogrammed?
If the token is intercepted and recognized, or someone gains access to the location on the server where the token is stored, it is theoretically possible to reprogram (clone) the token.
Since the token does not contain any personal or sensitive data, reprogramming it would not compromise anyone's privacy or data security.
If the token is intercepted and recognized, or someone gains access to the location on the server where the token is stored, it is theoretically possible to reprogram (clone) the token.
Since the token does not contain any personal or sensitive data, reprogramming it would not compromise anyone's privacy or data security.
Moreover, if the token is intended for single use only (e.g. in the case of an online purchase, after which the token is removed from the server and cannot be reused), there is no benefit in cloning it at all.
This is one of the main reasons why the token is not stored on the user's device, as the possibility of misuse would be much greater.
#Should a token be encrypted?
Regardless of the fact that the token does not contain confidential information, misuse cannot be ruled out if the token is used multiple times, either by a legitimate user or server administrator, or by those who obtained the token in an unauthorized manner.
This especially goes for a token that is transmitted online. It is best to encrypt such a token just before it is transmitted and thus protect its content, as if it were a message with sensitive content.
The biggest challenge, however, is how to protect the token located on the server.
The token is not stored on the user's device for security reasons, but must reside on the server. If the token is stored encrypted, the decryption code must also be stored somewhere, which poses another security risk. The location on the server where the token is stored is offline and out of reach of hackers, but it is still in the domain of the server administrators who could - intentionally or unintentionally - misuse it.
The solution is to use the token only once, which eliminates the possibility of such abuse. This is not always possible, so the server provider must take appropriate precautions and clearly inform users about it.
#How are tokens used to sync data across multiple devices?
This primarily refers to allowing access to the system from different devices using the same username. The device that logs in first is the primary device and access is granted by default, provided that the correct username is entered and the corresponding private key stored in the device's memory is selected.
The question arises as to what should be done in the event that it is necessary to simultaneously execute an application from another device using the same username, and that such a possibility was previously prohibited for security reasons.
The first thing to do is to issue an access permit, either temporary, limited, or permanent, but under certain conditions. To solve this, we will call on DCCL technology in combination with tokenization for help.
The token is generated on the primary device, displayed on the screen, and entered into the appropriate field on the screen of the other device from which we want to log in.
There are two possible scenarios.
  • The secondary device does not have a stored private key and is granted temporary and limited access to the system to perform a specific task. A typical example is online payment where the primary device is the buyer's device and the device in which the token is inserted is the seller's device.
  • The secondary device has a stored private key, which means that the data has been previously sent from the primary device to the secondary device (for example, via a cable). In this case, there is no need to restrict access, but rather permanent access is granted, with the token serving only as an activation code.
Both scenarios are used in practice. Whenever possible, the latter should be applied.
#Token vs. PIN
The only similarity is in their composition - both the token and the PIN code consist of alphanumeric characters. The key difference lies in the fact that the token does not transmit sensitive information and the disclosure of its content cannot cause too much hassle. On the other hand, the PIN code contains sensitive information and the disclosure of its content can cause irreparable damage.
It should also be noted that a token is most often used for one-time use, while a PIN code is usually used multiple times. This is another reason why a token is considered a more secure way to transmit information or activate a service than a PIN code.