Trojans and one-time passwords
Posted by Jonas Elfström Mon, 05 Feb 2007 11:51:00 GMT
It was recently reported that as much as 250 customers of one of Sweden’s biggest banks got their accounts emptied. It is believed that the cyber criminals used a trojan on the bank customer's computers.
The bank in question is known to have one-time passwords (OTP) printed on a plastic card (with the size of a credit card). The OTPs are hidden behind the same kind of layer as scratch lottery tickets uses. To log in the user enters his username and password, scratches and enters the number that shows. The trojan (said to be based on Haxdoor) captured username, password and OTP, then it intercepted the transmission to the bank. Thus the trojan acted as a Mallory and not only as an Eve, see earlier post. By compromising the user's computer the two-factor authentication were circumvented. It is a known problem with security tokens like this and it was not even news to the bank itself. Even the digital variants like RSA SecurID has the same vulnerability, although in that case the 30-60 second timeframe makes it a little harder for the attacker.
Now with OTP
My bank recently improved their security by adding OTPs. Before they used username, password (pin code actually) and a client certificate. Really convenient but apparently not secure enough anymore. The OTPs they have provided their customers with is delivered as a numbered list of 50 OTPs on a piece of paper.
Could they be attacked in the same way as the other bank? If the trojan not already has the capability to copy client certificates I am convinced that it will be capable to do so in the future and then the same attack could be used.
A bold statement
What if there was a really simple way for a bank using this kind of login procedure to be several times more secure? While logging in to my bank a couple of weeks ago I suddenly realized that the bank knows something about my security token (the OTP list) that a trojan does not and that by using that information they could render the attack described above almost useless.
A simple proposal
It's all really simple and I have no intention to claim being the inventor of the scheme. If the procedure has a name other than random challenge of OTP then please inform me.
1. Ask for username+pin code
2. Challenge the user to enter OTP number n where n is a randomly chosen OTP of those that the user has left.
2.1 Even if the user does not enter an OTP it should be considered used up.
The trojan could of course present the user with a false page and challenge the user to enter OTP n but when the trojan then tries to use this OTP it's only one in 50 that it got the right one.
Sign my bills
I would also recommend any bank using OTPs to ask for one a second time for signing purposes. Let's say the customer has made a list of all the bills he is about to pay that month. If the bank then asks the customer for another randomly chosen OTP the attack above would really be rendered almost completely useless.
Not good enough?
The method of asking the user for a specified OTP is an easy enhancement for a paper based OTP numbered list. It does not need any new hardware or infrastructure but only a simple software change. Easy for both the bank and the customer. But what if you want to be even more secure?
A digital security token that lets you sign both account numbers and values of transactions is very secure, the downside is that it's also a lot more cumbersome for the user. A couple of banks in Sweden use these. Of course they are only secure as long as the algorithms involved aren't totally cracked but if they are you will hear about it.
What’s the security model where this is (more) secure? We’re assuming the client software is compromised, right? So why can’t the malware, when it sees the user attempting to login on his/her bank and after entering password/pin:
Am I missing something?
So what you may have gained, given that this attack is valid, is that you force the attacker to act reasonably close in time to the user logging in (the attacker can wait with using the stolen OTP only until just before the challenge expires), at the cost of some usability (locating the correct OTP).
See this.
Test