Bug 301202
| Summary: | Cannot log-in to Google account with WebAuthn disabled if second factor configured | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adrian Perez <aperez> |
| Component: | WebKit Misc. | Assignee: | Adrian Perez <aperez> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | mcatanzaro, nekohayo, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://github.com/webcompat/web-bugs/issues/184312 | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=205350 | ||
Adrian Perez
Steps to reproduce:
1. Have a Google account with TOTP configured as second factor.
2. Add a second factor method that uses WebAuthn (like a YubiKey, an I think a Passkey would also work).
This step would need using a different browser with WebAuthn support (e.g. Firefox or Chrom{e,ium}).
3. Try to log-in using a browser that uses WebKitGTK or WPE (e.g. MiniBrowser, Epiphany)
Expected outcome:
The authentication flow gives the option to use a second-factor that does not need WebAuthn,
because WebAuthn is not supported in the GTK and WPE WebKit ports.
Actual outcome:
After introducing username and password, the load seems to hang and the progress bar
spins forever. The panel to choose to use a different second-factor that does not need
WebAuthn is never shown.
Additional information:
Opening “about:config” in Firefox and disabling “security.webauth.webauthn” results in the
same problem and the: the alternative second-factor methods panel is not shown.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adrian Perez
After staring into the abyss of minified JS code, it looked like it is assumed that WebAuthn
works if the account has a second-factor configured that uses it. The logic seems to be
“if one can configure it, then the same person must be able to use”, which disregards the
fact that the user may change user-agents from one session to the next.
OTOH, there seems to be code to trigger the panel with fallbacks to other methos if the
“Promise” returned by the “navigator.credentials.{get,create}()“ functions resolves to “null”,
which according to https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer
means:
“If a single credential cannot be unambiguously obtained, the promise resolves with null.“
It seemed worth checking what would happen if we pretend to support WebAuthn but resolve
the “Promise” that way. After some tinkering, adding the following to the WPE MiniBrowser
worked:
// In the activate() function, after adding the optional content
// filter, make sure to always have a content manager and add the
// user script.
if (!userContentManager)
userContentManager = webkit_user_content_manager_new();
const char *googleAuthUserScriptSource =
"(function (N) { \n"
" 'use strict'; \n"
" function resolve_to_null() { \n"
" return new Promise((resolve, reject) => { \n"
" setTimeout(() => { \n"
" resolve(null); \n"
" }, 300); \n"
" }); \n"
" } \n"
" N.credentials = { \n"
" get: resolve_to_null, \n"
" create: resolve_to_null, \n"
" }; \n"
"})(navigator);\n";
const char *googleAuthUserScriptURLs[] = {
"https://accounts.google.com/*",
nullptr,
};
g_autoptr(WebKitUserScript) googleAuthUserScript =
webkit_user_script_new(googleAuthUserScriptSource,
WEBKIT_USER_CONTENT_INJECT_TOP_FRAME,
WEBKIT_USER_SCRIPT_INJECT_AT_DOCUMENT_START,
googleAuthUserScriptURLs,
nullptr);
webkit_user_content_manager_add_script(userContentManager, googleAuthUserScript);
Adrian Perez
This seems to be an issue in the website code itself, not really on WebKit. Therefore I have
reported the issue in the WebCompat tracker: https://webcompat.com/issues/184312
We may be able to provide a quirk in WebKit in the meantime, I'm trying to look into that.
Adrian Perez
Pull request: https://github.com/WebKit/WebKit/pull/52813
Radar WebKit Bug Importer
<rdar://problem/163580319>
EWS
Committed 302791@main (b08846a9d6c8): <https://commits.webkit.org/302791@main>
Reviewed commits have been landed. Closing PR #52813 and removing active labels.