Alice, Bob, and Mallory

In an earlier post I mentioned that a security token that lets you sign your transactions is one way to go to get more secure Internet banking.

Now a couple of swedish students have shown (by also using the problem I mentioned in this post) that a security token both needs to be used in a secure manner and that it also needs to be simple for the user to know what he is actually signing. According to the press it seems that they did this as a man-in-the-middle attack. This is just speculations but it seems the reason that this were possible were that the user did not have a clear view of what he was signing.

It could have been done something like this:

• Redirect the user to a fake site (and hope that he does not investigate the certificate).
• Ask for username and challenge the user with the verification code and then login to the bank in the background.
• Try to add a new account for transfers and then tell the user he mistyped and has to login again while challenging him to verify the new account.
• Transfer money the same way.

The bank has solved the problem by adding a 9 before all login codes. I'm not convinced this is simple and obvious enough for the users. One way to make it simple could be a security device with buttons labeled "login", "sign account" and "sign amount" or such.

EDIT: Now it has started to arrive phishing mails that asks the customers of Swedbank to install ssl3.exe...

The phishing attempts against Nordea are still going strong and the mails are now in almost correct swedish.

One might wonder why Nordea still haven't done any major changes. Maybe the've seen Fight Club and calculates just the way Jack does while working as an automotive manufacture recall coordinator...

One-way hash functions takes a message of any length as input and outputs a very large but fixed length number, called message digest or fingerprint. They can be used for "storing" passwords or as a signature that makes it possible to verify that you got the correct message.

MD5 got into problems over 10 years ago and SHA-1 could to be heading the same way. Until the new standard is published I would follow the crowd and recommend SHA-256.

Ruby

require 'digest/sha2'
quickfox="The quick brown fox jumps over the lazy dog"
Digest::SHA256.hexdigest(quickfox)

=> "d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592"

C#

using System.Security.Cryptography;

...

 ASCIIEncoding byteConverter = new ASCIIEncoding();
 string quickfox="The quick brown fox jumps over the lazy dog";
 HashAlgorithm sha256 = new SHA256Managed();
 byte[] hash = sha256.ComputeHash(byteConverter.GetBytes(quickfox));
 crypt.Text = Convert.ToBase64String(hash);           

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.