Authentication through only what you are

[mfulton26]

e.g. The native Mint app on Android is able to authenticate me through my fingerprint and it does not give my PIN as a fallback.

I'd like to be able to do the same for a web app where something you know, a PIN, isn't acceptable for this particular flow but requires fingerprint (something you are).

From what I can tell the current UV flag in authenticator data in authentication responses does not distinguish between PIN and biometrics nor does Webauthn currently support prompting for authentication without a PIN fallback. Unless I've missed something there's no current way for a web app to require biometrics for authentication.

I'd like to see this ability added so that when my app needs to protect sensitive data I can prompt to verify the user via what they are and have higher confidence it is indeed them.

A spouse, child, or other can easily observe and know someone's PIN when they are around them enough so in some cases a PIN simply isn't sufficient/desired for authentication.

Thank you.

[emlun]

There isn't a way to request a particular kind of UV, but there is the uvm extension which, if the authenticator supports it, can report after the fact what kind of UV was performed. It may also be possible to use attestation to determine what kind of UV was done. You could then choose to reject assertions with an unsatisfactory UV method if you so wish.

But I would ask you this: why do you want this? Do you, for example, have a legal requirement to only allow biometrics, or is it coming from just a gut feeling that "biometrics is better"? PINs do have their drawbacks, as you note, but biometrics have drawbacks too.

[mfulton26]

why do you want this?

a user's family member stole information from their phone and used it in a harmful way

if accessing the information had required scanning the user's fingerprint and didn't accept simply the PIN (which the family member had discovered somehow, probably through observation) then the information would have remained protected

[sbweeden]

if accessing the information had required scanning the user's fingerprint and didn't accept simply the PIN (which the family member had discovered somehow, probably through observation) then the information would have remained protected

With the PIN, couldn't that family member add their own fingerprint and then use it anyway?

[mfulton26]

Ouch, yes. I mean, it might deter someone less tech savvy so at least it'd block more folks but that's a good point.

…

On Wed, May 4, 2022, 2:10 PM Shane Weeden ***@***.***> wrote: if accessing the information had required scanning the user's fingerprint and didn't accept simply the PIN (which the family member had discovered somehow, probably through observation) then the information would have remained protected With the PIN, couldn't that family member add their own fingerprint and then use it anyway? — Reply to this email directly, view it on GitHub <#1728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKUPXKOXHHF6BN7WFAVHKTVILDTNANCNFSM5VB25ZAA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Firstyear]

There isn't a way to request a particular kind of UV, but there is the uvm extension which, if the authenticator supports it, can report after the fact what kind of UV was performed. It may also be possible to use attestation to determine what kind of UV was done. You could then choose to reject assertions with an unsatisfactory UV method if you so wish.

While UVM "exists" nothing implements it, so you can't really rely on this as a relying party in any capacity.

[Firstyear]

why do you want this?

a user's family member stole information from their phone and used it in a harmful way

if accessing the information had required scanning the user's fingerprint and didn't accept simply the PIN (which the family member had discovered somehow, probably through observation) then the information would have remained protected

If the person has the PIN it's game over - that's the root of trust to authenticate to that device, and you could do a lot more than just webauthn auth from there. Installing apps, go through emails for account resets and more.

So the issue here is the "PIN needs to be stronger", for example iphone allows a full text password. As well, device possession is a factor too. Keeping the device away from malicious entities is a factor here!

IIRC some phones allow you to panic hit the lock button and it disables biometrics and makes it pin/pw only for example.

[mfulton26]

I appreciate all the points about how a compromised PIN/pwd is an issue.

I used my Mint app again this morning and it still gave me a good feeling having it ask for my fingerprint with no PIN fallback available. Isn't that silly? 😂

Is there a good use case to allow biometrics only? Android apps can clearly do it and I know there is a lot of momentum out there to enable web apps to do things that have previously been only available to native mobile apps.

[Firstyear]

I appreciate all the points about how a compromised PIN/pwd is an issue.

I used my Mint app again this morning and it still gave me a good feeling having it ask for my fingerprint with no PIN fallback available. Isn't that silly? 😂

Is there a good use case to allow biometrics only? Android apps can clearly do it and I know there is a lot of momentum out there to enable web apps to do things that have previously been only available to native mobile apps.

There are only negatives sadly. Biometrics may be fast and convinent, but if something happens (burn your thumb, authorities force you to unlock device, some passes away and you need to recover account) then your stuck. The PIN is there as a "fallback" effectively.

[Kieun]

This issue has been discussed a lot before. But, the WG decided not to provide such feature. Although, there is an extension for getting the user verification method as an operation result. And, such feature is not properly provided by the client and the authenticator.
The misconception of this is because many of biometric implementation for the native mobile apps only leverage biometric use only for the authentication and if they need some fallbacks, they provide alternative ways of authentication. The WebAuthn is the tech fully leveraging your device credential (even for biometric and any other unlock methods) and is trying to kill the passwordless completely, it always need fallback mechanism for the case of broken sensors or accessibility issues.

If the such options for handling UV are given to the RPs, the UX will be different from each other and it will make the less market adoption. Some smart RPs might handle such options and keep updating their feature. Most of RPs cannot do that.

I'm not sure when the majority of markets adopt the WebAuthn and leverage passkeys so that they entirely go passwordless, which means they might not need some other insecure fallbacks or account recovery.

[nicksteele]

@Kieun has it, and additionally in most cases the biometric on authenticators is just a way to mask the PIN/Password underneath, as you mentioned @Firstyear. Multi-tenancy devices, i.e. devices with you and others enrolled through the same account, is not a flow I think we necessarily want to handle, and would rather support a more correct flow, with distinct accounts for each user. Outside of using the uvm extension, I would recommend using attestation if you, the RP, is trying to determine the capabilities of the user's authenticator.