That is a gap that tokenization is meant to fill. The technology works behind the scenes of a digital transaction: Customers still put in their card number, but software then transforms that information into a one-time token — a randomly generated code — that is sent through the payment-processing chain. Thieves who intercept the code can do little with it without the means to unscramble the token.
This article in The New York Times blog is another example of fallacy of tokenization. This description is untrue. Tokenization does not work this way. In order to get authorization for the credit card charge, the point of sale system still needs to send the full card data (the content of magnetic track 1 or 2) to the payment processing server. Such data cannot be just "transformed into a one-time randomly generated token" because the server system must be able to recognize and process it. So the card data should be encrypted using another technology called point-to-point encryption (P2PE) which is different from tokenization. Only after the card data is decrypted and processed at the payment processor's data center, it can be tokenized using the method described above, and the resulting token can be returned to the point of sale system. There are P2PE systems that are able to produce the format-preserving encryption so the resulting encrypted data looks similar to the original input so maybe that's created a confusion. But in any case, the data produced by such system is not "randomly generated", and it's not a token, and it's done in hardware rather than software, and the system is called P2PE and not tokenization. Unfortunately, such misunderstanding and overestimation of tokenization is very common perception.
1 Comment
Trustmark National Bank and Green Bank, N.A. filed a class action lawsuit on March 24 against Target and Trustwave, which is Target’s quality security assessor (QSA), over the recent card data breach. Trustwave is a big security firm, and QSA (Qualified Security Assessor) is one of its main lines of business. But the lawsuit contains some questionable interpretations of the Payment Card Industry Data Security Standard (PCI DSS). The lawsuit claims: “Under PCI DSS, merchants like Target are required to encrypt customer names, payment card numbers, expiration dates, CVV codes (Card Verification Value codes), and PIN numbers (“Track Data”).” This is wrong. PCI DSS requires encryption only for sensitive cardholder data stored on hard drives or transmitted over public networks (like the Internet). Data in computer memory and data on local networks can remain unencrypted, which is allowed by PCI DSS, and such an environment would be still PCI compliant. The lawsuit also states, “The fact that the three-digit CVV security codes were compromised shows they were being stored.” This is wrong for the same reason. The fact that CVV codes were compromised does not mean they were being stored. They could be stolen either from memory using RAM scraping techniques or from the local network using network sniffers (there are many other methods, but those two are the most common). And as I said before, PCI DSS does not require encryption of sensitive cardholder data (including CVV) in memory or on a local network. Those are only two short statements from the large lawsuit, but they show that even if the merchant (Target in this case, but it can be anyone else) is PCI compliant, it is not safe from a security breach. In addition, or maybe even instead of PCI DSS measures, merchants and their payment processors should implement special security technologies such as P2PE (point-to-point encryption), which protects the sensitive cardholder data from the moment it enters the card reader and makes it virtually inaccessible to hackers. One thing to keep in mind here is that this lawsuit could set a precedent (if Trustwave is found liable), where the PCI security auditor is responsible for card data breaches even when the company they are auditing is fully in compliance with the PCI DSS. ![]() My article in VentureBeat: Lawsuit against Target and Trustwave gets the security standard all wrong. This lawsuit could set a precedent, where the PCI security auditor is responsible for card data breaches even when the company they are auditing is fully in compliance with the PCI DSS. Interesting view on U.S. EMV migration. 1. EMV solves the wrong problem – and an old one at that. I agree with #1, #2, and #4. As a technical guy, I don't care who pays for it (#3): eventually, it's us - consumers - who pay for everything. I disagree with #5: ACH and bank transfer threats (and solutions) are completely different from merchants' payments security problems. I would agree with #6 but I don't see "real opportunity": there is no mature payment technology available today that could become a real alternative to EMV. Crypto-payments (Bitcoin & Co.) is very promising trend but based on recent series of failures it is still on early proof of concept stages. And there is no single mobile payments technology that is secure enough to be accepted by mainstream consumers. Consumer Alert: Credit Card Information As a payment security expert, I get a lot of questions from people about new payment technologies. Are merchants likely to accept them? How secure are they? A couple of recent startups in this space, Loop and Coin, have been generating quite a few of those questions, and my review of them shows some concerning vulnerabilities. Loop and Coin are just two examples of mobile payments startups that try to bring an invention to market by marrying their new technology to an existing payment card system. The reason is simple: Their tech is more likely be accepted by the mainstream if merchants can reuse their existing payment hardware and software. Both Loop and Coin are trying to keep alive the dying magnetic stripe payment system. However, they have another important “feature” in common: By replacing the original plastic cards with digital ersatz, they unintentionally simplify the flow of the stolen credit card data. Loop The core know-how of Loop is transforming the traditional magnetic stripe reader device (MSR), which merchants use to accept the magnetic credit and debit cards, into the contactless reader. The powerful magnetic field is generated by the mobile payment device (instead of the payment card’s magnetic stripe), so the card data can be transmitted wirelessly to the same reader. Although this technique is very interesting from a technical point of view, there are several potential issues with accepting Loop as a mainstream method of payment. First, there is no real innovation here. It’s just a combination of old technologies. Second, from a security point of view, it’s the same nightmare as existing credit cards. It can be even worse because all my cards are now stored in one place. And the card data is not protected when it is transmitted from the mobile device and throughout the system, just like with traditional plastic cards. Finally, Loop is less convenient than plastic cards, especially, with the fob required for iPhone. Instead of just swiping the card, I need to: hold both the fob and the phone, unlock the phone, find and start the app, select the card, then press the button on the phone and at the same time “swipe” the fob. Not to mention the fact that many card readers are deeply “hidden” inside the customer-facing hardware, such as a bank ATM or gas station’s fuel pump, and therefore cannot be reached by the Loop device. But most importantly, this system is dangerous to merchants, issuers, and acquirers because it simplifies the credit card fraud process. Hackers don’t need to make the physical plastics anymore – they just load the dump of stolen card data into the single device, and voilà! Loop’s developers say the app identifies the cardholder before the new card is added to the wallet, so it is impossible to add someone else’s card into your wallet. This “security control” is very weak, and anyone familiar with the design of magnetic payment cards can find a workaround. This protection measure is implemented by comparing the cardholder name, which is encoded on magnetic Track 1 of the credit or debit card, with the name on the Loop app account. A hacker who wants to enter and use the stolen track data can easily fake the name on the card and match it with the name on the Loop account because the cardholder name on the magnetic track is not protected by encryption or digital signature and can be changed to any combination of letters without affecting the payment approval process. Coin The idea of Coin is similar but more elegant: replacing several payment cards with a single card-like sophisticated device. The technology behind Coin is pretty impressive, but it raises exactly the same security concern as the Loop device. Normally, when carders want to use the stolen card data to make a purchase in a brick-and-mortar store, they need to produce the fake plastic card, which must look like a real credit card, and encode it with the stolen magnetic tracks. But with Coin, there is no need to produce a good looking physical plastic anymore. The stolen data can be encoded directly into the Coin device. Carders would have to overcome one obstacle: taking a picture of the real card so they can enter the new card information into Coin through the iPhone or Android app. But I think generating a realistic virtual image of a credit card (so it can be photographed instead of the real card) is cheaper than creating a physical counterfeited card, which requires special equipment such as a PVC printer, an embosser, a tipper, etc. I am sure that hackers, carders, and cashers will be among the first beta testers (and subsequently the most appreciative users) of such “innovative” technologies. More effective security controls — if they are feasible at all — must be designed for the mobile wallet apps that reuse the existing magnetic stripe technology. Interesting facts about Target attack which confirm my theory that PCI compliance alone is unable to protect merchants from card data breaches. Target was certified as meeting the standard for the payment card industry (PCI) in September 2013. Company officials say its information security staff now numbers more than 300 people. A three-year study by Verizon Enterprise Solutions (VZ) found that companies discover breaches through their own monitoring in only 31 percent of cases. For retailers, it’s 5 percent. Poring over computer logs, Target found FireEye’s alerts from Nov. 30 and more from Dec. 2, when hackers installed yet another version of the malware. Not only should those alarms have been impossible to miss, they went off early enough that the hackers hadn’t begun transmitting the stolen card data out of Target’s network. Even the company’s antivirus system, Symantec Endpoint Protection (SYMC), identified suspicious behavior over several days around Thanksgiving—pointing to the same server identified by the FireEye alerts. the intruders had gained access to the system by using stolen credentials from a third-party vendor. Sally Beauty confirmed this morning that 25,000 records of Track 2 have been stolen from their systems. As we previously stated on March 5th, our systems detected an unauthorized attempted intrusion into our Sally Beauty Supply LLC network. At the time of this discovery, we immediately engaged a top-tier forensics firm (Verizon) to investigate this security incident. As a result of this ongoing investigation, we have now discovered evidence that fewer than 25,000 records containing card-present (track 2) payment card data have been illegally accessed on our systems and we believe it may have been removed. Track 2 is one of two tracks of information encoded to the magnetic stripe of payment cards (either credit or debit). Track 2 contains information which is sufficient for hackers to create a fake duplicate card and use it for purchases in brick-and-mortar stores without any limitations. There are plenty of ways to steal Track 2 data from point-of-sale systems, even if they are PCI-compliant. Track 2 sample: ;4005554444444403=1512101000000012300? Track 2 key elements: 4005554444444403 - Cardholder's PAN (Primary Account Number) 1512 - Card's expiration date (December 2015) 123 - CVV (Card Verification Value) My interview by Cathleen McCarthy at CreditCards.com about recent breaches, payments with credit/debit cards, EMV migration, etc. ![]() I was interviewed about recent card data breaches and my book - Hacking Point of Sale. You can listen to the interview here. Thanks to ITS Partners, and personally - to Jacob Crawford (@jake_crawford91) for this interview and for the great quality of the podcast! |
Books
![]() ![]() ![]() Recent Posts
Categories
All
Archives
January 2025
|