Here my point is, that if the user previously set the pin for FIDO app on key, it shall be respected, and userVerification being used. "the user experience depends on whether or not a PIN is set or a fingerprint is enrolled on the user’s security key." It states it in "use cases" loose section, and AFAIR this is not FIDO2 recommendation. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
current firefox has intermitent support of fido2/ctap2, while chrome/chromium supports it fully. PIN is only FIDO2 construct, in older, U2F (2014), there is no pin for credentials protectionĭ. Although I report it under 'web bitwarden' it shall apply to most/all clients supporting fido.Ĭ. full: allow user, during key enrollment, to define two options according to his needs:Īnd create credential on key according to user selection.Ĭurrently all credentials on keys are generated with the same configuration: touch required, pin not required.If so, properly mark new credential upon key enrollment as 'user-verification-required', if not, only 'user-presence'
minimal: checking if PIN is set on FIDO2 key.and currently is doing it improperly.Īctually two scenarios are possible/correct: *) here I mean, that bitwarden js code upon key enrollment may require (CTAP2 usage) specific parameters of generated credentials, like touch required, pin required etc.
any future usage of such 2fa token, will only required touch, while not pin.new credentials are created (because of improper configuration*) with only user-presence required, while not user-verification required.enroll such key as 2FA to bitwarden, using browser.use FIDO2 compliant yubikey (not older U2F/FIDO1).
0 kommentar(er)
