Here's why that doesn't work. The attack is very, very, very simple, and once you see it explained, you'll never trust those sorts of services again. A basic attack looks like this:
Attacker compromises the device and waits for user to log into Google.
Attacker captures the response to the authentication request and forwards it to their own server.
Attacker's server connects to Google's system and obtains credentials.
Attacker displays a network error message to the user. The user logs in again to the real Google server, unaware that the first attempt was successful, just for
Here is how I know you haven't a clue what you are talking about, and why I hope you will just go away and stop pontificating:
Attacker compromises the device...
Really? Really? Just like that, compromises my cell phone, which is never out of my possession?
How is it you hand waive all that process away?
And waits for the user to log into google
Again, Really? Do you even have a clue how Google authenticator works?
You don't log into google with the authenticator. You log in with some other computer over a ssl connection.
Then google asks you for a code from the authenticator app. Guess what: The app doesn't even talk to google
except at install time. You can put your phone in airplane mode and still get a code from the authenticator.
So even a compromised phone (something you seem to think is trivial, but never bother to explain) won't do you
any good because it does not contact google.
You then key this number into the computer talking to google over a ssl connection. It compares it to the
number your authenticator would have rendered for that particular 30 second window. If its good you get in
but again you are in a ssl pipe.
So you capture nothing. NOTHING.
Attacker captures the response to the authentication request and forwards it to their own server
No it doesn't, because you captured nothing. It was in an SSL pipe from some compute you don't even know about.
Further the code has been USED, and its no good any more. Its a one time code.
Further Google would see you trying to create your own connection and would immediately you to get a code off of your authenticator...
but wait, you don't have an authenticator synced with that account, and the old number is no good..
You would have to already have an ssl compromised machine in place and lure a google user into signing on via that specific machine.
But wait, that wouldn't work either because
google already detects this. Even Schneier does believe this would work even with National authorities forcing bogus certificates.
Even if you had a pre-compromised computer and an elaborate SSL spoofing setup in place ahead of time, on a computer that you knew I would have to log in from, you can only compromise that single session, and when you attempted to change anything so that you could log in again in the future, I would be locked out of the account, and would therefore know the account had been compromised.
So just stop hand waiving into existence imaginary compromised devices, and thereby supposing into existence the hardest part of the whole operation.
If this was so easy, it would have already been done. Yet every attempt to bypass Two Factor has been done via apps that would not support Two Factor, and which required an application specific password, which in the end, is just another password.