browser.secureStorage: Discuss how to handle platforms with limited control over authentication methods

[oliverdunk]

Currently, the browser.secureStorage proposal relies on an authentication array which the developer can use to require specific types of authentication (for example, only face or fingerprint based biometrics).

However, I recently found out that with some implementations (like Windows Hello), it isn't currently possible to specify this and you must request authentication without any control over if biometrics or another method like a PIN code is used.

This is already the case for desktop apps using Windows Hello, so isn't a huge concern, but we should find a way of making it clear to developers that we can't guarantee what auth method secrets are protected by. My first thought is some sort of "*" authentication method that you are forced to pass in on Windows but I'm open to better suggestions.

cc/ @mukul-p - I think this is a Windows API limitation but maybe you have thoughts/there is a way of doing this.

[dotproto]

Just took a brief look at Android's biometric authentication APIs and it appears that they also don't let you specify a particular authentication method. Instead, developers declare whether they want to require BIOMETRIC_STRONG, BIOMETRIC_WEAK, or DEVICE_CREDENTIAL authentication. It seems that this approach abstracts out the method and focuses instead on how well they secure the biometric pipeline and resist attempts to impersonate a user (Android CDD).

I also briefly looked into the Web Authentication API (WebAuthN) and played with the demo at https://webauthn.io/. I'm very new to this API, but when creating new publicKey authentication credentials it appears that callers don't directly specify the authentication methods they wish to use. Instead, the authenticatorSelection property allows callers to specify the properties they require of an authenticator in order to filter the list of options presented to the user. For example, the caller can indicate whether direct user verification of the authentication operation is required, prefered, or discouraged (WebAuthN § 5.8.6). Based on some limited experimentation in Chrome, it appears that end users are expected to be consistent about the authentication methods they use for a given service and to simply ignore they options they don't use when prompted.

[oliverdunk]

Thanks for poking @dotproto! Good to know that Android is similar and those classes sound sensible (it's actually not far off what I already have in the proposal but I guess BIOMETRIC_STRONG is slightly vaguer than FINGERPRINT or FACE).

I think the hard balance here is definitely between two things:

• In an ideal world, we would have a totally abstract API that leaks nothing about the hardware it's running on
• Working on a secure password manager like 1Password, an API which is too vague about what hardware it is using may mean we are too unsure about what protection users are getting and stop us from using the API entirely.

If we do use the classes approach that doesn't solve the Windows Hello issue. We still need to figure out how we would say that any class is fine, probably using an ANY class or going back to the * I proposed.

[dotproto]

I had a short, very early conversation with a member of Chrome's security team today regarding browser.secureStorage and user authentication. They shared that the current prevailing pattern for authentication APIs is to abstract out the specific authentication method used. Given this and Chromium's hesitation to expose details about the authentication method used on the web, this engineer recommended against exposing specific details about the specific method in this API. They also followed up with this Chromium issue crbug.com/1097972 for additional context.

Experiences such as "this website only works with my left index finger" and "I can't log into this website while wearing a mask" are not things that we wish to support. They damage the experience, and thus reputation, of modern authentication in general and encourage people to stick with passwords.

agl@ - source

I'm tentatively expecting that we'll be taking a harder look at this proposal over the coming weeks.

[oliverdunk]

Thanks for starting some conversations here @dotproto, super exciting!

Given this and Chromium's hesitation to expose details about the authentication method used on the web, this engineer recommended against exposing specific details about the specific method in this API.

I'm open to this and I think it lines up with the different biometric categories (WEAK, STRONG) that you were proposing.

Experiences such as "this website only works with my left index finger"... are not things that we wish to support. They... encourage people to stick with passwords.

It looks like this quote was in response to a comment pointing out that "In Android app, at least we can control which authenticator models (fingerprint, PIN...) can be used to authenticate." It seems this user had a very similar goal to us and wanted to be able to control which type of biometrics were offered. I think the response actually misses that point and seems to be assuming the user wants to be able to know which of many enrolled fingers were used. I don't believe this was their use case, and it certainly isn't ours. The goal of this proposal is to offer biometrics in the browser, and if we can show a Touch ID prompt and verify an enrolled finger has been presented, we're happy for that to be any of the fingers which have been enrolled.

In the context of PWAs, the case is stronger. But the (large) roster of work queued up to make WebAuthn more common and useful is already long and I cannot see that PWA-specific support for these extensions would displace anything given that we have significant questions about them. Thus no support should be expected anytime soon. (Source)

This is what makes me think that starting with a WebExtension API is the right approach. I'd love to see something that works for the whole web and to that end, I've had conversations with people in the WebAuthn space to see if we could use what they're building - but it feels like a solution in that domain is a way out unfortunately.

[oliverdunk]

I had a conversation about this internally and we agreed that given the lack of control on some platforms, we likely wouldn't be too opinionated here. It seems reasonable to provide a small number of options in the API and then trust browsers to make a sensible choice beyond that.

I'd like to take on board the feedback about being more generic but I still don't think we've solved the Windows case where we have no control over the biometric whatsoever. To keep things moving along I'll kick things off with a proposal to support the following:

• BIOMETRIC
• DEVICE_CREDENTIAL
• ANY

BIOMETRIC allows any biometric type authentication, and DEVICE_CREDENTIAL adds support for a system password being entered. You can pass one or multiple when storing credentials to control what will be required when retrieving it.

On devices with no control like Windows, the availableAuthentication array will contain a single string of ANY. This must be passed to a subsequent store call to indicate you are ok with using whatever the system chooses. Not passing ANY will cause the API call to throw.

What are the thoughts on that?

[oliverdunk]

Closing this. I am still personally interested in the API but there hasn't been any recent movement on implementation. With that in mind, it doesn't feel worthwhile updating the proposal.

From Chrome's side, we see the use case for the idea at a very high level but are worried about the number of implementations for different platforms that would be needed (using macOS / Windows Hello APIs etc.) and the long-term support costs even after this was implemented across all platforms.