[josteink]

> what's the phishing risk if bitwarden autofills only on the correct domains stored in the vault?

The whole point of passkeys is that they should be tied to a specific domain, and thus be nonphisable.

If Bitwarden allows reuse for different domains, that would be (as I understand it) a violation of the spec and a bug in their implementation.

[kiwijamo]

Silly question perhaps, but what happens if a certain website changes to a different domain. E.g. a takeover of Company B by Company A who then decides to migrate all Company B passkeys to Company A and removes assets hosted under the Company B domain. This is easily sorted with existing tools but with passkeys... how?

[pests]

If they had time to prepare I'm sure they could develop a flow to get you a passkey on the new domain first. Similar to how YouTube used to do a bunch of cross-domain redirects (to plant cookies) to get Google+ login support back in the day.

[neurostimulant]

You might not get a head up when you're forced to change your domain though. For example, recently a huge number of .ml domains are dead and people that used them must scramble to migrate to another domain. The problem is some apps like mastodon (and now passkey) don't support changing domains unless the old domain is still accessible.

[lxgr]

It still wouldn't be a security problem, since WebAuthN includes the hash of the visited domain in the signature.

So even if Bitwarden would go blatantly out of spec and allow usage of a passkey created on and scoped to a.com on b.com, the assertion signature would effectively say "I want to login to b.com", which a.com would simply reject.

That's what makes it so much harder to phish than auto-filled passwords (which could still be MITMed e.g. through usage of attacker-installed TLS certificates).

[eviks]

The question was about the password alternative the op was describing