"a criminal would need both physical access to the card and the knowledge of the permanent password"

No, he wouldn't need anything like that level of access.

He'd just proxy all the authorisation instructions backwards and forwards, *then* raid your account.

Classic man-in-the-middle.

Previous poster correct. One password or even ten won't do anything to stop man in the middle attacks. Even the silly feedback "verification image" banks are using doesn't help.

Https was designed to solve middle-man attacks, but relies on

1. user consistently confirming the domain name (bank.com <> my-bank.com)

2. user checks the pad-lock

3. the browser isn't subverted into displaying the above (perhaps a mock up of a browser window showing 1 and 2 inside of the real browser window).

4. the computer hasn't been compromised by a trojan.

However there is hope!

Both parties can exchange keys out of band (ie by using this number spewing card) and a symmetric encryption algorithm could in principal be used to leave all middle-people in the dark.

Actually this could be a sound encryption approach (requiring a browser upgrade). Unfortunately security would still be compromised by a trojan or user could still be tricked into typing the card's dynamic number at a sneaky web site. So this doesn't provide much more security than a careful user banking via https.

Aside to banks: Quit all this login non-sense that doesn't help protect users at all. I already need passwords pins and keys and now I have to actually drag my mouse pointer across the screen to type on a "virtual keyboard"?!? It's very noble of you to try to defeat the keyloggers. However a compromised machine is inherently insecure no matter what. Consider that attackers can also run a mouse logger, or hijack an existing session, or even just record screen shots.

I can just imagine customers not being able to withdraw money or do transfers, because their card is out of sync.

Excuse me, but doesn't two-factor authentication require two of the following;

Something you have

Something you know

Something you are

???

This is NOT two-factor authentication, as you only need to have the card. If it requested the PIN and the pass-code, then that'd be something, but you aren't allowed to use your PIN online (the bank's terms of service forbid you disclosing the PIN to anyone else!)

All the banks need to do is implement a small frame/application that has a minimum 60 second timer on it. Put this on any page that you use your card .... it should lock the card during this period and cash is only paid to the vendor at the end. Would that not solve proxies as the 60 second timer on the changing part of your pin would have expired. If they mix this with a virtual keypad / drop down list of questions and answers ......

As for spoof websites etc, that is social engineering rather than being technically rubbish. The answer to that will always be customer training......

Also websites that have a point and click interface rather than a key press entry is going to make the effort needed by the thieves much much greater. People write this method off as a pointless excerise but it defeats keyloggers ... negating one of the information thieves tools is always a good start.

To ammend the last post. This is two factor authentication something you know and something you have being two factors. Something you are would be a biometric identifier such as retina or finger print which would be referred to as multi-factor authentication usually.

Ah, after eating lunch I spotted a crucial line;

-->

Customers logging on to the issuer's website would be required to enter both the temporary and permanent password

<--

So this is, in fact, two factor. Serves me right for doubting El Reg.

Humblest apologies.

Cards are already two factor: one is the card number (that is, possession of the card itself), the other is the PIN (in shops) or password (in the bank's website) or "security code" (in shopping websites). The shortcoming with this is that you can know the card number easily, *without* possession of the card at that time.

So this temporary password scheme adds in a requirement to actually possess the card at that instant in time, which is a good thing, but IMHO it's still only two factors. Marketing might argue it's three factor (the card#, the website passwd and the card temporary passwd) but since the latter is redundant with the first, I don't think you can count both.

So they always were 2-factor, they still are 2-factor, it's just that one of the two is now much stronger.

Why not use the domain the interaction is with as part of the encryption key, as well as the temporary password? The bank will then reject any information sent via a man-in-the-middle, and the man-in-the-middle will not be able to decode said information (as they do not have the temporary password). Still not idiot-proof, but only requires browser support to get there.

why they don't simply register a mobile phone to the debit/credit card account and text a random Pin to the phone on demand?

As even the dumbest user is unlikely to lose both card and phone without bothering to report it, this would (unless I'm missing something) solve about 99% of the problem at a stroke