Encryption replaces sensitive data with a mathematically derived value which, ideally, can only be read by an authorized entity—machine or human—that has the same encryption keys that were used to create the value. That little lock icon on a browser’s URL line indicates that data, such as a payment account number (PAN), is encrypted as it flows between the browser and the online store. This level of security is now ubiquitous for financial web transactions and helps to ensure that no “man in the middle” can read the encrypted PAN and other information.
However, once the PAN reaches an online store’s web server it’s decrypted and used by the retail software to charge the customer’s account, setting off a series of interchanges among the merchant, payment processor, and card issuers. Often the merchant stores the card data to make it easy for customers to make another purchase, or to make recurring payments.
But how secure is the payment data when it is at rest in the databases and business systems? How many business systems are touching that card account number during processing, and are they all secure? When a merchant’s IT systems are breached by hackers, the database of customer PANs can be quickly siphoned off to the far corners of the dark web to be sold for fraudulent use, even if it’s encrypted. After all, encryption is just computer-driven mathematics, and all it takes is another powerful computer and clever software to decrypt it. That’s the basic weakness of encryption—it can be reverse engineered back to the original data. Encrypting data may make it temporarily secure while in transit, but once at rest in business systems, it is vulnerable to theft and decryption.
Another weak point in using only encryption to store sensitive data is that every person or business process needs to have access to the encryption keys to decrypt the data when ever it is used in a business process. This means the keys to the kingdom, so to speak, are available in multiple places and can be harvested right along with the data during a breach.
Let’s trace the same path using tokenization in addition to encryption. The first stage is the same, from browser to online store. But once the payment information is accepted to initiate the sales transaction, the data either remains encrypted or is immediately re-encrypted using different keys. With a tokenization solution integrated into the payment stream, the encrypted payment data is immediately sent to a secure data vault, where it is stored, and swapped with a mathematically unrelated token. The token is sent back to the merchant to use for additional processing and storage. The real PAN is sent on by the token provider to the payment processer of choice to be verified, charged, and the confirmation returned to the merchant to complete the transaction. Adding tokenization to the payment stream has four distinct advantages over using only encryption.
- The PAN is never accepted by the merchant in an unencrypted state.
- No version of the PAN is stored or transmitted by the merchant, only the token that represents it.
- Tokens stolen during a breach are completely useless to hackers as they cannot be reverse-engineered back to the original PAN.
- The keys to tokenization are stored in the secure cloud vault, out of the reach of hackers.
To understand why cloud data vaults are secure, read this article about TokenEx Secure Data Vaults.