Unless I'm missing something, RFC 4226 sounds like the RSA SecurID system I've worked with before; which is essentially equivalent to Blizzard's system for World of Warcraft.
In which case, my criticism stands. It's trivially more difficult to phish a keycode and the limited window of opportunity is simply a non-issue.[1]
Unless Google is calculating a one-time pad based on the individual login attempt and sending it along a second channel to the registered user, there'll be almost no reduction in phishing.
[1] The tens of seconds a keycode is valid are more than enough to establish a connection.
Which means you phished it once. Which means you need to take drastic actions to exploit it, a slow buildup over time is not an option.
Which in turn means you're more likely to get detected. It's not full protection - you'd still need a second channel for that - but it's better than nothing.
For the systems I log in to, each SecurID code is only valid once. If you want to log in again, you need to wait until a new code is available and use it.
Unless I'm missing something, RFC 4226 sounds like the RSA SecurID system I've worked with before; which is essentially equivalent to Blizzard's system for World of Warcraft.
In which case, my criticism stands. It's trivially more difficult to phish a keycode and the limited window of opportunity is simply a non-issue.[1]
Unless Google is calculating a one-time pad based on the individual login attempt and sending it along a second channel to the registered user, there'll be almost no reduction in phishing.
[1] The tens of seconds a keycode is valid are more than enough to establish a connection.