Comments on: Fun with ATM Skimmers, Part III http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/ In-depth security news and investigation Wed, 23 May 2012 21:31:36 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Jayson http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-22356 Jayson Sat, 21 May 2011 19:31:48 +0000 http://www.krebsonsecurity.com/?p=1815#comment-22356 Pretty scary that these devices keep getting smaller and smaller. This site isn't doing anything illegal, but someone could easily use their readers for doing this :( http://www.swipetek.com/ Pretty scary that these devices keep getting smaller and smaller. This site isn’t doing anything illegal, but someone could easily use their readers for doing this :(

http://www.swipetek.com/

Like or Dislike: Thumb up 0 Thumb down 0
]]> By: Psinet http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-19681 Psinet Fri, 18 Mar 2011 01:53:54 +0000 http://www.krebsonsecurity.com/?p=1815#comment-19681 I state again - security meaures must not rely solely on cryptography Not only are Md5 and SHA exploited, but now RSA (SecureID) is vunerable as well. http://securosis.com/blog/rsa-breached-secureid-affected I state again – security meaures must not rely solely on cryptography

Not only are Md5 and SHA exploited, but now RSA (SecureID) is vunerable as well.

http://securosis.com/blog/rsa-breached-secureid-affected

Like or Dislike: Thumb up 0 Thumb down 0
]]> By: 3xpl0it3r http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-19610 3xpl0it3r Wed, 16 Mar 2011 02:32:42 +0000 http://www.krebsonsecurity.com/?p=1815#comment-19610 I sell ATM SKIMMER, price 1000 dollars. I can show on webcam. my id on yahoo mesenger is: acces.denied I sell ATM SKIMMER, price 1000 dollars. I can show on webcam. my id on yahoo mesenger is: acces.denied

Like or Dislike: Thumb up 1 Thumb down 2
]]> By: JCitizen http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-17571 JCitizen Sat, 05 Feb 2011 23:27:22 +0000 http://www.krebsonsecurity.com/?p=1815#comment-17571 Very well! I understand now - thank you for your posts! Very well! I understand now – thank you for your posts!

Like or Dislike: Thumb up 0 Thumb down 0
]]> By: Lynn Wheeler http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-17568 Lynn Wheeler Sat, 05 Feb 2011 20:14:14 +0000 http://www.krebsonsecurity.com/?p=1815#comment-17568 Note that the x9.59 financial transaction standard is all about authentication. As mentioned, in the mid-90s we had been invited to participate in the X9A10 financial standard working group (somewhat as the result of this earlier work we had done on what is now comingly called "electronic commerce") which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (*ALL*, debit, credit, stored-value, gift card, point-of-sale, internet, face-to-face, unattended, low-value, high-value, transit turnstyle, etc aka *ALL*). Detailed end-to-end threat and vulnerability studies had been done of numerous environments before coming up with x9.59 standard. Part of authentication work for x9.59 resulted in no longer having to "hide" transactions &/or account numbers as part of preventing fraud. Now, the major use of *SSL* in the world today is this earlier work we had done for "electronic commerce", for hiding transaction details. The work for x9.59 eliminates the need to hide transactions ... so it also eliminate the primary use of *SSL* in the world today. It also eliminates the threat from fraudulent transactions as a resulting of skimming, evesdropping, and data breaches (doesn't eliminate skimming, evesdropping and/or data breaches, just eliminates crooks being able to use the information for fraudulent transactions). Note that the x9.59 financial transaction standard is all about authentication. As mentioned, in the mid-90s we had been invited to participate in the X9A10 financial standard working group (somewhat as the result of this earlier work we had done on what is now comingly called “electronic commerce”) which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (*ALL*, debit, credit, stored-value, gift card, point-of-sale, internet, face-to-face, unattended, low-value, high-value, transit turnstyle, etc aka *ALL*). Detailed end-to-end threat and vulnerability studies had been done of numerous environments before coming up with x9.59 standard.

Part of authentication work for x9.59 resulted in no longer having to “hide” transactions &/or account numbers as part of preventing fraud. Now, the major use of *SSL* in the world today is this earlier work we had done for “electronic commerce”, for hiding transaction details. The work for x9.59 eliminates the need to hide transactions … so it also eliminate the primary use of *SSL* in the world today. It also eliminates the threat from fraudulent transactions as a resulting of skimming, evesdropping, and data breaches (doesn’t eliminate skimming, evesdropping and/or data breaches, just eliminates crooks being able to use the information for fraudulent transactions).

Like or Dislike: Thumb up 0 Thumb down 0
]]> By: JCitizen http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-17567 JCitizen Sat, 05 Feb 2011 19:25:35 +0000 http://www.krebsonsecurity.com/?p=1815#comment-17567 Thank you psinet and Lynn Wheeler, for all of your comments. This has been very illuminating discussion. I don't hear much about authentication here, so I must not be understanding all your points. I can see where the encryption used would be critical in that area though. It seems a bit of AI[artificial intelligence] would go a long way to help in some of what I understand in Lynn's comments. I know my bank uses some of this in day to day transactions, and it seems to work fairly well, and I haven't been denied transactions very often, and when I do, it makes sense why the transaction got tripped. I want to express my appreciation for your time here. Thank you psinet and Lynn Wheeler, for all of your comments. This has been very illuminating discussion.

I don’t hear much about authentication here, so I must not be understanding all your points. I can see where the encryption used would be critical in that area though. It seems a bit of AI[artificial intelligence] would go a long way to help in some of what I understand in Lynn’s comments. I know my bank uses some of this in day to day transactions, and it seems to work fairly well, and I haven’t been denied transactions very often, and when I do, it makes sense why the transaction got tripped.

I want to express my appreciation for your time here.

Like or Dislike: Thumb up 0 Thumb down 0
]]> By: Lynn Wheeler http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-17559 Lynn Wheeler Sat, 05 Feb 2011 15:50:33 +0000 http://www.krebsonsecurity.com/?p=1815#comment-17559 There has been a lot written that large component of interchange fee is proportional to prospect of fraud ... and US financial institutions get 40% of their bottom line off payments (for some large institutions 60%). On individual fraud items, the bank is liable ... however the prospect of fraud allows the institutions to significantly inflate interchange fees (and their bottom line). One of the periodic articles is that European institutions get less than 10% of their bottom line from payments ... which could account for less resistance to new technologies that would significantly reduce fraud (since the corresponding reduction in interchange fees have less effect on their bottom line). There has been a lot written that large component of interchange fee is proportional to prospect of fraud … and US financial institutions get 40% of their bottom line off payments (for some large institutions 60%). On individual fraud items, the bank is liable … however the prospect of fraud allows the institutions to significantly inflate interchange fees (and their bottom line).

One of the periodic articles is that European institutions get less than 10% of their bottom line from payments … which could account for less resistance to new technologies that would significantly reduce fraud (since the corresponding reduction in interchange fees have less effect on their bottom line).

Like or Dislike: Thumb up 2 Thumb down 0
]]> By: Ray Butlers http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-17557 Ray Butlers Sat, 05 Feb 2011 15:08:08 +0000 http://www.krebsonsecurity.com/?p=1815#comment-17557 Actually, the entities (banks) are at enormous risk since they are liable for all losses. The customers are protected by law (regulation E). Actually, the entities (banks) are at enormous risk since they are liable for all losses. The customers are protected by law (regulation E).

Like or Dislike: Thumb up 0 Thumb down 0
]]> By: Lynn Wheeler http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-12889 Lynn Wheeler Fri, 26 Nov 2010 23:39:59 +0000 http://www.krebsonsecurity.com/?p=1815#comment-12889 I didn't make it to crypto conference where MD5 break was first presented in rump session ... but somebody in the rump session sent me an email in real time ... asking if I would identify all internet standards that reference MD5 ... so I added it as part of my internet standard index information. Part of the x9.59 and the chip effort was something called "parameterized risk management" ... which could associate integrity level of all components involved in transaction and, if necessary update it in real time. Transaction can then be evaluated based on whether minimum integrity levels of the components met the requirement for performing the transaction. Part ATM processing standards has involved DUKPT with DES ... and even tho DES is considered broken ... the issue in the ATM/DUKPT case is that the encrypted information has to be broken within the elapsed time it takes to perform the transaction. I didn’t make it to crypto conference where MD5 break was first presented in rump session … but somebody in the rump session sent me an email in real time … asking if I would identify all internet standards that reference MD5 … so I added it as part of my internet standard index information.

Part of the x9.59 and the chip effort was something called “parameterized risk management” … which could associate integrity level of all components involved in transaction and, if necessary update it in real time. Transaction can then be evaluated based on whether minimum integrity levels of the components met the requirement for performing the transaction.

Part ATM processing standards has involved DUKPT with DES … and even tho DES is considered broken … the issue in the ATM/DUKPT case is that the encrypted information has to be broken within the elapsed time it takes to perform the transaction.

Like or Dislike: Thumb up 1 Thumb down 0
]]> By: psinet http://krebsonsecurity.com/2010/05/fun-with-atm-skimmers-part-iii/comment-page-1/#comment-12888 psinet Fri, 26 Nov 2010 23:29:14 +0000 http://www.krebsonsecurity.com/?p=1815#comment-12888 I should point out that both MD5 and SHA-1 are already crackable by communities of loosely linked ppl on the internet. SHA-2 will take a while, but not long ;) I should point out that both MD5 and SHA-1 are already crackable by communities of loosely linked ppl on the internet.

SHA-2 will take a while, but not long ;)

Like or Dislike: Thumb up 2 Thumb down 0
]]>