Interesting study however needed a more diverse range of sample testers all of which were early twenties volunteer university graduates. I only bring this up because I see a very different responses to CAPTCHAS. The response and attitude towards CAPTCHAS from young university people hanging around the IT labs where this was most likely advertised will be far far different to the average online citizen. . Im not sure how accurate this is but out in the non IT section of society CAPTCHAS are loathed and hated beyond belief, also the failure rates sound spectacular. Full credit for the new variations on the old warped text captchas but I hazard a guess that those bizarre mental challenges are not going to fly with your average joe. In fact its amazing that captchas have entered mainstream at all. Im sure the study was limited with money and time but I look forward to a more mainstream diverse study.

Many ZeuS packages have an option to remove the outgoing transactions from the user's browser as part of the MITB package, this includes changing the balance total to before the outgoing transactions were made so the user wont know until a paper statement turns up if one ever does as many banks are ditching paper statements in favor of browser based ones. And since they are now using the same trojan tactics on users mobiles to defeat mobile sms authentication I am sure you will see a Zeus mobile trojan upgrade to divert any calls made to the banks hotline number to an even more "helpful" team who will probably need even more user information "to get to the bottom of this please give us your..." /s

More interesting news this week is the gang behind ZeuS, as predicted, have successfully integrated man in the middle attacks against mobile phone two-factor authentication schemes. http://securityblog.s21sec.com/2010/09/zeus-mitmo-man-in-mobile-i.html

I am curious, what sort of authentication is required on their websites to generate the numbers?

I am curious, some people above have mentioned that their online bank account allows them to instantly generate virtual credit card numbers. I am wondering with the trojans like Zeus etc which actively go after online accounts instead of the trojan trying to authenticate an outgoing transfer to a local mule account they could or are switching tactics and going after banks these virtual number generating accounts and then sucking the money out of the accounts from anywhere through the virtual card number charges. I know with the existing schemes they have to bounce the outgoing cash off a local mule and pay him 10% before sending it out overseas but a credit card transaction would rarely be flagged as fraudulent and if the trojan owns the browser like zeus does the account holder wouldnt even know their account was being drained. Can anyone explain why this isnt feasible? Id like some of the above mentioned account holders to explain what authentication is required by the bank websites to generate the card numbers?

Interesting, no doubt there will be more of that type of fraud in the future. So what exactly were in the boxes? fake credit cards? Sorry Im a little confused about the CDRW drives. I work in fraud prevention and after my last post here sure enough I had had a report of exactly what I described. Some African guy in Italy sending out paper letters around the world simply asking for cash. "To the responsible, Honest, humble, handicapped italian man. Financially needy. Open to any proposal, Western union or credit card. Blah Blah.. Thanks.." So yeah they went ahead and did it, cut out all the complexity and just went straight for the money, I guess they did drop in the handicapped angle for sympathy. If I thought I would get a straight answer id almost pay just to know what his ROI is.

Your right, someone could ask for the person to mail their card and they would also need to include their online username and password but for my liking this is getting too close to a rubber hose attack. It would only take one of the billion people who get such a letter to report the physical address to police and the whole scam goes down and also the attacker must start physically injecting himself into the scam which generally isnt the reason they got into online fraud in the first place.

Still its an interesting point I have often wondered if you sent out a billion letters just saying Hello, please send me your money. signed Matt what sort of return on inventment you would get.

Dont forget me with my PassWindow :)
*Works on any device irrespective of OS or software.
*Doesnt matter if a trojan or malware is present on the device, assumes malware is present.
*Costs practically nothing to implement.
*Not vulnerable to phone based extensions of the above attack where users are called and socially engineered out of their authentication keys.

Yes, when the whitepaper was done and PassWindow was initially featured on Slashdot it was a static challenge with several digits in the static challenge, these were interceptable in say 30 interception so a month or 2 worth of normal use. However since then weve had some major breakthroughs beyond just switching to the purely animated cyclical method, weve been able to easily achieve interception rates of 10K plus with very little usability obfuscation. A side benefit of this new method is the analysis doesnt actually give the attacker a clear probablistic determination at say 80% of the necessary number of interceptions, actually its only until the last few interceptions that it all falls into place for the attacker so a guess at 80% isnt knowing 80% of the key pattern. Of course since the whole key process has been pre analyzed its managed and a new card can be issued before it gets anywhere near this number of authentications which might compromise the key pattern. Once you start talking thousands of interceptions required by a normal user even if they authenticate every single day of the year and the attacker is prepared to analyze over a number of years he still wont get anywhere near the numbers required and the average membership card usually only has a few years of life in it anyway. But beyond that the EMV chip doesnt help online based authentication as was shown in the article, its not even helping much of the atm fraud it was desgined for where most ATM's in the world dont even check the EMV chip. The associated CAP readers which use the digital key off an EMV chip for their online authentication use the exact same method of authentication as provided in the article and we can see that has failed.

re telephoto lens attack etc, you are incorrect, it is not trivial to copy as we simply tint the key pattern, in normal lighting conditions it appears black but screens are quite bright and still allow the user to see quite clearly. This is without even going into transflective laminates etc, really the only way would be with a rubber hose or physical interception and there EMV will fail too. A piece of transparent plastic card costs less than a few cents and so if a bank was really paranoid about their user's waving their credit cards around in public they could easily issue a separate card. A digital version could also be constructed however the costs outweigh the benefits.

There is no simulation, it is a real airgap, the PassWindow is just printed onto an ordinary piece of plastic card just like any barcode. There is no electronics, or software or hardware. The challenge is just an animated gif it works on any device regardless of the situation. The transaction information is encoded into the gif so the trojan only has one avenue of attack which is a long term statistical analysis but we assume every terminal is already compromised like this so we do our own analysis at key generation and determine exactly how many interceptions would be required by the theoretical trojan. With some simple tweaks we can get 10K+ interception rates so it would take decades of normal user interceptions to get enough data to analyse. Of course the server issues a new card to a user if their use rate goes anywhere near the interception rate. In short you end up with semi passive transaction verification so the user cant be tricked into entering in the mule account details because its all done serverside, its also much easier to use, the devices from the article are a major pain and take forever to use.

If this is the case in your country I would just ring you up (or get an autodialer like they do with this scam in USA) and say "Hi im from (telecom company) we have some important information about your account but first I need to confirm your phone account management code". Actually I read about another version of the scam where the trojan would detect when the transaction was done and then they would would just ring up the number and say, "hi im from bank and we need to confirm a transaction you just did" Ive also read from Polish researchers that in the GSM protocol there is a kill last SMS command you can send out, so in this case rather than ringing anyone up you send this sms through and remotely delete the confirmation codes.

The simple way they get around the SMS without just putting a trojan on the phone like they do with a terminal is to just phone up the telecommunications company and say please transfer all my calls to xxx number, the girl asks what is your birthday (you google it) and the crime is done. The telecommunication companies cant increase the difficulties of authenticating users because of anti competition legislation which some used to lock in customers.

Do you have a link to any articles?

Banks wont run the IT tech support required, and theres also the liability issues. Even if you could guarantee the software had no security bugs the user can just as easily fall victim to phishing type scams and then sue the bank, this is essentially the same problem with the bootable linux LiveCD concept which does guarantee no trojans getting into it but fails to prevent simple phishing. The tech support for all the different drivers and other things a person might use the terminal for would kill the bank. The other problem is banking rarely happens in a vacum, a user wants their account program, their files etc and so locked devices become good for security demonstrations but impractical in real life.

This is the problem with putting complicated user action into the transaction authentication process, if you control the browser you can request the user do just about anything in the name of a test or error as related in the article. My Passwindow method encodes the transaction information (ie destination account) into the challenge from the server so the user must only visually check the information, because this information is cycled alongside the authentication digits they are forced to inspect it and cannot simply ignore it and blindly authorize the transaction.