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.

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.

A tokenized system is considered a safe harbor for confidential data. Even if such a system were to face a potential data breach, there is no valuable information to intercept or steal, as the sensitive data has already been tokenized and transferred to a more secure destination.

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. However, the token does not contain any personal or sensitive data, so 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. However, the token does not contain any personal or sensitive data, so reprogramming it would not compromise anyone's privacy or data security.

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 higher.

Regardless of the fact that the token does not contain confidential information and that the mere disclosure of its contents does not cause problems, 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. Therefore, it is best to encrypt the token just before it is transmitted, either online or from one device to another, and thus protect its content, as if it were a message with sensitive content. The combination of DCCL technology and RSA key pair generation allows us to effectively implement this idea. The solution is to use the token only once, which eliminates the possibility of such misuse. Since this is not always possible, the server provider must take appropriate precautions and clearly inform its users about it.

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 the 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 issue an access permit, whether temporary, limited or permanent, but subject to certain conditions. 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 into which the token is inserted is the seller's device.
• 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 into which the token is inserted is the seller's device.

Both scenarios are used in practice. Whenever possible, the latter should be applied.

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.

For more details on DCCL technology, please visit this page. For more details on how to encrypt data using DCCL, please visit this page. For more details on how to digitally sign a file using DCCL, please visit this page.

Licensing ChatLiner and the associated products based on Digital Chip Card Locker ("DCCL") technology costs $1200 per year. You can pay $300 quarterly, $600 half-yearly, or $1200 annually.

$300.00 USD / quarterly $600.00 USD / half-yearly $1200.00 USD / annually

Permission is hereby granted, free of charge, to any licensee who obtains a copy of the programming code available at https://soundsofsoftware.com/login.js and associated documentation to use it without restriction, including, without limitation, the rights to use, copy, modify and/or merge portions of the code or the code in its entirety in accordance with the terms of the Licensing Agreement.

By using this software platform (the "Software", or "ChatLiner") owned by VIDYPS 79 d.o.o. (the "Licensor"), you acknowledge and agree that the License Agreement sets out the business relationship between you and the Licensor. Visit this page for more information.