Posted by Jonas Elfström
Mon, 12 Feb 2007 18:45:00 GMT
Gunnar Kreitz has shown that random chosen OTPs aren't nearly as good as I first thought. Against the current trojan they work just fine but Kreitz describes how a modified and more advanced trojan could be effective.
It seems that in the end the protocol only forces the trojan be more complex, adds a time span for the validity of the OTP and makes the attack more likely to fail (there is no guarantee that the user will enter a second OTP or that he will do it in time). I suppose the attacker also would have to make the trojan completely automated or have a 24/7 staff waiting. If the user has opted in to have the n presented as a CAPTCHA it would force the evildoers to have that 24/7 staff.
Advantages:
-
A TTL (time to live) for OTPs.
- Demands more resources and higher complexity from the attacker.
Disadvantages:
- A little harder to use (finding the challenged OTP).
- In theory not that much more secure.
My bank has support for sending OTPs by SMS but a trojan that works like the one described by Kreitz would have no problem with that one either.
The protection against phising, as in redirecting the user to a fake login page, is still much greater with randomly chosen OTPs.
I find it a bit ironic that the bank in question actually is going to implement something that sounds like randomly chosen OTPs. They recently announced a change in their login procedure:
"Vilken engångskod från kodkortet du ska använda framgår på inloggningssidan." / "What one-time password you are supposed to enter will be presented on the login page."
Personally I think the security tokens with signing abilities sounds more and more reasonable.
Posted in Security | no comments
Posted by Jonas Elfström
Fri, 09 Feb 2007 00:11:00 GMT
Someone mentioned SETL and I didn't even know what it was so I googled it. Ended up at http://en.wikipedia.org/wiki/SETL#Sample_code:
Print all prime numbers from 2 to N
print({n in {2..N} | forall m in {2..n - 1} | n mod m > 0});
The notation is similar to list comprehension.
Interesting! In Ruby you could do that something like this:
N=42
2.upto(N) {|n| puts n if (2..n-1).all? {|m| n.modulo(m)>0} }
The SETL example at wikipedia actually iterates way too much.
N=42
puts 2
3.step(N,2) {|n| puts n if (2..n/3).all? {|m| n.modulo(m)>0} }
I realize this is not purist list comprehension, well actually it isn't lc at all. Ruby does not have lc in the same sense as Python and others, but you can do almost everything you can with lc with the fantastic collection of methods in Enumerable. If that isn't enough you could always expand Ruby with a more general support for list comprehension like described here.
Posted in Ruby | no comments
Posted by Jonas Elfström
Tue, 06 Feb 2007 15:59:00 GMT
In this post I hope to answer some questions I got about the one-time password protocol I described in "Trojans and one-time passwords".
The scenario is that the attacker has got at least one OTP by using a trojan or some other means.
Couldn't the attacker just reload the login page until he is asked to enter an OTP that he has?
- No, he could not. All decent login procedures has a max number of tries before blocking the account. Also the OTP is asked for in the page following the login-page and failure to enter or to enter a faulty OTP there should count as a failed login attempt.
Couldn't the trojan record all OTPs entered and then it knows it's only one left redirect the login attempt and then login itself with that OTP?
- This is a real concern. To counterfeit this you have to have more OTPs than you will actually use or the numbered list could go on and on and not begin from 1 for every new sheet of OTPs. In either way the trojan will have a hard time to find out how many OTPs there are left.
In theory you could also present the number of the OTP as a CAPTCHA but I would recommend against it for usability reasons and because it locks out people with certain disabilities.
Probability of success
Let's say the trojan has succeeded in getting hold of two OTPs. What is the probability that it will hit the correct OTP if the user has a list of 20, 50 and 200 OTPs and if three login tries are allowed?
20: (1-(18/20*17/19*16/18))*100 = 28.4%
50: (1-(48/50*47/49*46/48))*100 = 11.8%
200: (1-(198/200*197/199*196/198))*100 = 3.0%
This is why it is important to make it hard or impossible for the trojan to count how many OTPs there are left.
If you add a second round of OTP check like I suggested in my earlier post life gets a lot harder for Mallory.
Posted in Security | no comments
Posted by Jonas Elfström
Tue, 06 Feb 2007 13:16:00 GMT
This monday Computer Sweden had an article that says that the finnish branch of Nordea is using something that sounds just like what I described in my earlier post. Unfortunately I can't provide an URL to the article since it seems to only have been published in the paper version.
The article says that they randomly chose among 20 codes. To me that sounds a little low. I even find 50 codes a little low and I plan to show why in a later post.
Posted in Security | no comments
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.
Posted in Security | 3 comments | no trackbacks
Posted by Jonas Elfström
Sun, 04 Feb 2007 19:35:00 GMT
I've been interested in computer security for a long time. Maybe watching War games and coding Commodore 64 made an impact on me as a boy. A couple of years later the annoying boot sector viruses on the Amiga kept my interest going.
In late 1995 I were involved in starting up a local Internet Service Provider. Me and a friend (a colleague at our day job) were the technicians. Our server ran Slackware Linux. Fast forward to late 1996. My friend were sitting in our "office" and happened to notice some strange processes and activity on our server. He pulled the network plug immidiately. We had been hacked!
A couple of days later we got an email from an investigator in the US Airforce. Not that I really thought that it wasn't real but I still wanted more confirmation, so I asked him to call me. I will always remember his opening line "Hello, this is Special Agent Brian...". He asked if he could get some excerpts from certain logs and as far as I remember we provided them to him. He also told us that people like those breaking in into our system usually are very good at removing traces of their visit in the logs. My friends gut feeling and fast network disconnect were probably what made us keep the logs.
All that said I'm not working as a computer security specialist. I've been working as DBA, sysop, teacher, software developer, project manager and systems integrator. I like to think of myself as a software engineer with some social skills. Also I might have a little more focus and feel for computer security than the next guy.
Posted in Security | no comments
Posted by Jonas Elfström
Sat, 03 Feb 2007 17:56:00 GMT
So who's Alice? If you found this blog because of your interest in computer security it's a good chance that you already knew that in cryptography Alice, Bob and Mallory are often used as placeholders for common actors in different scenarios.
I guess it's simpler to remember Alice and Bob than "The sender A wants to identify itself to receiver B" and alike. Alice usually wants to send data to Bob. If there exists an eavesdropper she is often called Eve. Mallory is a more dangerous animal than Eve because he has control over Alice's messages in such a way that he can change or resend then.
The first posting I had in mind for this blog involved Alice, Bob and Mallory and suddenly the blog had a name. That "article" isn't quite finished yet. Now it is.
This blog will most certainly not be about IT Security alone. I have been known to post some Ruby-snippets, JavaScripts and such in the past and will try to keep that up.
Posted in Security | no comments
