3 ms·

> But passkeys aren’t a new thing. It’s just a new name starting to be used for WebAuthn/FIDO2 credentials that enable fully passwordless experiences. These typ

by amluto 4y ago

> But passkeys aren’t a new thing. It’s just a new name starting to be used for WebAuthn/FIDO2 credentials that enable fully passwordless experiences. These types of credentials are also called discoverable credentials, or sometimes resident credentials. Can someone explain what discoverable credentials have to do with a passwordless experience? Accepting a WebAuthn credential in lieu of a password is a policy decision and is every bit as possible with non-discoverable credentials. As I see it, discoverable credentials enable a usernameless experience, which is a rather different phenomenon.

arianvanp 4y ago
You are correct.
- amluto 4y ago
  I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc? Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard.
  - dwaite 4y ago
    > I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc? An agent that registers non-discoverable credentials as discoverable ones via local storage is an option, although not one that browsers have yet chosen to support. This however locks you onto a browser (if it doesn't have a cloud sync fabric) or into a particular ecosystem (if that browser has a sync fabric). Authenticators support discoverability because a limitation of only being able to authenticate in a single browser is significant. Since authenticators tend to either support both discoverability and user verification, or neither discoverability nor user verification, I suspect there won't be business drivers to support such user agent storage/functionality. Note that the CredProtect extension protects discoverability of a resident credential without user verification, and Chrome requests this extension on sites' behalf by default. This protects against scenarios where a third party who gets physical access to your authenticator (thief, partner, law enforcement, border control) can introspect the websites you have accounts at without your participation. > Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard. There was a serious proposal: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension The challenge is that support for such things (new multisig algorithms, this recovery extension) require active relying party participation, and many would just choose not to take on the extra effort. So instead we have multi-device credentials, where there is a sync fabric behind the scenes. Nothing would preclude hardware credentials from participating in such a thing, although they would obviously need either radios or software assistance to do so. To capture the change in physical hardware, a new extension (devicePubKey) is being proposed under Web Authentication. This would have the benefit over the previous recoverability proposal in that sites opt-in to extra responsibility as needed for their business logic, compared to usability being restricted unless sites do extra work.
dwaite 4y ago
> Can someone explain what discoverable credentials have to do with a passwordless experience? Accepting a WebAuthn credential in lieu of a password is a policy decision and is every bit as possible with non-discoverable credentials. As I see it, discoverable credentials enable a usernameless experience, which is a rather different phenomenon. Depends on how much information you want to leak about user accounts. A non-discoverable credential requires a credential handle value from a previously registered credential to be given in the WebAuthn "get" request. That means you need to understand who the user is to look up the set of possible credential handles to supply. Credential handles are a vendor-specific format and are not required to be cryptographically random, so this leaks information such as that an account is valid, how many keys they have registered, and potentially which vendor/model keys those are. The other challenge is somewhat orthogonal to discoverable credentials, and that is authenticator support for user verification. Since the older U2F keys support neither discoverability nor user verification, and since newer discoverable credential usage doesn't make a lot of sense without user verification, the two features sometimes conceptually get bundled together. Without user verification, your authentication only represents (at most) a possession factor. In several spaces this is considered less secure than a password and insufficient. I've heard of efforts to support non-discoverable first-factor authentication via an initial username prompt, but I haven't actually interacted with one in production yet. I believe I have interacted with sites which will do periodic non-discoverable challenges after an initial (password-backed) user login, e.g. step-up a long-term cookie-backed session. These are typically relying on mobile phone/desktop support, and represent it as a faster login option on that device for the future. Since these environments are getting passkeys, I suspect they will eventually migrate over to discoverable credentials with user verification.

by amluto 4y ago

arianvanp 4y ago

You are correct.

amluto 4y ago
I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc? Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard.
- dwaite 4y ago
  > I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc? An agent that registers non-discoverable credentials as discoverable ones via local storage is an option, although not one that browsers have yet chosen to support. This however locks you onto a browser (if it doesn't have a cloud sync fabric) or into a particular ecosystem (if that browser has a sync fabric). Authenticators support discoverability because a limitation of only being able to authenticate in a single browser is significant. Since authenticators tend to either support both discoverability and user verification, or neither discoverability nor user verification, I suspect there won't be business drivers to support such user agent storage/functionality. Note that the CredProtect extension protects discoverability of a resident credential without user verification, and Chrome requests this extension on sites' behalf by default. This protects against scenarios where a third party who gets physical access to your authenticator (thief, partner, law enforcement, border control) can introspect the websites you have accounts at without your participation. > Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard. There was a serious proposal: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension The challenge is that support for such things (new multisig algorithms, this recovery extension) require active relying party participation, and many would just choose not to take on the extra effort. So instead we have multi-device credentials, where there is a sync fabric behind the scenes. Nothing would preclude hardware credentials from participating in such a thing, although they would obviously need either radios or software assistance to do so. To capture the change in physical hardware, a new extension (devicePubKey) is being proposed under Web Authentication. This would have the benefit over the previous recoverability proposal in that sites opt-in to extra responsibility as needed for their business logic, compared to usability being restricted unless sites do extra work.

dwaite 4y ago

> Can someone explain what discoverable credentials have to do with a passwordless experience? Accepting a WebAuthn credential in lieu of a password is a policy decision and is every bit as possible with non-discoverable credentials. As I see it, discoverable credentials enable a usernameless experience, which is a rather different phenomenon. Depends on how much information you want to leak about user accounts. A non-discoverable credential requires a credential handle value from a previously registered credential to be given in the WebAuthn "get" request. That means you need to understand who the user is to look up the set of possible credential handles to supply. Credential handles are a vendor-specific format and are not required to be cryptographically random, so this leaks information such as that an account is valid, how many keys they have registered, and potentially which vendor/model keys those are. The other challenge is somewhat orthogonal to discoverable credentials, and that is authenticator support for user verification. Since the older U2F keys support neither discoverability nor user verification, and since newer discoverable credential usage doesn't make a lot of sense without user verification, the two features sometimes conceptually get bundled together. Without user verification, your authentication only represents (at most) a possession factor. In several spaces this is considered less secure than a password and insufficient. I've heard of efforts to support non-discoverable first-factor authentication via an initial username prompt, but I haven't actually interacted with one in production yet. I believe I have interacted with sites which will do periodic non-discoverable challenges after an initial (password-backed) user login, e.g. step-up a long-term cookie-backed session. These are typically relying on mobile phone/desktop support, and represent it as a faster login option on that device for the future. Since these environments are getting passkeys, I suspect they will eventually migrate over to discoverable credentials with user verification.