1812351 - Can't connect to OVHcloud panel since changeset because of const MAX_ALLOWED_CREDENTIALS

Status: RESOLVED WONTFIX

(Core :: DOM: Web Authentication, defect)

Description

[cs35]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

Go to https://www.ovh.com/manager/ and try to connect to an account with at least 21 Yubikeys associated

Actual results:

At login, the error "Impossible de trouver votre clé de sécurité" ("Can't find your security key") appears.

---

Since the beginning of the summer, we can no longer connect to our OVHcloud account using the Yubikeys used for dual authentication. At the time, the version of Firefox in production was 101.0
Different versions have been released since then without the situation changing, neither we nor OVHcloud support have found an explanation before today.

Among the users who reported problems with Yubikeys, OVHcloud finally discovered that we were the only ones to have a certain number of Yubikeys authorized to connect to the account. The bug not being reproduced on chromium-based browsers, one of their specialists made the link with a possible limit of Firefox and discovered the constant MAX_ALLOWED_CREDENTIALS with a limit of 20 : https://hg.mozilla.org/mozilla-central/file/tip/dom/webauthn/WebAuthnManager.cpp#l450

This constant was introduced by https://hg.mozilla.org/mozilla-central/rev/fa859ac8796d6bd303527e362cd546d2000bae30

We understand that this limit is necessary for security reasons, but it blocks access to the account managing our services with this provider.
Would it be possible to customize the value of this constant, from about:config for example, to allow us to find a nominal operation?

Thanks in advance.

Expected results:

After logging in, instead of receiving an error message, the Yubikey connected to the station should flash to authenticate the connection

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

:rmf, since you are the author of the regressor, bug 1730434, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

This bug has the keyword regression, so its type should be defect.

Comment 4

[John Schanck [:jschanck]]

The 20 credential limit that we use was recommended in Section 6.1.4 of https://arxiv.org/pdf/2205.08071.pdf, and it matches the limit used by Windows Hello. For users on recent versions of Windows, the effective limit will be the minimum of our MAX_ALLOWED_CREDENTIALS and the Windows Hello limit. So I don't think it makes sense for us to expose a preference to raise MAX_ALLOWED_CREDENTIALS above 20.

I understand that this is probably frustrating. Can you use an old version of Firefox or another browser to unregister some of your security keys?

Comment 5

[cs35]

Hello,

Unfortunately, we can't unregister Yubikey, we have already limited to the bare minimum before making this bug report. This number of registered keys, between 20 and 30 at the moment, should increase as our team grows, especially since it is spread all over the country and sometimes abroad (so it is not possible to share a key between multiple users either).
Most of our technical team uses Linux (3/4 of the Yubikeys associated with the OVHcloud account), on various distributions. It is therefore not concerned by the limitation of Windows Hello.
Also, as the documentation of your link indicates "This should still preserve the functionality since most users will never register more than 10 tokens". So we are not in this case suitable for most people (as long as Yubikeys are not more democratized) since we have a higher number of keys. As it is, we really don't need much to be able to work normally again. Setting up a parameter that can be edited by about:config and having a default value of 20, security.webauth.webauth_max_allowed_credentials for example, would allow us to raise this limitation as we need it.

Thanks in advance