4 ms·

> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This

> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry. Thanks for this helpful comment, it helped me understand the difference between U2F and passkeys. I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected. (I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys, or would this necessitate buying a new device - if you're not willing to use your phone for the purpose.)

dwaite 3y ago
> I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected. The WebAuthn spec describes a Javascript API, and CTAP describes how to communicate with authenticators over various transports (USB and NFC being the ones with the most implementations). Actual conformance to these, requirements on behavior, and things like whether the hardware has mechanisms to protect certain types of attack if someone has physical access all fall into certification. The implementations can provide attestations, which allow a third party like FIDO Alliance to assert some level of certification (even if at lower levels the implementation details are self-asserted by the implementer). Without certification, it is the manufacturer's word to the user that it has proper security and protections. Without attestations, there is no guarantee to the site requesting authentication that any particular process took place or that the credential has any particular form of security. But the reality is that while we have built sophisticated _models_ for describing authentication and compromise risks, most consumer-facing infrastructure is a hodge hodge of password-backed accounts with email recovery. The user already has full choice in how they manage passwords - from established to shady software makers, to a printout of an excel spreadsheet in 5 point font they keep in their back pocket. The SMS you sent out to verify the user's account may very well be protected by a carrier account with the same password the user supplied to you at registration. > I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys Passkeys are "just" WebAuthn credentials with a couple of features - e.g. discoverability and user verification. With usability caveats (say, limitations around UX with NFC key fobs) I would expect hardware from the last 2-3 years to support passkeys just fine. Support for new features may be added over time, both in software and hardware. For instance, a 2020 security key fob might only support a dozen passkeys, while a more modern fob might be able to store hundreds.

dwaite 3y ago

> I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected. The WebAuthn spec describes a Javascript API, and CTAP describes how to communicate with authenticators over various transports (USB and NFC being the ones with the most implementations). Actual conformance to these, requirements on behavior, and things like whether the hardware has mechanisms to protect certain types of attack if someone has physical access all fall into certification. The implementations can provide attestations, which allow a third party like FIDO Alliance to assert some level of certification (even if at lower levels the implementation details are self-asserted by the implementer). Without certification, it is the manufacturer's word to the user that it has proper security and protections. Without attestations, there is no guarantee to the site requesting authentication that any particular process took place or that the credential has any particular form of security. But the reality is that while we have built sophisticated _models_ for describing authentication and compromise risks, most consumer-facing infrastructure is a hodge hodge of password-backed accounts with email recovery. The user already has full choice in how they manage passwords - from established to shady software makers, to a printout of an excel spreadsheet in 5 point font they keep in their back pocket. The SMS you sent out to verify the user's account may very well be protected by a carrier account with the same password the user supplied to you at registration. > I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys Passkeys are "just" WebAuthn credentials with a couple of features - e.g. discoverability and user verification. With usability caveats (say, limitations around UX with NFC key fobs) I would expect hardware from the last 2-3 years to support passkeys just fine. Support for new features may be added over time, both in software and hardware. For instance, a 2020 security key fob might only support a dozen passkeys, while a more modern fob might be able to store hundreds.