Webauthn on Android

[dougaxe1]

Issues in both Chrome and Firefox on Android. The Android system prompt appears successfully to accept the key, however an error message is shown on both cases.

The issue persists whether the U2F compatibility hack is enabled or disabled in the plugin. Cross-platform / Discouraged are the other two non-default options set.

Tested with two security keys (Yubikey 5 NFC) registered in Windows 10 in Firefox.

Login errors:
Android Chrome: The request is not allowed.
Android Firefox: The operation failed for an unknown transient reason

When attempting to register on Android I get different error messages:
Android Chrome: An unknown error occurred while talking to the credential manager
Android Firefox: The operation failed for an unknown transient reason

Seems similar to #183 however I don't believe it's the same issue because authenticating to Github works fine using these keys with webauthn.

[sjinks]

Hi @dougaxe1,

If possible, could you please give me access to your site so that I can check / test?

My email is volodymyr.kolesnikov at automattic dot com

[dougaxe1]

@sjinks - clearing some things and will reach out via an alternate channel.

[dougaxe1]

I've done some more testing (with both versions 1.0.8 and 1.0.9) and believe the following statements are accurate:

• If a Yubikey is registered on Windows (Chrome or Firefox) it will not work on Android (Chrome or Firefox)
• If a Yubikey is registered on Android (Chrome or Firefox) it works on both Windows and Android - but the counter is never incremented!

(non-default settings: Modality: Cross-Platform, User Verification Requirement: Discouraged)

Unfortunately I've been unable trigger the debugging message made available by the DEBUG_TFPWA flag in 1.0.9. I will try and adapt that code to log more information about the "The operation failed for an unknown transient reason" and "The request is not allowed." messages.

[sjinks]

DEBUG_TFPWA is for the PHP side; there is not much I can do with the JS part (errors come from the browser, and they are very obscure).

[sjinks]

I don't have a Windows box, but with your non-standard settings, when I register the key in a Linux box, I sometimes need to log in twice on Android (the first attempt sometimes fails). Also, the counter does not seem to be incremented for cross-platform attachment modality (again, there is nothing I can do here - the browser reports the counter value).

[dougaxe1]

@sjinks - thanks for your replies. I'll continue debugging and let you know what I find.

[dd32]

I've tested this (Fresh site, no configuration of the plugins, just defaults), and can confirm:

• If a Yubikey is registered via Mac OSX Chrome it will not work on Android Chrome via NFC or USB-C
• If a Yubikey NFC is registered via Android Chrome it will work on Mac OSX Chrome. Did not test registering via USB-C

Android screen locks, if setup on either Desktop or Mobile works on both though, so this appears to be specific to external-security-keys.

[dd32]

Did some more digging, wasn't able to narrow it down any further than it being related to the public key algorithm used.
It appears that Android NFC doesn't support EdDSA, or at least has some kind of issue with it.

It's offering the full kitchen-sink of public key algorithms during registration:

{type: 'public-key', alg: -8}    # EdDSA
{type: 'public-key', alg: -36}   # ECDSA w/ SHA-512 (RFC8152)
{type: 'public-key', alg: -35}	 # ECDSA w/ SHA-384 (RFC8152)
{type: 'public-key', alg: -7}    # ECDSA w/ SHA-256 (RFC8152)
{type: 'public-key', alg: -259}  # RSASSA-PKCS1-v1_5 w/ SHA-512
{type: 'public-key', alg: -258}  # RSASSA-PKCS1-v1_5 w/ SHA-384
{type: 'public-key', alg: -257}  # RSASSA-PKCS1-v1_5 w/ SHA-256

When registered via the Mac it's -8 EdDSA, when registered via Android NFC it's -7 ECDSA w/ SHA-256.

If I forcibly disable EdDSA (-8) when registering the key with Mac, the next algorithm it selects ECDSA w/ SHA-256 (-7), and then successfully works via Android NFC.

The key I've tested with is a Yubikey 5c NFC with firmware 5.4.3. (It looks like Yubikey added support for EdDSA in Firmware 5.2.3 / Devices after August 2019, Yubikeys prior to then probably don't have this issue, and other NFC keys that don't support EdDSA probably don't suffer this either)

[dd32]

Temporarily, as a workaround one can disable EdDSA for new key registrations using the below code in an mu-plugin.

This will cause any newer keys registered through a desktop that supports that algorithm to not be offered it during registration, which means it won't attempt to use it during subsequent validation attempts. AFAIK there's no way for an existing key to be fixed, without Android NFC supporting it (I'm guessing that's the problem, but I'm not sure).

add_action(
	'wp_ajax_webauthn_preregister',
	function() {
		ob_start( function( $output ) {
			$json = json_decode( $output );

			if ( ! empty( $json->data->options->pubKeyCredParams ) ) {
				$json->data->options->pubKeyCredParams = array_values(
					wp_list_filter(
						$json->data->options->pubKeyCredParams,
						[ 'alg' => -8 ],
						'NOT'
					)
				);

				$output = wp_json_encode( $json );
			}

			return $output;
		} );
	},
	1
);

[dougaxe1]

Very late follow-up, but the code provided by @dd32 resolved my issue of desktop-registered keys working on Android mobile (NFC). Since I have a fix, this issue can be closed, or if there's interest to incorporate a more proper filter of public key cred params into this plugin, that would be appreciated, too.

[sjinks]

I have applied a patch from https://github.com/madwizard-org/webauthn-server/pull/23/files; in theory; this should fix this issue.

[sjinks]

2.4.1 and 2.5.0 have this fix.

[dougaxe1]

Version 2.5.0 of the plugin without the workaround from @dd32 did not work for me when registering in Windows FF and using in Android Chrome. Restoring the workaround continues to work in the latest version of the plugin.