So from what I understand a attacker couldn't as easily fish me by pretending e.g. to be Google. With a password or even a TOTP code the attacker could just pose as Google and forward the credentials to the actual site.
So from what I understand a attacker couldn't as easily fish me by pretending e.g. to be Google. With a password or even a TOTP code the attacker could just pose as Google and forward the credentials to the actual site.
I've read of attackers with valid passwords spamming logins in hopes to trick a user into approving the auth. Whether it's because it woke up the user and they're in a sleep fog, or they're busy and not paying attention.
Microsoft, at some point, changed their login flow so that, by default, when you enter your username, it sends a pin. I receive regular attempts at this. This isn't going to work out for the attacker because they have to get the pin. But if all that's required is a button press, the attacker could just make the login request and wait.
With multi-factor auth, where a password is in use, you have to get past the password before getting to that auth approval. It reduces how much noise the user gets and the chances of success for the attacker.
For me the question is if this is a webauthn thing in general or a security key thing (to include the domain in the challenge to prevent phishing)
But, of course, if this is optional, I still have to reference the end users. I'm willing to pay for an authentic FIDO key, which can be a tad costly. Your typical user might be more inclined to go for a cheap one that does enough to get into the account, and may not be trustworthy, or would prefer not to do it at all.