Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

8/27/2010
02:01 PM
50%
50%

Four Best Practices For Tokenization

Going beyond Visa's best practices guide

With Visa releasing its tokenization best practices guide earlier this summer, security professionals and encryption vendors have debated the strengths and weaknesses of the guide. As one of the most debated topics in encryption-land, tokenization still has a long way to go before it achieves any kind of true standardization of best practices.

Even so, security experts say there are some practices that you can adopt that go beyond Visa's recommendations (PDF). While there is room for discussion about any one of these tokenization suggestions, experts recommend these tips to achieve the best possible security posture for data protection:

1. Randomly Generate Tokens

According to many security experts, the only way to guarantee that tokens are not able to be reversed is if they are generated randomly.

"If the output is not generated by a mathematical function applied to the input, it cannot be reversed to regenerate the original PAN data," Adrian Lane, analyst for Securosis, recently on the topic. "The only way to discover PAN data from a real token is a (reverse) lookup in the token server database. Random tokens are simple to generate, and the size and data type constraints are trivial. This should be the default, as most firms should neither need or want PAN data retrievable from the token."

2. Avoid Homegrown Solutions

While tokenization may seem simple on its face, Ulf Mattsson, chief technology officer for Protegrity warns that "there are more ways to go wrong with tokenization that traditional encryption."

"It's a little bit of rocket science because first you need to generate the tokens, manage the tokens in a good way, protect your token server in a good way and then on top of that you need a normal encryption system with key management that should be compliant that's protecting your token server," Mattsson says.

Mattsson has heard a number of horror stories about homegrown deployments of tokenization that were easily cracked due to the reversibility of the tokens and lack of security around the system in general. "There are homegrown systems out there that are called tokenization and they do not meet the security level of tokenization; in many cases they don't even meet basic security levels for encryption," he says.

3. Protect the Token Server

The Visa standards did start out with a note about the importance of network segregation and keeping tokenization systems PCI compliant, but the importance of securing the token server bears repeating. If organizations fail to secure this server, it can put the whole balance of the token system at risk and render an organization's tokenization investments moot if it is not properly secured.

"In the corner somewhere you have to have a token server which can reverse the (tokenization process)," Mattson. "That server will need to be encrypted with traditional key management and strong encryption. If it's PCI data that it holds, the server needs to be PCI-compliant."

4. Create An Encryption Ecosystem

Over the last year or so, experts have debated whether an organization should choose between end-to-end encryption or tokenization. Many within the card processing world, however, believe that organizations shouldn't be choosing between the two. Each type of technology serves a different purpose: The strength of tokenization is its irreversibility and its ability to play nice with the database infrastructure. Meanwhile, end-to-end encryption helps fill in the gaps as the cardholder data and PANs travel across the rest of the IT infrastructure.

"We believe that tokenization is a prudent strategy when used in conjunction with end-to-end encryption," says Steven Elefant, CIO for Heartland Heartland Payment Systems, which expects to provide tokenization services to its customers later this year as a complement to the encryption services it announced to its customers last fall.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
catherinegoble
50%
50%
catherinegoble,
User Rank: Apprentice
9/23/2020 | 10:58:25 PM
Tokenization of Alternative Assets
When we think about tokenization of assets the first thing that comes to our mind is the real estate sector. Indeed the biggest interest we are experiencing at DigiShares comes from this field. https://www.digishares.io/alternativeassets
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
US Counterintelligence Director & Fmr. Europol Leader Talk Election Security
Kelly Sheridan, Staff Editor, Dark Reading,  10/16/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-26895
PUBLISHED: 2020-10-21
Prior to 0.10.0-beta, LND (Lightning Network Daemon) would have accepted a counterparty high-S signature and broadcast tx-relay invalid local commitment/HTLC transactions. This can be exploited by any peer with an open channel regardless of the victim situation (e.g., routing node, payment-receiver,...
CVE-2020-26896
PUBLISHED: 2020-10-21
Prior to 0.11.0-beta, LND (Lightning Network Daemon) had a vulnerability in its invoice database. While claiming on-chain a received HTLC output, it didn't verify that the corresponding outgoing off-chain HTLC was already settled before releasing the preimage. In the case of a hash-and-amount collis...
CVE-2020-5790
PUBLISHED: 2020-10-20
Cross-site request forgery in Nagios XI 5.7.3 allows a remote attacker to perform sensitive application actions by tricking legitimate users into clicking a crafted link.
CVE-2020-5791
PUBLISHED: 2020-10-20
Improper neutralization of special elements used in an OS command in Nagios XI 5.7.3 allows a remote, authenticated admin user to execute operating system commands with the privileges of the apache user.
CVE-2020-5792
PUBLISHED: 2020-10-20
Improper neutralization of argument delimiters in a command in Nagios XI 5.7.3 allows a remote, authenticated admin user to write to arbitrary files and ultimately execute code with the privileges of the apache user.