2

When using WebAuthN (https://w3c.github.io/webauthn/) to authenticate, is it possible to hide certain authentication options?

For example, when testing on webauthn.io, my android device shows available authentication types like hardware keys, Bluetooth, and fingerprint. Is it possible for me to configure it somehow to not accept hardware keys and bluetooth.

Also, when selecting and using my fingerprint to login, if I force it to fail by using the wrong finger, it defaults to then asking for my unlock pattern and if I enter my unlock pattern, I still get a success. In my opinion an unlock pattern is not secure as a dirty screen leaves the pattern on the screen with a smudge mark. Also parents give the pin to children. Can I stop this behaviour and if the fingerprint fails error instead?

garethb
  • 3,951
  • 6
  • 32
  • 52

1 Answers1

2

Not an expert but this is what I discovered when I recently implemented WebAuthn/FIDO2 support in our identity provider:

  1. authenticatorSelection.authenticatorAttachment - When you create the request for navigator.credentials.create() you can specify whether it should use platform (i.e. built-in biometric/PIN) or cross-platform (e,g, an external USB/BT/NFC device). Note this just gives the user agent a hint about what you're after.
  2. authenticatorSelection.userVerification - set this to required and it will require the user of an additional factor beyond mere verification of presence - i.e. a PIN or biometric challenge
  3. Attestation - A FIDO2 compliant device can provide attestation information that can be verified via the Metadata Service. This will expose the capabilies of the device and you can base policy on that. E.g. you could insist that it must use tamperproof hardware to protect the private key.
  4. Authentication result - can provide information about how the user was verified so you could build a policy around that. The spec for this extension is here: https://www.w3.org/TR/webauthn/#sctn-uvm-extension

The recommenation is not to specifically black/white-list devices yourself but the MDS does support revocation of certification and that should be respected by relying parties.

mackie
  • 4,996
  • 1
  • 17
  • 17
  • Using steps 1 and 2 and I'm able to go straight to biometrics (and pin). I'm still unable to differentiate whether PIN was used or biometric. I've searched the result from a successful `navigator.credentials.create` and can't see anything I could use, same for the result from `navigator.credentials.get` unfortunately – garethb Feb 13 '20 at 02:29
  • Have you tried requesting the UVM extension? That can include additional flags in the response that tell you more info about the device and what method was used. https://www.w3.org/TR/webauthn/#sctn-uvm-extension – mackie Feb 13 '20 at 09:07
  • Thanks, looks like that is the right extension to use but I wasn't able to get this to work in chrome – garethb Feb 17 '20 at 04:22
  • I suspect it's more down to what the device itself supports. I've not done exhaustive testing as my requirement at the moment doesn't really require me to know. Ultimately though I'd like to translate the flags that are sent back into `amr` claim values in the resulting tokens issued by my IDP. – mackie Feb 17 '20 at 13:25
  • So its working on Chrome, but UVM contains all the possible ways a user can verify everytime. So whether I use fingerprint, pin or draw pattern, chrome always returns all 3. Not helpful at all..... – garethb Feb 18 '20 at 04:30
  • Chrome knows about and won't fix. Android doesn't expose the details. https://bugs.chromium.org/p/chromium/issues/detail?id=1046700 – garethb Feb 18 '20 at 06:04