We spent some time putting together a threat-model and taxonomy of attacks paths for Passkeys in case anybody is interested: https://www.slashid.dev/blog/passke

We spent some time putting together a threat-model and taxonomy of attacks paths for Passkeys in case anybody is interested: https://www.slashid.dev/blog/passkeys-security-implementation/#security-and-threat-modeling https://www.slashid.dev/blog/passkeys-security-implementatio... Passkeys are definitely a leap forward in that we are shifting the bulk of the account takeover risk from the end users using weak passwords or clicking on phishing links to: 1) The server side implementation, including any mechanism for account recovery and support for multiple passkeys/auth factors 2) The browser enforcement checks (eg: this is what Chrome does: https://www.slashid.dev/blog/webauthn-antiphishing/ https://www.slashid.dev/blog/webauthn-antiphishing/) 3) The wallet/keychain/password manager holding the keys (there's a lot of variance here in terms of security guarantees, see recent password managers breaches. We wrote a bit about how Apple does it: https://www.slashid.dev/blog/passkeys-deepdive/#the-technical-details https://www.slashid.dev/blog/passkeys-deepdive/#the-technica...) 4) The authenticator itself (again, lots of variance here) All of which are harder to compromise vs the average end-user. There are still scenarios where the end-user could be targeted/tricked but they are fewer and harder to pull off (to name some: malware stealing the private keys and account takeovers on the password manager).