[thewebguyd]

> passkeys are intended to sync via your password manager of choice as the primary use case.

The sync was actually a compromise to the standard. The idea was unique, device-bound credentials. One person, one device. The private key/passkey on your phone should not be the same one on your laptop, or your tablet, etc. Each device was supposed to have it' own unique credential.

Allowing sync is a security downgrade to the standard, in terms of threat-model guarantees. Pure WebAuthn credentials should be sealed in hardware (TPM or Secure Enclave or equivalent) and be mathematically non-exportable which guarantees zero remote blast radius, an attacker must physically posses the device.

Allowing sync and storing passkeys in a password manager reintroduces cloud account compromise risk and recovery flow hijacks. You lose non-repudiation.

Still more secure than passphrase + TOTP, but doesn't eliminate account takeover attacks against your cloud credential vault, which purely hardware based, per-device credentials do.

[Aerroon]

I don't get it. How does every device combo having a unique key pair help with security? They can all log in, right? So all you need is to compromise their session and you're in, whether they share the same passkey or not.

And if you're compromised in such a way that an attacker could steal your password then wouldn't they be able to just hijack your session instead?

[thewebguyd]

Passkeys protect against credential theft, not session hijacking, two different parts of the stack. Passkey's only concern is initial authentication, it was never meant to provide any sort of protection against session theft. RFC 9449 Proof of Possession is how you prevent session hijacking, or session binding with a client-side TLS certificate.

Device-bound passkeys take care of non-repudiation. With synced keys (e.g., 1password), an account compromise of your vault hands the attacker all your credentials, the private keys are in the vault.

Device-bound keeps the private key sealed in the TPM (or secure enclave), the key cannot be exported, so it cannot be extracted remotely. Even malware on the machine, can hijack your session, but it cannot exfiltrate your private key, TPM won't release it to the service without user verification via biometrics, yubikey, or a PIN. There's also an attestation chain that breaks with synced passkeys. The attacker has no way to get your private key, so the only way to compromise the account is, yes, session hijacking, or physical access to the device with the user present to pass the biometrics check.

[rufo]

Ooh, thanks for the insight, I didn’t realize that - though that makes sense given how they work. My initial reaction is, I like the idea of the pure hardware-locked passkey as you describe it, but I feel like the syncing is a reasonable-ish nod towards making them more usable in the real world since it does let you have more flexibility.

I haven’t ever looked at the APIs for passkeys; is there any semblance of those types of keys being an option, or did opening the door to syncing basically let anything happen with the APIs and lose those guarantees?