WebAuthn does not work

[GGORG0]

Preliminary checklist

• I have read the README.
• I have searched the existing issues for my problem. This is a new ticket, NOT a duplicate or related to another open issue.
• I have read the FAQs.
• I have updated Cromite to the latest version. The bug is reproducible on this latest version.
• This is a bug report about the Cromite browser; not the website nor F-Droid nor anything else.

Can the bug be reproduced with corresponding Chromium version?

No

Cromite version

117.0.5938.89

Device architecture

arm64-v8a

Platform version

Android 13

Android Device model

Google Pixel 6 (with GrapheneOS and Sandboxed Play Services installed!)

Is the device rooted?

No

Changed flags

no flags changed

Is this bug happening in an incognito tab?

Yes

Is this bug caused by the adblocker?

No

Is this bug a crash?

not a crash

Describe the bug

WebAuthn just does not work. After trying to authenticate or register, I get an error (see screenshots)

Steps to reproduce the bug

1. Go to any website that supports WebAuthn authentication, like WebAuthn.io
2. Try to authenticate/register/use passkeys
3. Get an error

Expected behavior

Get a Google Play Services (or similar) popup asking me to authenticate, like this:

Details

Screenshots

Details

[uazo]

I don't know much about it.
in bromite there was a specific issue bromite#2339
seems to need external libraries to work

[uazo]

in the windows version, webauth is up and running.
Now, apart from privacy issues that need to be sorted out (I understand that the site can ask for the existance of registration without the user's prior authorisation), there are two issues:

• either deactivate support in windows
• or activate it in android also using google/microg api.

https://webauthn.io/?regUserVerification=preferred&attestation=none&attachment=platform&algES256=false&algRS256=false&discoverableCredential=preferred&authUserVerification=preferred
in any case i could only check the platform mode (no usb stick).

[GGORG0]

Hi, has there been any work on this? WebAuthn still doesn't work and I have to use another browser to sign into my FIDO2-protected (YubiKey5) accounts on mobile. I use GrapheneOS with Google Play Services. WebAuthn works fine in Vanadium (a chromium-based browser made by the Graphene team - but not as feature-rich as cromite!) and in other apps.
I'm surprised no one else has the same issue... Or maybe I can't search GitHub issues...

[uazo]

no, sorry, I haven't looked at it yet.

[uazo]

Intrigued by how it works, I took a look at the chromium code and found a little something that does not convince me.

docs: https://www.w3.org/TR/webauthn-3/ (Working Draft)

to check:

• kill support to excludeCredentials ?
• check whether native windows support generates different private keys (but I don't think I can verify this)
• understand whether it is possible to bind the feature activation only for certain urls (the login ones), considering that it is still not clear to me whether the call to credentials.get ALWAYS makes the request appear to the user (even if he has no credentials)

I am also able to activate platform authenticator support in android without using gms, but

• I am not able to encrypt private keys in the device, but I could obfuscate them

I'd be out of spec at this point, which explicitly requires encryption of private key in platform authenticators, but after all, android doesn't have support for native encryption protected by the OS, so what can I do?

@PF4Public what do you think about it? is it worth doing even if, theoretically, it is not very safe?

[PF4Public]

@PF4Public what do you think about it? is it worth doing even if, theoretically, it is not very safe?

First of all, what makes WebAuthn not function in Cromite? Did you disable it intentionally? And secondly you should define "very safe". You cannot be significantly safer than Chromium unless you improve upon it yourself. On the other hand as far as I understand WebAuthn, most cryptographic operations are supposed to be running outside of a browser, perhaps there's not much you can do in terms of "safety"?

[uazo]

First of all, what makes WebAuthn not function in Cromite?

the standard requires the existence of an authenticator, which may be external via usb or similar, or of the platform, implemented via software.
in chromium the implementation is delegated to gms in android while in windows via the microsoft api already present in the os.
in fact, in windows, it works, while obviously not in android.

Did you disable it intentionally?

well, yes, as cromite does not allow the use of non-open code, in android. theoretically I should also deactivate it in Windows for the same reason.

You cannot be significantly safer than Chromium unless you improve upon it yourself. On the other hand as far as I understand WebAuthn, most cryptographic operations are supposed to be running outside of a browser, perhaps there's not much you can do in terms of "safety"?

The security lies in the way the private key generated by the plaform authenticator is stored. I do not know how gms saves this information and I do not think I will ever know.
My problem is that there is no API in Android that guarantees data security, theoretically, I guess, because the OS does not allow applications to access another application's private data. but, rooting is possible and at that point, the storage is open.
I had had a similar discussion with Carl some time ago and the conclusion had been that protecting the application from rooting the device was not a goal, but I was in doubt at the time and still am.
what I propose is to encrypt with a symmetric key the storage of that information, as exactly chromium already does for cookies and passwords, obviously modifying the passkey by not making it public (for the record it is 'peanuts').
the question I have is: since theoretically the only way to secure the implementation is to exclude rooted devices (and mine would be one of those :), how much would you use a function that makes it possible to bypass any password if you know it is theoretically flawed from a security point of view?

[PF4Public]

Does Android support hardware USB tokens for that purpose?

[uazo]

Sorry, I do not understand the question, but android os does not have that feature, in android it is developed via google's library.
and me, what I would like to do is exploit https://developer.chrome.com/docs/devtools/webauthn

[PF4Public]

https://developers.google.com/identity/fido/android/native-apps

The API provides a WebAuthn Client implementation, which supports the use of BLE, NFC, and USB roaming authenticators (security keys) as well as a platform authenticator, which allows the user to authenticate using their fingerprint or screen lock.

Perhaps you could allow using only external (hardware) authenticators, which shouldn't compromise user's security; and forbid software implementation (platform authenticator). Alternatively you could allow enabling the latter upon user discretion.

[uazo]

https://developers.google.com/identity/fido/android/native-apps

yes, it is gms (or part of the package) and is closed-source, is the current implementation used in chromium.

Perhaps you could allow using only external (hardware) authenticators, which shouldn't compromise user's security;

I would not be able to, and even if I succeed, it would take too long to develop as well as being outside the scope of cromite.

Alternatively you could allow enabling the latter upon user discretion.

OK, but for example, would you use it?

[PF4Public]

OK, but for example, would you use it?

That would be the question for people who use WebAuthn at the first place. I don't.

[pdf]

The security lies in the way the private key generated by the plaform authenticator is stored. I do not know how gms saves this information and I do not think I will ever know.

Almost certainly via TPM using a key derived from device auth for the current user, however users may replace the default Google passkey provider with another provider at their discretion - e.g. Bitwarden, which is open source. The API calls will still be proxied through GMS or whatever, but actual passkey handling will be taken care of by Bitwarden.

My problem is that there is no API in Android that guarantees data security, theoretically, I guess, because the OS does not allow applications to access another application's private data. but, rooting is possible and at that point, the storage is open.

Define "guarantees data security"? I don't believe application data storage has any relevance here, since storage of these keys is delegated to the external service, they're not stored by the browser itself. See below for notes on guarding against root access.

I had had a similar discussion with Carl some time ago and the conclusion had been that protecting the application from rooting the device was not a goal, but I was in doubt at the time and still am.

It cannot be a goal. If you have root, and are concerned about malicious activities performed as root, then you're already lost - as root you can read/write any process memory, and you cannot guarantee that any operation performed by an application is secure if your adversary can exploit root access.

what I propose is to encrypt with a symmetric key the storage of that information, as exactly chromium already does for cookies and passwords, obviously modifying the passkey by not making it public (for the record it is 'peanuts').

I suspect attempting this would be strictly counter-productive.

the question I have is: since theoretically the only way to secure the implementation is to exclude rooted devices (and mine would be one of those :), how much would you use a function that makes it possible to bypass any password if you know it is theoretically flawed from a security point of view?

As above, an adversary operating as root can already steal all your credentials, so that shouldn't be a blocker here.

[uazo]

what I propose is to encrypt with a symmetric key the storage of that information

I suspect attempting this would be strictly counter-productive.

Can you elaborate?

[pdf]

what I propose is to encrypt with a symmetric key the storage of that information

I suspect attempting this would be strictly counter-productive.

Can you elaborate?

I can't see a way to remain in-spec when attempting this, although it's not entirely clear to me what you're proposing here. Are you suggesting this as an implementation detail for building an Authenticator directly into Cromite?

[uazo]

Are you suggesting this as an implementation detail for building an Authenticator directly into Cromite?

sure, I thought it was clear :)
I have already written a proof-of-work patch and it seems to work but I stopped because I don't know how to securely write the private key to disk.

[pdf]

Are you suggesting this as an implementation detail for building an Authenticator directly into Cromite?

sure, I thought it was clear :)

Does the proposed implementation support delegating to other FIDO2 software/hardware like Bitwarden, Yubikeys, etc?

Tying passkeys to application storage would make them extremely brittle.

[uazo]

Does the proposed implementation support delegating to other FIDO2 software/hardware like Bitwarden, Yubikeys, etc?

No. What I have done is to use the emulation already active in the developer tools.

[pdf]

What I have done is to use the emulation already active in the developer tools.

I see. I can't speak for others, but for me any implentation that doesn't allow the user to provide their own FIDO2 target is probably a non-starter. I also certainly wouldn't consider using a passkey implementation that is strictly tied to a specific browser install, and/or can be destroyed by wiping application storage - either of those conditions would disqualify it for me.

I can understand the desire not to call non-free APIs, but I suspect that a local implementation is likely to be some combination of: less secure; less conformant; less usable.

[uazo]

any implentation that doesn't allow the user to provide their own FIDO2 target is probably a non-starter

The web APIs allow selection of the minimum security level: consider that support in Windows is provided by the windows api (precisely, ‘platform authenticator’) even without hardware key, so in android, with my solution, it would be the same.
In my tests, github and google accepted the keys I produced.

that is strictly tied to a specific browser install

the key would be exportable, it is, after all, a file

I suspect that a local implementation is likely to be some combination of: less secure; less conformant; less usable.

That's why I stopped! or at least, put on low priority...

[pdf]

The web APIs allow selection of the minimum security level: consider that support in Windows is provided by the windows api (precisely, ‘platform authenticator’) even without hardware key, so in android, with my solution, it would be the same.
In my tests, github and google accepted the keys I produced.

I understand that "it works", but it does not work in an an interoperable way - if I want to use my hardware token to provide a passkey, so that I can use that passkey from multiple platforms, that is not possible in the proposed model.

the key would be exportable, it is, after all, a file

But even if it was exportable, it would be entirely unusable except within Cromite.

[GGORG0]

So, if the discussed implementation gets released, will there ever be support for hardware tokens, like YubiKeys? What about saving a passkey into a supported password manager?

Also, why didn't the MicroG implementation get used? It was discussed at the beginning, but I can't find a reason why you didn't stick with it.

Another option - maybe make 2 versions of the app, like other popular open source apps do. One fully 100% FOSS, and the other one, which can include some proprietary blobs where needed (like here, with Google's WebAuthn API). Then the user can choose if want to have those blobs or not. That could maybe allow for some other features, which are also blocked by the 100% FOSS policy.
Even if you do release the current implementation using the DevTools, I'd still recommend considering this for all the other people (like me) who want to use a YubiKey (or store their passkey in their password manager), or just don't trust that the private key is indeed securely stored (or are worried that they might delete it by accident).

No matter what gets chosen, for the end user (me) it will be better than nothing. Right now, my accounts have to have another, less secure, 2FA method just for Cromite... Or if I can't do that, then I have to switch to a different browser just for that 1 task. So annoying.
Cromite is the best, most feature-rich open-source Chromium-based browser for Android. I'd really like to use the GrapheneOS' built-in one - Vanadium - but they don't have as many features, even just a content blocker. But what they do have is WebAuthn support via Google Play Services.

[uazo]

will there ever be support for hardware tokens, like YubiKeys?

I don't have that hw.

What about saving a passkey into a supported password manager?

if bitwarden/android#4005 is accepted, I can see how A14 Credential Manager works.

Also, why didn't the MicroG implementation get used? ... but I can't find a reason why you didn't stick with it.

are you capable of it? sometimes you guys are really weird.
I don't know the implementation, but I believe that, being a drop-in of play services, nothing changes in the chromium code.
except the activation of the play services library, which I would like not to include, since it is specified that it tracks the app.

But what they do have is WebAuthn support via Google Play Services.

it is a choice, I have made mine.

[lucasmz-dev]

if bitwarden/android#4005 is accepted, I can see how A14 Credential Manager works.

On CalyxOS at least, Chromium, any Chromium, has just not been working with it even with the flag enabled. So that would need to be addressed upstream first.
On Mull and such, at least it seems to interact with it, but it fails due to the privileged list. On Chromium, previously it worked, with the same restriction, but now it doesn't even seem to interact with the system's credential manager.

[uazo]

has just not been working with it even with the flag enabled

ah, you say the a14 CM blocks use to unauthorised apps by google? seems strange to me, but I haven't read the documentation yet. but then, what is your pull for?

[lucasmz-dev]

I'm not sure because I can't look at the code, but it just seems using the credential manager in Chromium is just broken. The flag just doesn't seem to have any effect and passkey use just fails immediately, where on Mull/Fennec, Bitwarden complains about the browser instead, in the middle of the process.

The PR I sent to Bitwarden should get one of the issues, which is having Bitwarden trust that browser for passkey use to be solved, but there is still this issue where Chromium doesn't seem to use the credential manager... At least for me.

[uazo]

I'm not sure because I can't look at the code, but it just seems using the credential manager in Chromium is just broken.

if the problem is with the chromium code it can be solved, if it is android it cannot.
I have seen so many constraints built into their code, I am not saying it would be simple, but it is only a matter of time.
but only when a CM backend authorises us to use it (unless I fork bitwarden but I already have a lot to do!)

[lucasmz-dev]

It doesn't seem to work on my mom's phone either, so I suspect it is a Chrome issue
This did use to work for me before, the time that I tested it however was when they also shortly removed the flag AFAICT, so it got a bit confusing, at the time I wrote some very lost comments on it, it was complicated because I don't think Bitwarden or Chromium were either quite ready to use these new APIs and stuff

[lucasmz-dev]

Bitwarden is still in beta, I suspect there's still more to fix in the passkey support side. (e.g. WhatsApp doesn't work with the new native app AFAICT) It makes sense to wait on this, I do think this will be the best form of passkey use in the end though.

[uazo]

@lucasmz-dev if you let me know when Bitwarden comes out of beta I'll try to check what kWebAuthnAndroidCredMan does

[uazo]

Block navigations to fido: scheme URLs on Android

Sites should always use the WebAuthn API rather than attempting to
use the external handler for a fido URL.

Bug: [370482421](https://issues.chromium.org/issues/370482421)
Change-Id: [I5b5a17871a7ab007679c9187c54444c9706d6277](https://chromium-review.googlesource.com/q/I5b5a17871a7ab007679c9187c54444c9706d6277)
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5906286

does anyone know how fido: url works?

[lucasmz-dev]

@uazo

FYI, just realized this now, it seems like I can just download builds from GitHub and install them, they even seem to use the same signing key (?) because I just updated it no issue

e.g. https://github.com/bitwarden/android/actions/runs/11462365731/job/31893580733

Mull already seems to work in this example

[lucasmz-dev]

Ok, it seems like whatever was happening with Chromium is now solved, as it now works on CalyxOS Chromium and Edge. Using bitwarden passkeys still doesn't work, though, on Cromite.

Pretty sure CalyxOS Chromium has the proprietary blobs, might be worth looking into the microG reimplementation

[Xisrr1]

@uazo Can you take a look again? It's hard to login without passkeys.

[Doc-4]

I would also appreciate this feature being revisited, this and extension support are the only reason I'm using brave alongside vanadium instead of cromite.

While it wouldn't be directly useful for Yubikeys, GrapheneOS is working on its own implementation of FIDO2 without requiring play services using the on-device key. Perhaps it might be possible to collaborate?

[uazo]

https://hwsecurity.dev/guide/fido-webview/
https://github.com/hwsecurity-sdk/hwsecurity

WebView Integration
JavaScript calls to navigator.credentials are delegated to the Hardware Security SDK. This is implemented by injecting a short JavaScript file into the currently loaded page. It intercepts API calls and delegates them to our FIDO2 implementation in Java.

interesting, thank you @Doc-4

Perhaps it might be possible to collaborate?

I don't think it can be possible

[Doc-4]

Vanadium implemented preliminary webauthn support (without dependency on play services) as of this version: https://github.com/GrapheneOS/Vanadium/releases/tag/134.0.6998.108.0

It only supports some providers, and there are some open issues of it not working on certain sites, but it's there. I've personally tested Bitwarden and Proton pass and they work (although I don't actually use either, still waiting on support from either KeePass app.)