I can agree that this will raise the bar for financial transactions — but only slightly. The problem with two-factor authentication systems is that I think they can’t fully deter, stop or avoid man-in-the-middle (MITM) attacks.
Let’s think about this scenario:
A malicious user, Malory, wants to hijack a financial transaction being performed, or about to be performed, by Alice over the Internet against a merchant, called Bob. Malory could forge the merchant’s website, let’s name it X, and hijack Alice communication by diverting it to X’s website — this can be done by hijacking the communication channel or by using social engineering, like phising. Since X’s website looks identical to Bob’s website — or else, the transaction between Alice and Bob can be forged into a new transaction between Alice and X that looks like the original one —, it is possible to deceive Alice into thinking that X is the website she wants to deal with. SSL won’t help much since X’s website can install a valid SSL certificate and yet the browser won’t complain.
Once Alice has got into X’s website, this site can launch a man-in-the-middle-attack: X website contacts Bob’s website in order to retrieve all the authentication details, and sends them back to Alice. This will include a request for Alice to generate and show back the 12-digit, single-use code (One time password, OTP). Alice will use his secure device to generate the 12-digit, single-used code, but will send it back to X’s website.
Now, X’s website has a valid, single-use, 12-digit code for a transaction. Malory, the owner of X, could try forging the transaction at its will, for example by trying to change the amount of the transaction or any of its conditions, like payment timeframe, modifying or even cancelling the transaction. The only thing X has to do is taking the 12-digit code, plus the original transaction information and modify it in such a way that it is somehow altered, but sill valid. This can lead to Denial of Service (DoS) attacks — if Malory simply stops the transaction from taking place —, an active attack that modifies the terms of the transaction in Malory’s benefit or even Bob’s benefit, reducing the amount of the transaction, etc.
In general, I think two-authentication systems are not completely inmune against man-in-the-middle attacks. The user still has the responsability to check that the end-to-end communication channel is secure, that is, that no Malory-like guy has hijacked it. SSL itself won’t prevent this since Alice can still establish a SSL-secured connection against X. The problem is authenticating X identity to be Bob’s website and not Malory’s, that is, asserting that the communication channel is clear and secure. If both Alice and Bob have met before, this can be achieved with relative ease. However, if Alice has never met Bob before this can prove challenging.
Of course, this is my personal opinion. Comments are always welcome.