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.
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.
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.
I am not associated with Magtek but at least they are offering a solution, you cant call it snake oil as it has been widely deployed (in Chile) and has worked quite well by all reports. Their technology security argument seems as strong as anyone else's argument. The question to you is whats the alternative? Magtek requires new read heads to be installed, EMV requires entirely new hardware and the new smartcards to go along with them which cost $2 a pop which by the million is no small change. The bank managers ive spoken to in emerging countries simply cannot justify the costs and neither solutions solve the biggest worry which is online CNP fraud. Until there is a better alternative solution banks must act on what they have in front of them now.
Regarding the personal attacks, ie hidden cameras etc actually I came up with a really simple solution, you tint the transparent background to a 75% darkness which appears almost black in normal lighting but then when placed over a electronic screen the key segments are clearly visible, most people just dont realise how bright the average screen is. From playing with it I know I would have a much easier time surveiling my OTP token screen with a hidden camera than the tinted key pattern. The best thing is that this doesnt cost any extra as the tinting is done with regular ink used to print other text on the cards. Of course if the attacker can get the card off you and out of your sight then with a light setup he will be able to take a photo of the card but in that scenario all devices fail. We have run the regular tinting through regular photocopiers which only saw black. The card factories are excited about reflective laminates and special angle viewable inks but of course that would all increase the cost so once again the security gain from these tricky solutions is only marginal compared to the free tinting idea (a similar situation with the electronic tokens) of course a purpose with a budget which is prepared to spend more than $1 per user could have special tinting effects for better protection.
I am letting clients choose their own tinting level based on their customer demographic and how likely they will be authenticating out in public. Ideally I would like to see tinting levels customized for individual users, ie if ($member_age>60) $tint = 40% etc
If you would like a sample card I am happy to mail a free one out to you if you put your details into the website contact form. Ultimately there will be alot of customizing going on for different uses and different levels of paranoia.
Regarding deductive trojan analysis of PassWindow, you are correct each time the token is used a tiny bit of probabilistic information is leaked in an ideal trojan attack. Since this is the only online attack the method faces everything fom the beginning is done to eliminate that specific threat. When we generate a new key and associated challenge data we assume a trojan is intercepting all the challenges and all the correct user responses. Since the combinatorics inference is entirely predictable we can deduce exactly how many interceptions an attacker would require to break the newly generated key pattern. By tweaking several parameters of the challenges without even increasing the key size we can easily achieve interception rates up over 10,000 interceptions which means that in an attack situation assuming a user authenticates or logs in once a day for 27 years the trojan still wouldnt have enough data to crack the key pattern. Much higher interception protection rates can be easily achieved however it is technically unecessary and indeed is adjustable on the fly to make sure the an assumed attacker never gets anywhere near enough information. Of course the server keeps a track of every key's number of authentications , its pre analysed interception crack number and the life expectancy of a card is usually no more than a few years so this method of attack doesnt appear to be feasible.
Of course the main security advantage over expensive electronic OTP tokens apart from the cost is the ability to do transaction authentication preventing all trojans from doing harm at a fundamental level without hassling the user to enter in transaction information into a large electronic authentication device.
Weve had an electronic version on the table for awhile but the costs / reliability dont seem to justify the theoretical security increase and the odd extra transaction possibilities over the simple printed approach. In the future it will definitely be released but the card technology as shown in the article isnt really quite there yet. While it looks cool for an OTP the reality is cards go in wallets and wallets go into backpockets under backsides which can place enormous pressure on the liquid screens. I am sure the technology will improve in the future.
Thanks for the commendation, if you have any questions or theoretical attacks I am happy to talk about them, its really a simple idea and in some ways the simplicity leaves an attacker little room to manoeuvre for an attack.
Yes I understand the Magtek solution was widely introduced in Chile and Argentina. I am not associated with the company and have no idea where its been implemented all I know is a bank manager there who implemented it said that cloning went to zero since they did, I like their cost effective solution to the problem which from the article above EMV which Europe has gone for is failing to solve.
I dont disagree the OTP generators are not better than nothing and do add an extra step for the attacker but the trojans are taking that extra step and winning, often the use of OTP absolves the banks of any liability in the fraud so in some ways it could be worse than nothing.
To be clear the article is a little misleading from the point of view the OTP security has nothing to do with stopping cards being cloned, its an online authentication system.
Ah cheers, thanks mate, its hard pushing an entirely new method in such a conservative industry but ive finally got some banks implementing it and some online service networks in Asia where security was important. (Not in Australia yet however) Actually since the show ive improved it enormously, the main discovery was that I can do transaction authentication which prevents any type of trojan attack at a fundamental level and give it a security edge over the electronic OTP devices many banks currently use. The other difference is that you would have seen the static challenges on the show with static digits however I figured out that by animating single digits in an animated gif any deduction analysis on the challenge becomes exponentially more difficult and usability seems to have improved. You can see a demo at http://www.passwindow.com/ I wanted to show it on the grand final episode but the producers of the show had rules about introducing new material. Thanks again for the support.
The OTP card shown in the article is purely used for online transactions. There is no hardware or method available for authenticating these OTP values in a personal way say at an ATM or a shop in these cases to prevent cloning they would opt to use the EMV secret key on the smartchip inside most cards, sadly there are ways around this too by tricking the devices that your card isnt running on the EMV standard so it goes into a non EMV mode.
About the only solution which can fix the card cloning problem economically is the magtek.com method used in South America to cut cloning down to zero. They take a fingerprint of the background noise on the cards magnetic strip and then ad a special reader head to ATM's etc to check this fingerprint exists. The fingerprint is randomly created at time of manufacture and so is technically almost impossible to recreate.
No need to attack the algorithm, instead of running a keylogger just run a trojan which attacks the browser and MITB you way straight past this and other OTP devices. Zeus and most of the major trojans already do. While the device shows no information about WHAT they are authenticating its easy to get a user to authenticate whatever you like without spending any extra bucks.
Like all OTP devices including the RSA OTP tokens the modern trojans simply MITB Man-In-The-Browser their way past these devices including the electronic card pictured in the article. Most of the new trojans (Zeus etc) have this feature or module and they simply hijack the browser dll and then create a second connection in the background. Often the banks require a second OTP value to authenticate the outgoing transaction and so the trojans usually just bounce the user to a "session expired, please login again" page and use the new OTP to validate the outgoing transaction.
My own method http://www.passwindow.com/ does OTP without electronics and at zero cost of implementation, but more importantly it can do transaction authentication (including transaction details into the challenge itself) without any extra requirement from the user (ie no requirements to enter in long transaction account details into a separate device). The trojans are unable to bypass transaction authentication and I know of no other online 2 factor authentication method which is as cheap or usable.
Slashdot Mirror
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.
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.
I am not associated with Magtek but at least they are offering a solution, you cant call it snake oil as it has been widely deployed (in Chile) and has worked quite well by all reports. Their technology security argument seems as strong as anyone else's argument. The question to you is whats the alternative? Magtek requires new read heads to be installed, EMV requires entirely new hardware and the new smartcards to go along with them which cost $2 a pop which by the million is no small change. The bank managers ive spoken to in emerging countries simply cannot justify the costs and neither solutions solve the biggest worry which is online CNP fraud. Until there is a better alternative solution banks must act on what they have in front of them now.
Regarding the personal attacks, ie hidden cameras etc actually I came up with a really simple solution, you tint the transparent background to a 75% darkness which appears almost black in normal lighting but then when placed over a electronic screen the key segments are clearly visible, most people just dont realise how bright the average screen is. From playing with it I know I would have a much easier time surveiling my OTP token screen with a hidden camera than the tinted key pattern. The best thing is that this doesnt cost any extra as the tinting is done with regular ink used to print other text on the cards. Of course if the attacker can get the card off you and out of your sight then with a light setup he will be able to take a photo of the card but in that scenario all devices fail. We have run the regular tinting through regular photocopiers which only saw black. The card factories are excited about reflective laminates and special angle viewable inks but of course that would all increase the cost so once again the security gain from these tricky solutions is only marginal compared to the free tinting idea (a similar situation with the electronic tokens) of course a purpose with a budget which is prepared to spend more than $1 per user could have special tinting effects for better protection.
I am letting clients choose their own tinting level based on their customer demographic and how likely they will be authenticating out in public. Ideally I would like to see tinting levels customized for individual users, ie if ($member_age>60) $tint = 40% etc
If you would like a sample card I am happy to mail a free one out to you if you put your details into the website contact form. Ultimately there will be alot of customizing going on for different uses and different levels of paranoia.
Regarding deductive trojan analysis of PassWindow, you are correct each time the token is used a tiny bit of probabilistic information is leaked in an ideal trojan attack. Since this is the only online attack the method faces everything fom the beginning is done to eliminate that specific threat. When we generate a new key and associated challenge data we assume a trojan is intercepting all the challenges and all the correct user responses. Since the combinatorics inference is entirely predictable we can deduce exactly how many interceptions an attacker would require to break the newly generated key pattern. By tweaking several parameters of the challenges without even increasing the key size we can easily achieve interception rates up over 10,000 interceptions which means that in an attack situation assuming a user authenticates or logs in once a day for 27 years the trojan still wouldnt have enough data to crack the key pattern. Much higher interception protection rates can be easily achieved however it is technically unecessary and indeed is adjustable on the fly to make sure the an assumed attacker never gets anywhere near enough information. Of course the server keeps a track of every key's number of authentications , its pre analysed interception crack number and the life expectancy of a card is usually no more than a few years so this method of attack doesnt appear to be feasible.
Of course the main security advantage over expensive electronic OTP tokens apart from the cost is the ability to do transaction authentication preventing all trojans from doing harm at a fundamental level without hassling the user to enter in transaction information into a large electronic authentication device.
Weve had an electronic version on the table for awhile but the costs / reliability dont seem to justify the theoretical security increase and the odd extra transaction possibilities over the simple printed approach. In the future it will definitely be released but the card technology as shown in the article isnt really quite there yet. While it looks cool for an OTP the reality is cards go in wallets and wallets go into backpockets under backsides which can place enormous pressure on the liquid screens. I am sure the technology will improve in the future.
Thanks for the commendation, if you have any questions or theoretical attacks I am happy to talk about them, its really a simple idea and in some ways the simplicity leaves an attacker little room to manoeuvre for an attack.
Yes I understand the Magtek solution was widely introduced in Chile and Argentina. I am not associated with the company and have no idea where its been implemented all I know is a bank manager there who implemented it said that cloning went to zero since they did, I like their cost effective solution to the problem which from the article above EMV which Europe has gone for is failing to solve. I dont disagree the OTP generators are not better than nothing and do add an extra step for the attacker but the trojans are taking that extra step and winning, often the use of OTP absolves the banks of any liability in the fraud so in some ways it could be worse than nothing. To be clear the article is a little misleading from the point of view the OTP security has nothing to do with stopping cards being cloned, its an online authentication system.
Ah cheers, thanks mate, its hard pushing an entirely new method in such a conservative industry but ive finally got some banks implementing it and some online service networks in Asia where security was important. (Not in Australia yet however) Actually since the show ive improved it enormously, the main discovery was that I can do transaction authentication which prevents any type of trojan attack at a fundamental level and give it a security edge over the electronic OTP devices many banks currently use. The other difference is that you would have seen the static challenges on the show with static digits however I figured out that by animating single digits in an animated gif any deduction analysis on the challenge becomes exponentially more difficult and usability seems to have improved. You can see a demo at http://www.passwindow.com/ I wanted to show it on the grand final episode but the producers of the show had rules about introducing new material. Thanks again for the support.
The OTP card shown in the article is purely used for online transactions. There is no hardware or method available for authenticating these OTP values in a personal way say at an ATM or a shop in these cases to prevent cloning they would opt to use the EMV secret key on the smartchip inside most cards, sadly there are ways around this too by tricking the devices that your card isnt running on the EMV standard so it goes into a non EMV mode. About the only solution which can fix the card cloning problem economically is the magtek.com method used in South America to cut cloning down to zero. They take a fingerprint of the background noise on the cards magnetic strip and then ad a special reader head to ATM's etc to check this fingerprint exists. The fingerprint is randomly created at time of manufacture and so is technically almost impossible to recreate.
No need to attack the algorithm, instead of running a keylogger just run a trojan which attacks the browser and MITB you way straight past this and other OTP devices. Zeus and most of the major trojans already do. While the device shows no information about WHAT they are authenticating its easy to get a user to authenticate whatever you like without spending any extra bucks.
Like all OTP devices including the RSA OTP tokens the modern trojans simply MITB Man-In-The-Browser their way past these devices including the electronic card pictured in the article. Most of the new trojans (Zeus etc) have this feature or module and they simply hijack the browser dll and then create a second connection in the background. Often the banks require a second OTP value to authenticate the outgoing transaction and so the trojans usually just bounce the user to a "session expired, please login again" page and use the new OTP to validate the outgoing transaction. My own method http://www.passwindow.com/ does OTP without electronics and at zero cost of implementation, but more importantly it can do transaction authentication (including transaction details into the challenge itself) without any extra requirement from the user (ie no requirements to enter in long transaction account details into a separate device). The trojans are unable to bypass transaction authentication and I know of no other online 2 factor authentication method which is as cheap or usable.