4 ms·

So is it true that the website/server can "dictate" which password-client/vendor users are allowed to use and which not ? (don't see this addressed in the artic

So is it true that the website/server can "dictate" which password-client/vendor users are allowed to use and which not ? (don't see this addressed in the article.) For example: Apple native (not) allowed, 1Password (not) allowed, Bitwarden (not) allowed, KeePassXC (not) allowed, etc.

m-p-3 3y ago
Microsoft Azure lets you restrict which Authenticator Attestation GUIDs (AAGUIDs) that are allowed when enrolling a FIDO2 key. Example for Yubikey https://support.yubico.com/hc/en-us/articles/360016648959 https://support.yubico.com/hc/en-us/articles/360016648959 So you could technically restrict which FIDO2 key models are allowed at the server level.
danShumway 3y ago
> A Relying Party can request attestation during passkey registration. Attestation provides additional information about the legitimacy of the authenticator device and can be used by the Relying Party to make a trust decision for the authenticator. According to the WebAuthn specification, authenticators should provide some form of attestation, but it is not required, and authenticators vary in the type and format of attestation statements they can provide. Currently, iOS zeros out attestation information for roaming keys, but that's not dictated by the spec and different authenticators may choose to provide attestation. ---- Relying Parties can also specify feature requirements for user validation/verification: > The user verification requirement. The ability to provide user verification enhances the security of the ceremony, but it may not be necessary for all use cases. Interestingly, user verification can not only be required, it can also be discouraged(https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#enum-userVerificationRequirement https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#enum-user...): > This value indicates that the Relying Party does not want user verification employed during the operation (e.g., in the interest of minimizing disruption to the user interaction flow). And they can indicate that they only want to be used with a platform authenticator instead of a roaming authenticator. ---- Of course, without attestation there is no way to force the authenticator to actually do anything that is asked of it or to identify itself in any way, but it can be assumed that most 3rd-party authenticators are probably not going to lie? Certainly not if they're trying to get certified. Relying parties can set preferred authenticators and they can query authenticators on a device to get a list of discoverable keys, but I'm not sure if there's any expectation that platforms should refuse to work if a preferred authenticator isn't present. ---- There's more information at https://webauthn.wtf/how-it-works/registration#the-options https://webauthn.wtf/how-it-works/registration#the-options and https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictionary-makecredentialoptions https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictionar.... In particular, Relying parties can dictate that duplicate passkeys should not be created for an account. They can also specify extensions that open the door to other requirements: > This member contains additional parameters requesting additional processing by the client and authenticator. For example, the caller may request that only authenticators with certain capabilities be used to create the credential, or that particular information be returned in the attestation object. To me, https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictdef-authenticatorselectioncriteria https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictdef-a... seems to suggest that specific authenticators can be required, but I very well could be misreading that section, so don't quote me on that. And again, without attestation, there's nothing to prevent an authenticator from lying, but... will they lie if push comes to shove? And will the FIDO Alliance tolerate that? ---- In general, the FIDO Alliance's attitude towards all of this is "yes, we're giving Relying Parties a ton of power, but come on, it's not like they would ever use it." There is no requirement in the spec that I'm aware of that would dictate that certified Relying Parties must be vendor neutral and must not try to restrict smaller authenticators.
jiveturkey 3y ago
To the degree that the server can differentiate them, yes. For attested authenticators, the server needs to have a way to keep a list of them. I know some bank/finance sites (Vanguard I think is one) restrict to Yubikey or historically have restricted to that. For non-attested authenticators, the server could unreliably fingerprint the response and decide to selectively allow. Obviously this is completely spoofable, if it's differentiable at all.

m-p-3 3y ago

Microsoft Azure lets you restrict which Authenticator Attestation GUIDs (AAGUIDs) that are allowed when enrolling a FIDO2 key. Example for Yubikey https://support.yubico.com/hc/en-us/articles/360016648959 https://support.yubico.com/hc/en-us/articles/360016648959 So you could technically restrict which FIDO2 key models are allowed at the server level.

danShumway 3y ago

> A Relying Party can request attestation during passkey registration. Attestation provides additional information about the legitimacy of the authenticator device and can be used by the Relying Party to make a trust decision for the authenticator. According to the WebAuthn specification, authenticators should provide some form of attestation, but it is not required, and authenticators vary in the type and format of attestation statements they can provide. Currently, iOS zeros out attestation information for roaming keys, but that's not dictated by the spec and different authenticators may choose to provide attestation. ---- Relying Parties can also specify feature requirements for user validation/verification: > The user verification requirement. The ability to provide user verification enhances the security of the ceremony, but it may not be necessary for all use cases. Interestingly, user verification can not only be required, it can also be discouraged(https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#enum-userVerificationRequirement https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#enum-user...): > This value indicates that the Relying Party does not want user verification employed during the operation (e.g., in the interest of minimizing disruption to the user interaction flow). And they can indicate that they only want to be used with a platform authenticator instead of a roaming authenticator. ---- Of course, without attestation there is no way to force the authenticator to actually do anything that is asked of it or to identify itself in any way, but it can be assumed that most 3rd-party authenticators are probably not going to lie? Certainly not if they're trying to get certified. Relying parties can set preferred authenticators and they can query authenticators on a device to get a list of discoverable keys, but I'm not sure if there's any expectation that platforms should refuse to work if a preferred authenticator isn't present. ---- There's more information at https://webauthn.wtf/how-it-works/registration#the-options https://webauthn.wtf/how-it-works/registration#the-options and https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictionary-makecredentialoptions https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictionar.... In particular, Relying parties can dictate that duplicate passkeys should not be created for an account. They can also specify extensions that open the door to other requirements: > This member contains additional parameters requesting additional processing by the client and authenticator. For example, the caller may request that only authenticators with certain capabilities be used to create the credential, or that particular information be returned in the attestation object. To me, https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictdef-authenticatorselectioncriteria https://www.w3.org/TR/2021/WD-webauthn-3-20210427/#dictdef-a... seems to suggest that specific authenticators can be required, but I very well could be misreading that section, so don't quote me on that. And again, without attestation, there's nothing to prevent an authenticator from lying, but... will they lie if push comes to shove? And will the FIDO Alliance tolerate that? ---- In general, the FIDO Alliance's attitude towards all of this is "yes, we're giving Relying Parties a ton of power, but come on, it's not like they would ever use it." There is no requirement in the spec that I'm aware of that would dictate that certified Relying Parties must be vendor neutral and must not try to restrict smaller authenticators.

jiveturkey 3y ago

To the degree that the server can differentiate them, yes. For attested authenticators, the server needs to have a way to keep a list of them. I know some bank/finance sites (Vanguard I think is one) restrict to Yubikey or historically have restricted to that. For non-attested authenticators, the server could unreliably fingerprint the response and decide to selectively allow. Obviously this is completely spoofable, if it's differentiable at all.