2FA is meant to prevent your account from being stolen even if you log in on a compromised system.
As you must assume such a system runs a key logger and will get you password this is a problem. But not a supper big one.
Except if it's a dev-account, because then a lot of things of high importance are linked to it.
I think it's a sane default setup for the causal user. But it and a fiew other defaults should be changed by telling google that this account needs to be secure or similar.
> 2FA is meant to prevent your account from being stolen even if you log in on a compromised system.
No. No 2FA system is designed to protect you from using a compromised system, as there's no such system possible. No 2FA or any system can protect your account and data from a compromised system. It can make it slightly more difficult, but can not prevent the account take-over.
Even with u2f, if the browser lies to u2f device or to you, all bets are off.
If you value your account, you should not sign into a system you don't have trust.
> Even with u2f, if the browser lies to u2f device or to you, all bets are off.
With WebAuthn / U2F if the browser lies it can result in you authenticating to a different system or under different circumstances than you expected, but nothing else, which seems pretty far from "all bets are off".
In particular a compromised browser could tell you that you're signing into Facebook, when the actual authentication performed is for GitHub, for example.
But because the User Presence detection happens in the physical authenticator it can't fake that, it does need you to press the button, tap the sensor or whatever.
And the credentials obtained this way are inherently one-use, when you take your Security Key away, bad guys can't get any further credentials from the compromised system you stopped using. As we see in this Google example that might not stop them, but that's an application security design issue not an inherent flaw in U2F / WebAuthn.
>But because the User Presence detection happens in the physical authenticator it can't fake that, it does need you to press the button, tap the sensor or whatever.
Sure, there's a user present. That doesn't stop the account being compromised. Users tap that thing all day when prompted. You prompt, they tap, easy as pie.
If you're really advanced you could build a little mechanical arm that would reach out of the computer and tap the key itself.
>And the credentials obtained this way are inherently one-use
That "one-use" could be to add a new 2FA device that's under the attacker's permanent control.
No, if you have 2FA peopel can steal you data on a compromised system but not your whole account.
With googles 2FA implementation they can steal your whole account.
If the compromised system has no way to get your second factor it can't disable/change the second factor methods and can't independently log in.
EDIT:
Sure there are probably many other ways to then trick the user into giving 2FA permission to e.g. change 2FA auth. But this is harder and not always viable in all situations.
As you must assume such a system runs a key logger and will get you password this is a problem. But not a supper big one.
Except if it's a dev-account, because then a lot of things of high importance are linked to it.
I think it's a sane default setup for the causal user. But it and a fiew other defaults should be changed by telling google that this account needs to be secure or similar.