Alice, Bob, and Mallory

It has recently been reported that by simply opening the wrong web page you could be in trouble if you haven't changed the default password of your home router. The page could contain a JavaScript that changes the DNS-settings. Schneier blogs about it here and today he posted a link to a page containing default passwords for most of the home routers on the market.

Change it now!

Recently I helped a friend to change the password on his router. He knew that he could administer his router with a web interface but he did not know where to point his browser. He's running Windows and if you are in the same situation as my friend you could almost always find out the address by:

• Click Start
• choose Run...
• Enter cmd, click ok.
• Type ipconfig + enter.
• Open your favorite web browser and type http:// + the Default Gateway IP-address. Chances are it's http://192.168.0.1/.

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.

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.

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.

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.