Tokenization vs. Encryption: Which is Better for Your Business?
Written by TokenEx
Finding the right security technology for your company's data can be difficult. There are myriad options and a lot of industry terms and jargon thrown around without much reliable information with which to make a smart business decision. To assist with this process, we're going to review a couple of popular technologies that are often compared to each other: tokenization vs. encryption.
If you have any experience with data security, you’re probably already familiar with the concept of encryption.
What is Data Encryption?
Data encryption is the term for the process of using an encryption key to temporarily alter data, rendering it unreadable to parties who are not in possession of the decryption key. Encryption is the most common method of keeping sensitive information secure, and thousands of businesses around the globe use encryption to protect cardholder data (CHD), payment card information (PCI), personal data, personally identifiable information (PII), nonpublic personal information (NPI), financial account numbers, and many other types of sensitive data. However, encryption has some drawbacks, especially when compared with tokenization. Below, you will find a table that compares tokenization vs. encryption, detailing the strengths, weaknesses, and applications of each.
Tokenization vs. Encryption
Tokenization vs. encryption explains how these specific security technologies differ from each other when it comes to protecting cloud data. The primary difference is the method of security each utilizes. In short, tokenization uses a token to protect the data, whereas encryption uses a key. What that means is that tokenization swaps sensitive data for an irreversible, nonsensitive placeholder (token) and securely stores the original, sensitive data outside of its original environment, and encryption encodes the content of a data element where it resides with a key shared between whoever is encrypting the data and whoever need to decrypt it.
To access the original data, a tokenization solution exchanges the token for the sensitive data, and an encryption solution decodes the encrypted data to reveal its sensitive form. Both have valuable security applications when it comes to data protection and safeguarding data in transit and at rest. Encryption is great for unstructured fields or databases of information that aren't exchanged frequently or stored in multiple systems. Tokenization is ideal for structured data, such as Social Security and credit card numbers, that need to be kept on file to verify identities and to be easily accessible for future use, such as financial transactions and online purchases.
Learn more about the differences between tokenization and encryption by downloading TokenEx's ebook.
Tokenization vs. Encryption: Can They Be Broken?
The first, and by far the biggest, problem with data encryption is that it is reversible. By design, encrypted data can be returned to its original, unencrypted form—which means any individual or entity that has access to the key can use it to uncover the sensitive data the encryption is meant to protect. The strength of the encryption is based on its key, or the algorithm it uses to secure the data. In application, a more complex algorithm will create a stronger form of encryption that is more difficult to crack. Conversely, a simpler one will be easier to solve.
However, all encryption is eventually breakable—it’s simply a matter of how strong your algorithm is versus how powerful the computers are of the malicious actors that are attempting to break it. In this sense, encryption isn’t really data protection. Rather, it’s data obfuscation. In other words, instead of focusing on preventing outside parties from accessing the data, the primary aim of encryption is to make it much more difficult, though not impossible, to find the real information hidden within the encrypted data if that encrypted data becomes exposed.
Tokenization vs. Encryption: Compliance Concerns
Another problem with encryption is that, because it is reversible, the PCI Security Standards Council and other similar governing entities tasked with enforcing regulatory compliance still view encrypted data as sensitive data. This might seem counterintuitive, but even though encryption is widely recognized as an effective security technology, because it is reversible and can be returned to its original form, the Payment Card Industry Data Security Standard (PCI DSS) considers it to be insecure, which means it requires additional protective measures to adequately safeguard it in compliance with the requirements of the PCI DSS. As a result, organizations can expect significant capital expenditure in purchasing additional solutions to sufficiently protect this encrypted data, which is compounded by the significant expenses involved with meeting compliance obligations for other areas of a business.
On top of all that, if your business is noncompliant due to encryption or your encryption algorithm proves vulnerable—allowing your organization's and your customers' sensitive data to fall into the wrong hands—the subsequent fines can crush your company. Fines for PCI violations, for example, are rumored to be in the neighborhood of $25,000 a month for noncompliance alone, regardless of whether a breach occurs. If your environment and the data stored inside does become compromised, it can cost approximately $150 per record lost, according to IBM Security and the Ponemon Institute.
Tokenization, on the other hand, has none of these problems. That’s because tokenization doesn’t rely on encryption to protect data. Rather than securing information through a breakable algorithm, a tokenization system replaces sensitive data with randomly generated data mapped one-to-one within your environment. The original information is not contained within the token, and thus, the token cannot be reversed into the original, sensitive data. The token is simply a placeholder, and it has no inherent value. Meanwhile, the real, sensitive information is stored in a different location entirely, such as a secured offsite platform. That means that sensitive customer data does not enter or reside within your internal systems at any time, which significantly reduces the scope of regulatory compliance as well as virtually eliminates the risk of data theft.
So, if a hacker should manage to break into your environment and steal your tokens, they’ve really stolen nothing of value. Tokens cannot be used for fraudulent purposes. To exchange a token for the original, sensitive data, those in possession of the tokens face additional security checks and requirements to verify their identity. Furthermore, as we mentioned previously, tokens can’t be reversed independently of the secure platform or software by breaking an algorithm.
Again, because tokens do not contain any of the original, sensitive data—they only serve as representatives of it—they aren’t subject to the same issues that encrypted or otherwise "unsecure" information would have with compliance from PCI or other regulations for data security. As a result, costly compliance obligations are reduced, and if implemented properly, there will be no fines or breach notifications to worry about in the event that your environment becomes compromised.
Tokenization vs. Encryption: Tokens Explained
Another benefit of tokenization vs. encryption is the business utility and agility that tokens offer. Customizable token schemes, such as length- and format-preserving tokens, can retain portions of the sensitive data to preserve much of its original operational value. For example, many ecommerce platforms and other online retailers use credit card tokenization to store customer payment data for future use. This allows customers to perform multiple, repeated, or recurring transactions without needing to enter their payment information for each individual purchase, which results in quicker, easier transactions and an overall improved user experience. To enable this, merchants often mask a portion of the data to protect it but reveal other parts to help users identify which credit card is being charged without requiring the data to be detokenized first. The goal here is again greater convenience for a better user experience. Here’s an example: an ANTOKENfour scheme.
This token scheme is commonly used for credit card data such as primary account numbers (PANs) and other payment card information (PCI). It tokenizes the original, sensitive data to return an alphanumeric, length-preserving token that retains the original last four digits of the input data—in this case, the credit card number. This is sometimes displayed on receipts as:
•••• •••• •••• 4242
Similarly, custom token schemes can preserve protected data for analytics purposes without altering it additionally or exposing it to unnecessary risk. This allows marketing departments, operations managers, and other internal entities to continue to use sensitive data for their business purposes. In many cases, especially with encryption, this functionality is considered an either-or absolute, not a sliding scale, where useless=secure and useful=unsecure. Although encryption does offer format-preserving forms, it does not share the flexibility of its tokenized counterpart.