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.

My Passwindow method could have prevented this and cost practically nothing to implement too, the transaction verification method employed by the electronic tokens which do the transaction signing as explained in the article have the fatal flaw in that it requires user action for the transaction verification part. ie entering the website generated challenge and then their transaction destination account number etc (a very laborious process for the users). With passwindow the transaction information is encoded into the challenge and the user is forced to recognize it (not merely click an authentication button with some other devices) as it this info such as destination account number is cycled alongside the actual authentication confirmation numbers. Once you put up complicated user action hurdles if the attacker owns the browser it wouldnt be too difficult to simply instruct the user to do as you wish claiming a security test or some such. Honestly with the amount of digits required to be entered into both the device and terminal by the user (up to 40+ on some of the devices) Im not suprised it all turns into a blur of action for many users.

Thanks for the good times mate ;) I hope amiga.com would open again, I bought a bunch of their Cimemaware pc converted amiga games 6 months ago off the site but I see its down or gone now. Lots of good memories.

With all the non latin address character sets being approved I imagine there is a world of new opportunities which completely void all the "inspect the address bar" education which was pushed on the general public for so many years. ICANN has managed to turn the net into a pretty much anything goes place, almost every major company is practically extorted into buying the new extension flavour of the month to prevent spammers and fraudsters sending seemingly legitimate email and the general public is left completely confused with no guiding address principals.

regarding Magtek, im not their salesman and I dont know how the costs break down but I know they dont have the cost of replacing all the cards.

Please explain your smartcard web based system which will overcome online fraud? If you are thinking of the outrageously expensive EMV CAP readers there is a thread below about it being a monsterous fail in security, cost and usability.

When I originally came up with the idea it seemed that 4 digits in 16 columns was going to be cracked in about 10 interceptions, with some careful management of the challenges we could get it up to around 50 but we still felt we might have to deploy a virtual keypad with it which didn’t sit right with everyone. Sadly it was at this point I first went on a TV in Australia and got a front page Slashdot story where the response from security people wasn’t great as nobody wants to hear 10 interceptions, the real breakthrough was by separating the digits into single frames of an animated loop and then using a unknown subset of those challenges as the authentication code is when the entropy really took off. So now the attacker has only a very vague probabilistic idea of which digits went to which frames in the challenge and where in those frame columns they might be. Because there is only 1 digit in each frame there is effectively a much wider ratio of possible locations for the digit too. There is some information about the cracking algorithm method in the whitepaper. The curious thing about this animated method is that the smaller ratio of digits to total frames exponentially increases the difficulty of analysis which in effect means smaller password are more secure than larger passwords (If the total number of frames is steady) If you take straight up guessing out of the equation a 4 digit in 10 frames challenge is exponentially more difficult to crack than a 6 in 10. Of course since it doesnt affect usability at all so we turn up the number of overall frames to keep the ratio low and essentially get extra security for free. The next problem for the analyser is the character set, many people don’t realise there are many ways to represent a 1 and others like 6 or 9 or 7 all have multiple versions of themselves, you essentially double the assumed character set. For the analysis we assumed the attackers know exactly which character set is being used and we also assume that 80% is the cracked level of a key is enough to assume it is broken, so I think we are quite generous when the analysis was done. There are actually 3 serious security adjustments which multiply the amount of interceptions, first is the ratio of digits to frames, second is the number of columns in the key and third is the level of obfuscational noise. After that there are a bunch of extra measures which can be easily taken such as increasing the screen challenge proportions and using random offset alignment markers, multiple rows in the key, and a few simple tricks which destroy the analysis permutations. The important thing is doing it the way we are doing it the analysis difficulty gets exponentially difficult with small tweaks so high interception numbers are easily achieved with reasonably sized keys. For the original static challenges we don’t recommend them at all for online authentication as there is no real cost to moving to the animated method and in fact some people report they prefer the usability of the animated method.

There are plenty of phishing examples where they simply added a jabber instant messenger client to the phishing page to instantly transmit the OTP codes.

Thanks I was just about to respond with the same answer, actually apart from that the usability of those devices is terrible. The demonstrations i have seen require 40+ digits back and forth from token device to terminal with no room for error. This is just too much for the average joe of the world to handle on a wide scale and many of the implementations of this I have seen the managers know this and simply dont enable that feature on their devices. To top it off as you mentioned if they control the browser there are lots of games attackers can play with switching account names. The devices are ridiculously big enough already with the necessary long life numeric keypads, to add a full character keyboard onto them would just be too much.