1526792 - Design and implement the API allowing creation of custom WebAuthentication Authenticators

Status: UNCONFIRMED

(Core :: DOM: Web Authentication, enhancement, P5)

Description

[KOLANICH]

There is some demand on pure software WebAuthentication Authenticators. Currently the only approach to create a software authenticator is to create a driver emulating the hardware. It causes performance and security problems.

It is proposed to create a way to create and load pure software Authenticators.

2 kinds of pure software Authenticators are proposed:

1. an Authenticator implemented as a shared library loaded in runtime
2. an Authenticator implemented as a WebExtension.

In order to load an authenticator implemented as a shared library an intermediate library is installed into the system. A User Agent loads that library in runtime (weth graceful fallback if the lib is not available), and that library reports the authenticators installed in the system. To do it the middleware library scans a predefined directory (impl-defined) and inspects all the dynamic libraries available there. Each library can define several authenticators and has exported symbols mirroring the API defined in CTAP specs and some additional symbols for introspection, setup and teardown. Setup and teardown functions can get pointers to tables of functios implementing cryptoprimitives.

A WebExtension Authenticator is a WebExtension with webauthentication-authenticator permission. It listens to events and implements the authenticator with any means it has, for example WebCrypto, WebAssembly, Fetch or Native messaging.

Comment 1

[Dirkjan Ochtman (:djc)]

I independently came up with the same idea (which I guess is obvious to some extent). I think there's a lot of potential. Another way of thinking about this is that Google is doing some of this with Android devices as Authenticator for Chrome running on desktop-class hardware, and it would be nice if Firefox had an (ideally better standardized/more flexible) option to do similar stuff.

https://www.blog.google/technology/safety-security/your-android-phone-is-a-security-key/

Comment 2

[J.C. Jones [:jcj] (he/they)]

I agree. Google's pushing CaBLE (Cloud-Assisted BLE authentication) as the mechanism to do this more easily. CTAP2 supports the use case of phone-authenticating-for-desktop (and vice-versa), but there's a UX problem of how to get everything ready, the push notifications and whatnot, hence CaBLE.

Overall exposing WebAuthn as a WebExtension seems like it would require great care given the level of danger that a malicious extension could prompt. That's something I think would need to start with a security risk analysis, attached to this bug, for consideration. I'm not likely going to invest time in that in the foreseeable future, though I'd happily review such a document. For that reason though I'm going to mark this P5, saying we'd take a patch --- but specifically, I think we need an answer for whether malicious extensions are as much of a danger as I'm thinking, and mitigations regarding that before anyone proceeds to code.

Comment 3

[Dirkjan Ochtman (:djc)]

Can you give some hints about what form such a security risk analysis should take? Like an outline or existing security risk analysis document or some kind of template?

Also I suppose in any case we could/should rely on an extra-stringent AMO review for extensions that ask for this permission.

Comment 4

[David Vo [:auscompgeek]]

It might be worth noting that Krypton already take over WebAuthn by injecting scripts into webpages. Unfortunately this means that Firefox doesn't present the UI to cancel WebAuthn.