4 ms·

FWIW no consumer implementation of passkeys is device bound for exactly this reason. The threat of a user losing a device is much bigger and pressing than getti

by dcow 2y ago

FWIW no consumer implementation of passkeys is device bound for exactly this reason. The threat of a user losing a device is much bigger and pressing than getting phished. All passkeys are backed up in a sync fabric.

gclawes 2y ago
You _can_ use a standalone YubiKey or similar dedicated hardware tokens as a passkey, but they have limited slots for discoverable credentials. But yeah, anything resembling a phone passkey seems to have a sync fabric behind it.
jampekka 2y ago
Most consumer passkey implementations are lock-in. https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ https://arstechnica.com/security/2024/12/passkey-technology-...
- reginald78 2y ago
  And one of the developers of passkeys threatened to use the specified attestation anti-feature to blackball Keepassxc's implementation when they made something not locked in enough. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 There have been some discussions to create an export standard since then but I remain skeptical. Why was this not part of the original spec but the ban hammer was? Depending upon how this standard is implemented I can easily see it preventing export to anything but Google, Microsoft and Apple's implementations. And it still leaves the attestation badness in place.
  - dcow 2y ago
    I was referring to device bound discoverable credentials and saying all implementations that an average Joe will run across have a sync fabric deliberately. Platform lock-in is a different thing. AFAIU the attestation referred to here won’t be signed so any implementation can say anything. It’s just supposed to be ise for things like showing the user a logo so they know where their passkey is stored.
- dcow 2y ago
  Platform/vendor lock-in != device bound

by dcow 2y ago

gclawes 2y ago

You _can_ use a standalone YubiKey or similar dedicated hardware tokens as a passkey, but they have limited slots for discoverable credentials. But yeah, anything resembling a phone passkey seems to have a sync fabric behind it.

jampekka 2y ago

Most consumer passkey implementations are lock-in. https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ https://arstechnica.com/security/2024/12/passkey-technology-...

reginald78 2y ago
And one of the developers of passkeys threatened to use the specified attestation anti-feature to blackball Keepassxc's implementation when they made something not locked in enough. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 There have been some discussions to create an export standard since then but I remain skeptical. Why was this not part of the original spec but the ban hammer was? Depending upon how this standard is implemented I can easily see it preventing export to anything but Google, Microsoft and Apple's implementations. And it still leaves the attestation badness in place.
- dcow 2y ago
  I was referring to device bound discoverable credentials and saying all implementations that an average Joe will run across have a sync fabric deliberately. Platform lock-in is a different thing. AFAIU the attestation referred to here won’t be signed so any implementation can say anything. It’s just supposed to be ise for things like showing the user a logo so they know where their passkey is stored.
dcow 2y ago
Platform/vendor lock-in != device bound