Two channel authentication - part two

I've had some excellent replies to my last post (including the CTO of PhoneFactor - probably via Google Alerts or something similar ;) - I don't delude myself into thinking that he reads my blog :)), so I thought I expand a little on the subject:

As it was pointed out in the comments, this does not prevent active MITM attacks. Then again, security is a cat-and-mouse game, and as long as you stay ahead of the curve, you can reduce your risk to the minimum. There are also other approaches to security which can compliment this, like IP Geolocation. Then again (just to make my point about this being a cat-and-mouse game from the technological point of view), bad guys can host servers near you to avoid triggering alarms from IP Geolocation systems. They can even host the code which modifies the transaction on the fly inside your browser in which case IP Geolocation becomes useless.

The elimination of passive attacks (ie. password capture) has the (small) advantage that the time-frame for attackers to act is limited, and while this is not such a big hurdle from an attack standpoint (since the attack itself can be automated), it means that it can be discovered really fast - for example if I fall for an active MITM attack and after doing my trasaction I go down to my bank and ask for the list of transfers, the fraudulent transfer will clearly be present, since the attack can be executed only while I'm logged in. With a passive attack they can withdraw money any time in the future. (Observe that I did not say check my balance / activity history on my computer, since it is possible for attackers to alter the output of the browser to hide the malicious activities, so a second channel needs to be used).

Also I was pointed to the blog posting Only the Easiest Way is the Secure Way (which resonates well with the things said by the second commenter). This is so true. So, while in theory you could thwart some active MITM attacks by good security practices (like checking the validity of SSL certificates), most (and I mean most - like 99.9999%) users won't (know to) do that. Something like NIM (again, no affiliation, just read it in the comments of Roger's Security Blog, and they have a cute animation) has the same capabilities (by which I mean that NIM = client side certificates and proper checking of the server certificates) and probably costs money. Sure, it provides a nicer user interface, but ultimately it is just as vulnerable to active MITM attacks which is performed directly in the clients machine (eg. software which changes the destination account just before the transaction is submitted for example).

Also, I got a video to an OpenID presentation. While OpenID is nice and is very useful for having a federated identity, it's not multi-factor usually (although it can be, if you identity provider chooses so) and has the same problem of single channel authentications: the electronic data representing your proof of identity can still relatively easy be copied and replayed.

Finally, I would like to present a solution employed here in Romania (and probably elsewhere) by ING (again, no affiliation, not even a customer):

When you sign up for online banking, you get a device similar to a pocket calculator. This works as a RSA token at login, but also, when you do a transfer you are asked to punch in the details of the transfer (like the targer, the sum, etc) in it, and it will generate a one-time code which you must provide with the transfer for it to be accepted. This is very cool, and possibly (depending on the implementation) very secure, but a little hard to use. One possible extension of this would be for the webpage to display a 2D barcode with the details of the transfer and for the device to contain a barcode reader, so that you don't have to type them in twice. Again, there are endless possible ways the implementation of such a device can be screwed up (weak hashing algorithms, weak random number generator, etc), however I think the concept is very secure.