No it isn't, because people will manually fill things in when autofill doesn't work. People will go out of their way to feed credentials to sites that look authentic; it's a genuinely hard problem. (I've had the displeasure of having to work on it for financial industry clients.)
Ironically, just about the only sites where it makes sense to do this as a user are... those from the financial industry, who in their infinite wisdom frequently decide to prevent autofill. There's otherwise basically no reason to ever open the password manager or to know any of your passwords.
In any case, if you have a KBA recovery mechanism, then anyone who would go dig through their saved passwords to put into a phishing site will also just enter the recovery info into a phishing site and enroll an attacker's passkey.
Can you elaborate (or provide a source that does) on how passkeys prevent a phisher from just MITMing the initial passkey setup with some nonsense claim about your session expiring? I'm probably mistaken here, but my interactions with passkeys always make them seem to be trust-on-first-use, which is a very phishable strategy.
A lot of people mentioned the DNS aspect to it, and that's still true. It prevents someone from just proxying the request.
But also, in the end the attacker site isn't really getting anything that would let them then turn around and authorize as you.
Think of it like SSH keys. A public key and a private key. The site holds the public key, you have the private key. When you create a new passkey with the new site, they're holding your public key. They can't go turn around and start logging into to other places with your public key, they can't sign the challenges. So if you make a passkey for bank.com and an attacker at baank.com had you enroll a key there, they can't take the public key at baank.com and use it anywhere to act as you. They only have a public key, and one tied to baank.com at that.
In the end you never actually transmit your actual credential even in the original setup. You're just signing things, the private key stays on your device. And its a different key for every service.
Authenticating yourself with a passkey cryptographically signs a challenge issued by the site you're trying to log in at, and your WebAuthN client (usually your browser) only signs challenges it knows about.
The important point here is that there is no way for you to have your browser sign an arbitrary (e.g. an attacker's) challenge, since you can't input the challenge at all.
This makes WebAuthN strictly better than static passwords, TOTPs (which are "unidirectional" in nature), and even "enter code 123456 into your authentication device and provide the code it displays"-like flows (which is a bidirectional challenge-response, but a MITMable one).
The passkey on the MITM site could not be used with the original site if they were on different domains. If the MITM site is on the same domain as the original site, then either you've compromised the original site or you've got in-roads with a trusted CA to fool the browser into accepting your cert, and passkeys don't protect against those.
Passkeys are tied to a DNS name, so unless they were able to take over the DNS of a site, they wouldn't ever even be offered to authenticate the password. Additionally the private key never leaves the device regardless, so if you were tricked to setup a new passkey on a fake site, you'd just end up creating a new Passkey for it and the site would get some new unique public key.
More than DNS name though--while DNS is susceptible to MITM and cache poisoning, afaik passkeys requires HTTPS so the domain's certificate is validated. Authentication not assertion and all that
