[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).