[bedast]

You're looking at an exploit from a technological point of view, which I expect this community is likely to do. Think of it from the perspective of the average user. I know for a fact if my mom was told by an attacker "if you see an approval request for your account, just accept it" she would do so. It's taken time to train her not to give anyone her password.

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.

[cmeacham98]

You don't understand FIDO/webauthn/etc. The scenario you describe is impossible. This is the genius - the user is totally cut out of the equation, there is no action your mom can take on phishing-website.com to send the credentials of google.com, because the key will refuse to do so.

[bedast]

What this article is about is authenticating the request with an app on your phone, not a hardware key. This ends up being a device totally disconnected from the device requesting the auth, and neither have to be in the same geographic location unless implemented alongside the spec.

[j_san]

Depending on how it's implemented it could still use the same mechanism, couldn't it? (genuine question)

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)

[bedast]

The article specifically discusses auth via app, but if it's involving the FIDO alliance, it'd be weird to exclude hardware keys, I guess. I still don't like the idea of going single factor, but if it's with a hardware key, I can see it being better than with an app since it has to directly interact with the process itself.

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.

[cmeacham98]

My understanding is that the theoretical app being discussed behaves in the same way as a hardware key - it is simply a software-only implementation of the protocol (and thus comes with the same advantages).