Comments for Storefrontbacktalk http://www.storefrontbacktalk.com Techniques, Tools and Tirades about Retail Technology and E-Commerce Sat, 17 May 2008 07:50:34 +0000 http://wordpress.org/?v=2.3.3 Comment on Opposition To Tokenization A Lot More Than Token by Steve Sommers http://www.storefrontbacktalk.com/securityfraud/opposition-to-tokenization-a-lot-more-than-token/#comment-30058 Steve Sommers Fri, 16 May 2008 16:53:12 +0000 http://www.storefrontbacktalk.com/securityfraud/opposition-to-tokenization-a-lot-more-than-token/#comment-30058 I agree that properly implemented public key encryption or PKI can be one of the best forms of encryption for card holder data (CHD) but there are two issues with this. To get the most benefit out of public key encryption in a point-of-sale (POS) environment, the POS cannot have access to the private key portion of the two keys. The problem is that many payment transaction requests to the banks and processors require two steps: an authorization step and a later settlement step. Both these steps require the CHD and therefore the POS would need access to the private key decrypt the CHD to perform the second step. This negates the biggest advantage of PKI. The second issue is that PKI is probably the most expensive form of encryption to properly implement. By expensive, I’m not referring to licensing costs because there is free code and libraries available. Instead I’m referring to the infrastructure changes required to support the physical and logical separation of roles between the system that house the public and private keys, database changes required to support the storing the encrypted data, all the access controls required for the keys, the annual rekeying of the data if it is archived, PKI is much more CPU intensive than single key encryption techniques (Blowfish, AES, 3DES, etc.), etc. etc. Many of these costs are not PKI specific, but instead are costs associated with housing encrypted CHD. Now your whole argument is assuming the “token” = “hash” or “encrypted CHD” and that a hacker, if provided the tokenization algorithm, could de-hash (if that is a word) or decrypt the data. Being the inventor of the term “tokenization,” the definition you are using is incorrect. Shift4 invented the term tokenization, not the concept. The concept has been around long before PCI, CHD or even computers. A token is simply an object or in this case, a piece of data that symbolizes or is used to reference another piece of data – the CHD. A properly implemented token is not related in any way to the original data other than by reference. In law enforcement, case numbers are assigned to cases; most of the time these numbers are simply sequential numbers. The case number itself is a token. There is no way to decrypt the case number to determine the contents of the case. This is why I say we invented the term, not the concept. Now there are vendors out there that are applying the same definition you did to the term tokenization. Against these implementations, your argument is very valid. But in our minds, these are not tokenization, or at least not properly implemented tokenization solutions – these we classify as hashing or encryption solutions. Lastly leave you with a challenge. Below are test card numbers and their associated tokens in my testing database. I urge you or anyone to devise an attack on the tokens that reveal the corresponding card number: AX 373400000000001 0001d7byvlgqmdzf AX 373400000000001 0001713nfgjb20yt AX 373400000000001 0001j4nr6pjb2js3 MC 5400000000000005 0005sf9fmmjb2yr3 MC 5400000000000005 0005hw29x2jb2j9z MC 5400000000000005 0005ylmsg9jb2xnt VS 4222222222222 2222dxdh61lvq68l VS 4222222222222 2222f9nk2llvq92x VS 4222222222222 2222y9wswygqm278 If you can crack this, I’ll buy your algorithm because you would have figured out a way to predict both future and past random events – the implications of which would be mind blowing (not to mention a great money maker ;-). --Steve I agree that properly implemented public key encryption or PKI can be one of the best forms of encryption for card holder data (CHD) but there are two issues with this. To get the most benefit out of public key encryption in a point-of-sale (POS) environment, the POS cannot have access to the private key portion of the two keys. The problem is that many payment transaction requests to the banks and processors require two steps: an authorization step and a later settlement step. Both these steps require the CHD and therefore the POS would need access to the private key decrypt the CHD to perform the second step. This negates the biggest advantage of PKI. The second issue is that PKI is probably the most expensive form of encryption to properly implement. By expensive, I’m not referring to licensing costs because there is free code and libraries available. Instead I’m referring to the infrastructure changes required to support the physical and logical separation of roles between the system that house the public and private keys, database changes required to support the storing the encrypted data, all the access controls required for the keys, the annual rekeying of the data if it is archived, PKI is much more CPU intensive than single key encryption techniques (Blowfish, AES, 3DES, etc.), etc. etc. Many of these costs are not PKI specific, but instead are costs associated with housing encrypted CHD.

Now your whole argument is assuming the “token” = “hash” or “encrypted CHD” and that a hacker, if provided the tokenization algorithm, could de-hash (if that is a word) or decrypt the data. Being the inventor of the term “tokenization,” the definition you are using is incorrect. Shift4 invented the term tokenization, not the concept. The concept has been around long before PCI, CHD or even computers. A token is simply an object or in this case, a piece of data that symbolizes or is used to reference another piece of data – the CHD. A properly implemented token is not related in any way to the original data other than by reference. In law enforcement, case numbers are assigned to cases; most of the time these numbers are simply sequential numbers. The case number itself is a token. There is no way to decrypt the case number to determine the contents of the case. This is why I say we invented the term, not the concept.

Now there are vendors out there that are applying the same definition you did to the term tokenization. Against these implementations, your argument is very valid. But in our minds, these are not tokenization, or at least not properly implemented tokenization solutions – these we classify as hashing or encryption solutions.

Lastly leave you with a challenge. Below are test card numbers and their associated tokens in my testing database. I urge you or anyone to devise an attack on the tokens that reveal the corresponding card number:

AX 373400000000001 0001d7byvlgqmdzf
AX 373400000000001 0001713nfgjb20yt
AX 373400000000001 0001j4nr6pjb2js3
MC 5400000000000005 0005sf9fmmjb2yr3
MC 5400000000000005 0005hw29×2jb2j9z
MC 5400000000000005 0005ylmsg9jb2xnt
VS 4222222222222 2222dxdh61lvq68l
VS 4222222222222 2222f9nk2llvq92x
VS 4222222222222 2222y9wswygqm278

If you can crack this, I’ll buy your algorithm because you would have figured out a way to predict both future and past random events – the implications of which would be mind blowing (not to mention a great money maker ;-).

–Steve

]]> Comment on Dave & Buster’s Data Breach Indictment: Apps Crash For The Bad Guys, Too by Evan Schuman http://www.storefrontbacktalk.com/securityfraud/dave-busters-data-breach-indictment-apps-crash-for-the-bad-guys-too/#comment-30048 Evan Schuman Fri, 16 May 2008 14:56:58 +0000 http://www.storefrontbacktalk.com/securityfraud/dave-busters-data-breach-indictment-apps-crash-for-the-bad-guys-too/#comment-30048 Editor's Note: That's a nice sentiment, but I cynically doubt it would do any good. It's like increasing the penalties for illegal narcotic distribution. There is SO much money to be made with these schemes--and the chances of being caught are so slight--that these punishments won't do much good. The deterrence of any punishment only exists if the one you're trying to deter has any reasonable belief they'll get caught and convicted. These cyber thieves are generally confident, cocky and quite careful. Reality aside, they are likely to BELIEVE they'll never get caught. Therefore, no punishment will likely any impact. I hope I'm wrong, though. Editor’s Note: That’s a nice sentiment, but I cynically doubt it would do any good. It’s like increasing the penalties for illegal narcotic distribution. There is SO much money to be made with these schemes–and the chances of being caught are so slight–that these punishments won’t do much good.
The deterrence of any punishment only exists if the one you’re trying to deter has any reasonable belief they’ll get caught and convicted.
These cyber thieves are generally confident, cocky and quite careful. Reality aside, they are likely to BELIEVE they’ll never get caught. Therefore, no punishment will likely any impact.
I hope I’m wrong, though.

]]> Comment on Dave & Buster’s Data Breach Indictment: Apps Crash For The Bad Guys, Too by Biff Matthews http://www.storefrontbacktalk.com/securityfraud/dave-busters-data-breach-indictment-apps-crash-for-the-bad-guys-too/#comment-30047 Biff Matthews Fri, 16 May 2008 14:37:56 +0000 http://www.storefrontbacktalk.com/securityfraud/dave-busters-data-breach-indictment-apps-crash-for-the-bad-guys-too/#comment-30047 Finally! As Paul Harvey said, now for the rest of the story, which is yet to unfold, taking years, is what happens to these cyber criminals. Swift and meaningful punishment is necessary to send a message to those considering a life of cyber crime. Finally! As Paul Harvey said, now for the rest of the story, which is yet to unfold, taking years, is what happens to these cyber criminals. Swift and meaningful punishment is necessary to send a message to those considering a life of cyber crime.

]]> Comment on Applying Internet Security To RFID by A Reader http://www.storefrontbacktalk.com/securityfraud/applying-internet-security-to-rfid/#comment-30041 A Reader Fri, 16 May 2008 12:29:35 +0000 http://www.storefrontbacktalk.com/securityfraud/applying-internet-security-to-rfid/#comment-30041 This is more important than most retailers (and system purveyors) realize. Hackers are already using their own barcodes and credit card magnetic stripes to perform attacks against various unattended kiosks and systems. At the most recent Chaos Communication Congress in Berlin, one of the presenters gave a talk on implementing various attack methods, including SQL injection attacks, XPath injection attacks, and fuzzing attacks, all using custom barcodes against self-checkout DVD rental systems and other systems where the customer is providing the input data. The video is very much worth watching, and is available by torrent here: http://outpost.h3q.com/fnord/24c3-torrents/24c3-2273-en-toying_with_barcodes.mp4.torrent RFID would be the safest of all machine readable technologies for a hacker to attack, since even a watchful human monitor could not tell the difference between which invisible tags are legitimate, and which ones are malicious. This is more important than most retailers (and system purveyors) realize. Hackers are already using their own barcodes and credit card magnetic stripes to perform attacks against various unattended kiosks and systems.

At the most recent Chaos Communication Congress in Berlin, one of the presenters gave a talk on implementing various attack methods, including SQL injection attacks, XPath injection attacks, and fuzzing attacks, all using custom barcodes against self-checkout DVD rental systems and other systems where the customer is providing the input data. The video is very much worth watching, and is available by torrent here: http://outpost.h3q.com/fnord/24c3-torrents/24c3-2273-en-toying_with_barcodes.mp4.torrent

RFID would be the safest of all machine readable technologies for a hacker to attack, since even a watchful human monitor could not tell the difference between which invisible tags are legitimate, and which ones are malicious.

]]> Comment on Opposition To Tokenization A Lot More Than Token by A Reader http://www.storefrontbacktalk.com/securityfraud/opposition-to-tokenization-a-lot-more-than-token/#comment-30020 A Reader Fri, 16 May 2008 05:06:56 +0000 http://www.storefrontbacktalk.com/securityfraud/opposition-to-tokenization-a-lot-more-than-token/#comment-30020 As I've said before, tokens are much less secure than properly implemented public key based encryption. Assuming the tokens are generated based on the account number, such as with a cryptographic hash, then the tokens are subject to a simple dictionary attack. If an attacker can freely access the tokenization routine, all the attacker has to do is feed every possible account number into the tokenizer until a match pops out. The attacker does not have to know the technical details of the hash routine (SHA-1 vs SHA-256 or MD5), all they need is access to it. [ I've personally written such an attack against a tokenizer (that was SHA-1 based) and run it from my own desktop PC, and I recover whole account numbers in an average of four seconds. (I fixed a bug that previously kept it spinning for up to 40 seconds.) So I know first-hand that account numbers can be recovered from tokens. ] So instead of protecting secret keys, you now have to protect this secret tokenization algorithm, in every single place it exists -- registers, PIN pads, kiosks, web servers, etc. If you were unaware of this attack, you might not even know that you should be protecting it. On the other hand, public key encryption is extremely secure, and key secrecy in the field is a non-issue. Public keys are intended to be distributed publicly -- that's the point. It's the private keys that must be carefully held, but since they are used only at the decryption point they can be securely stored in a single, hardened, dedicated hardware decryption appliance (such as an Atalla box or an IBM mainframe with a cryptographic coprocessor.) Sure, there are still points to harden in the stores, and a PCI audit is still a useful tool. File Integrity Monitoring can help insure that encryption routines are not tampered with, and that rogue software isn't poking about where it shouldn't. Constant patching of the operating system is needed to ensure that the encryption routines remain secure (the cryptographic PRNG is a critical component for security in a public-key protocol.) That said, encryption is very easy to get wrong, and neither encryption algorithm design nor encryption protocol design should be left in the hands of amateur cryptographers. Any security system like this should be subjected to a rigorous review by several unbiased professional cryptanalysts, and should be based on sound designs with long track records in the cryptographic field. I don't mean to say that tokenization is not "better than nothing". Obviously, recovery of the account numbers from tokens requires technical knowledge of the systems, and certain levels of access. But an insider could certainly figure this out, and without adequate monitoring and other mitigating controls they could be recovering accounts from tokens today. As I’ve said before, tokens are much less secure than properly implemented public key based encryption.

Assuming the tokens are generated based on the account number, such as with a cryptographic hash, then the tokens are subject to a simple dictionary attack. If an attacker can freely access the tokenization routine, all the attacker has to do is feed every possible account number into the tokenizer until a match pops out. The attacker does not have to know the technical details of the hash routine (SHA-1 vs SHA-256 or MD5), all they need is access to it.

[ I’ve personally written such an attack against a tokenizer (that was SHA-1 based) and run it from my own desktop PC, and I recover whole account numbers in an average of four seconds. (I fixed a bug that previously kept it spinning for up to 40 seconds.) So I know first-hand that account numbers can be recovered from tokens. ]

So instead of protecting secret keys, you now have to protect this secret tokenization algorithm, in every single place it exists — registers, PIN pads, kiosks, web servers, etc. If you were unaware of this attack, you might not even know that you should be protecting it.

On the other hand, public key encryption is extremely secure, and key secrecy in the field is a non-issue. Public keys are intended to be distributed publicly — that’s the point. It’s the private keys that must be carefully held, but since they are used only at the decryption point they can be securely stored in a single, hardened, dedicated hardware decryption appliance (such as an Atalla box or an IBM mainframe with a cryptographic coprocessor.)

Sure, there are still points to harden in the stores, and a PCI audit is still a useful tool. File Integrity Monitoring can help insure that encryption routines are not tampered with, and that rogue software isn’t poking about where it shouldn’t. Constant patching of the operating system is needed to ensure that the encryption routines remain secure (the cryptographic PRNG is a critical component for security in a public-key protocol.)

That said, encryption is very easy to get wrong, and neither encryption algorithm design nor encryption protocol design should be left in the hands of amateur cryptographers. Any security system like this should be subjected to a rigorous review by several unbiased professional cryptanalysts, and should be based on sound designs with long track records in the cryptographic field.

I don’t mean to say that tokenization is not “better than nothing”. Obviously, recovery of the account numbers from tokens requires technical knowledge of the systems, and certain levels of access. But an insider could certainly figure this out, and without adequate monitoring and other mitigating controls they could be recovering accounts from tokens today.

]]> Comment on The Data Breach Librarian Actually Gets Paid by Roger Dawson http://www.storefrontbacktalk.com/securityfraud/the-data-breach-librarian-actually-gets-paid/#comment-29939 Roger Dawson Wed, 14 May 2008 22:54:49 +0000 http://www.storefrontbacktalk.com/securityfraud/the-data-breach-librarian-actually-gets-paid/#comment-29939 Most excellent! The guy got paid. Where did all the folks who said this wouldn't happen go? Most excellent! The guy got paid. Where did all the folks who said this wouldn’t happen go?

]]> Comment on The Home Depot Self-Checkout Machine That Wouldn’t Take “No” For An Answer by John Roberts http://www.storefrontbacktalk.com/e-commerce/the-home-depot-self-checkout-machine-that-wouldnt-take-no-for-an-answer/#comment-29862 John Roberts Tue, 13 May 2008 16:56:26 +0000 http://www.storefrontbacktalk.com/e-commerce/the-home-depot-self-checkout-machine-that-wouldnt-take-no-for-an-answer/#comment-29862 Putting a survey on a self checkout system slows down the transaction. That's an anti-service in my opinion. Even if they only do it off peak hours, it's not an excuse to impact customers simply because of when they choose to shop. I've also found several security issues with their system including putting an item on the scale prior to pressing start or starting of scanning. The item will not be detected and the cashiers misses it completely because no alarm is raised. I tried to tell them it this was happening, but they ignored me. Guess it's a free item for those that have figured it out. Putting a survey on a self checkout system slows down the transaction. That’s an anti-service in my opinion. Even if they only do it off peak hours, it’s not an excuse to impact customers simply because of when they choose to shop. I’ve also found several security issues with their system including putting an item on the scale prior to pressing start or starting of scanning. The item will not be detected and the cashiers misses it completely because no alarm is raised. I tried to tell them it this was happening, but they ignored me. Guess it’s a free item for those that have figured it out.

]]> Comment on Opposition To Tokenization A Lot More Than Token by Steve Sommers http://www.storefrontbacktalk.com/securityfraud/opposition-to-tokenization-a-lot-more-than-token/#comment-29822 Steve Sommers Mon, 12 May 2008 21:48:06 +0000 http://www.storefrontbacktalk.com/securityfraud/opposition-to-tokenization-a-lot-more-than-token/#comment-29822 Dave, I knew that was what you were doing and your points are issues and concerns that we have already encountered. All the points are valid concerns for merchants, as they should be. I was just conveying how we counter the opposition. Keep doing what you do. I would rather have someone like you point out the various issues that can arise and address them than convey a grass is always green message. I equate the later to a sales brochure. Dave,

I knew that was what you were doing and your points are issues and concerns that we have already encountered. All the points are valid concerns for merchants, as they should be. I was just conveying how we counter the opposition. Keep doing what you do. I would rather have someone like you point out the various issues that can arise and address them than convey a grass is always green message. I equate the later to a sales brochure.

]]> Comment on Opposition To Tokenization A Lot More Than Token by David Taylor http://www.storefrontbacktalk.com/securityfraud/opposition-to-tokenization-a-lot-more-than-token/#comment-29819 David Taylor Mon, 12 May 2008 20:58:49 +0000 http://www.storefrontbacktalk.com/securityfraud/opposition-to-tokenization-a-lot-more-than-token/#comment-29819 Steven, Thanks a lot for the comments -- i believe they are longer than the original column, which appears to be a new record. The tone of the comments is exactly right. When I was doing the interviews for the www.PCIKnowledgeBase.com, these are the types of resistance I encountered as I was saying positive things about tokenization, along the lines of what I said in my Feb 8th column. In order to move the market forward, we have to be able to address each of these objections factually. The PCI Knowledge Base was founded on the principle of the free exchange of knowledge and experience. Storefront Backtalk promotes these same ideas, and I'm encouraged to take a position, even a controversial one, in order to promote discussion. I only wish more folks would take the time to present the issues and the facts as you have done. Thanks, Dave Taylor Founder, PCI Knowledge Base David.Taylor@KnowPCI.com Steven,
Thanks a lot for the comments — i believe they are longer than the original column, which appears to be a new record.
The tone of the comments is exactly right. When I was doing the interviews for the http://www.PCIKnowledgeBase.com, these are the types of resistance I encountered as I was saying positive things about tokenization, along the lines of what I said in my Feb 8th column.

In order to move the market forward, we have to be able to address each of these objections factually.
The PCI Knowledge Base was founded on the principle of the free exchange of knowledge and experience.

Storefront Backtalk promotes these same ideas, and I’m encouraged to take a position, even a controversial one, in order to promote discussion. I only wish more folks would take the time to present the issues and the facts as you have done.
Thanks, Dave Taylor
Founder, PCI Knowledge Base
David.Taylor@KnowPCI.com

]]> Comment on Self-Checkout Psychology: Losing The Customer’s Trust by novelgirl http://www.storefrontbacktalk.com/payment-systems/self-checkout-psychology-losing-the-customers-trust/#comment-29817 novelgirl Mon, 12 May 2008 20:20:27 +0000 http://www.storefrontbacktalk.com/payment-systems/self-checkout-psychology-losing-the-customers-trust/#comment-29817 Until they become easier to use/ have less glitches, I think most customers will prefer a live cashier. I worked in a grocery store for five years, many of those with a scanner check out, and still have problems maneuvering self-checkouts. Until they become easier to use/ have less glitches, I think most customers will prefer a live cashier.
I worked in a grocery store for five years, many of those with a scanner check out, and still have problems maneuvering self-checkouts.

]]>