Is this a stand-alone fob-style system, where the keycode is unique to a point in time with no knowledge of the connection? Or is this some sort of second-channel verification, where the requesting connection is hashed into the one-time-pad?
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.
While I have used this kind of authentication before, I'm not intimately familiar with it. From the way Kincaid described it in the article, it seems the key is unique only to a general moment in time, not each log-in attempt (though it wouldn't be hard to imagine it being invalidated as soon as it was used).
If it is only a moment in time, I assume the phishing script could simply log in at the same time and hope the user has the "once per computer" setting enabled. Though this seems like too big of something to miss. Can anyone offer some clarification?
