Here's how I know you don't know what you're talking about: All of the things I've talked about have happened already.
Really? Really? Just like that, compromises my cell phone, which is never out of my possession?
A smartphone? You bet. There have been at least two jailbreaks (read "root compromises) for iOS that were triggered by simply going to a web page. In those particular cases, the user knew that he/she was going to a website that did this, but it could just as easily be done surreptitiously.
Nobody bothers to root Android that way because there are generally easier ways to do it, but that doesn't mean it is impossible or even more difficult than it was for iOS. Nor is there any reason to believe that identity thieves do not already have such techniques in their arsenal.
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.
First, that's not necessarily true. Most users do use their phones as browsers, too, which means the device is often the same piece of physical hardware.
Second, even when you do have a proper physical separation between the authenticator and the browser, the only thing it changes is which attacks are relevant:
- If the computer is the compromised device, attacks 1, 2, and 3 are possible.
- If the mobile phone is the compromised device, attack 4 is possible.
In short, the separation is mostly a security no-op.
Even if you had a pre-compromised computer and an elaborate SSL spoofing setup in place ahead of time
Once the endpoint of an SSL/TLS link is compromised, you don't need any spoofing. You can drop an extra self-signed anchor cert into the appropriate trusted anchors list, and you're trusted. There's nothing elaborate about it. It's downright trivial. I can throw together a proof of concept in about three minutes.
For that matter, once the endpoint is compromised, you can just tweak it to display the little lock icon while sending data in the clear. SSL and TLS are worthless if the endpoint is compromised. Completely worthless.
But wait, that wouldn't work either because
google already detects this.
Correction. Chrome detects this, but only if the user is running Chrome and that copy has not been modified by the attacker. Once the computer is compromised, you cannot rely on that, either. Any attacker capable of compromising the computer is also capable of compiling a copy of Chrome with those checks disabled. Besides, even if those checks could magically be made impossible to remove, they would still only effectively guard against attack #2, which still means the security hole is wide enough to drive an Abrams tank through it.
It is not possible to detect a man-in-the-middle attack where one of the endpoints is compromised. Period. You're trying to argue against one of the most fundamental tenets of computer security here. There is exactly one way to guarantee that a transaction is secure, and that requires either cryptographic signing or some other form of cryptographic authentication between two trusted endpoints.
Assuming the servers are secure (which isn't 100% certain, but it's sort of an unavoidable assumption), the remaining piece is a hardware device that is not field programmable, that has a screen to show information about a transaction, buttons to authorize or cancel that transaction, and a simple communication protocol, with code that has been proven to be bug free using formal verification techniques. Anything less than that is at best only trivially more secure than passwords.