keepassxreboot / keepassxc-browser

KeePassXC Browser Extension
GNU General Public License v3.0
1.72k stars 178 forks source link

KeepassXC passkey integration has less precedence, than browser internal one #2335

Open Grundik opened 2 weeks ago

Grundik commented 2 weeks ago

Expected Behavior

Keepass plugin should have a precedence over browser internal passkey mechanisms. When site asks for passkey on its loading, keepass should catch it first, and then fallback to browser in case of missed credentials.

Current Behavior

Internal browser passkey mechanisms have precedence, if page asks for passkey immediately after load: only after browser popup closed, and passkey request reinitiated (without page reload), keepass can do its thing.

On some sites "try again" link reloads the page, making keepass passkeys inaccessible, since it in this case it never has a chance. For example: microsoft.com.

Possible Solution

If it is possible, keepass browser plugin should initialize its mechanisms earlier, to take precedence over browser.

Steps to Reproduce (for bugs)

  1. try to add passkey to microsoft.com account (https://account.live.com/proofs/Manage/additional -> Add a new way to sign in or verify -> Face, fingerprint, PIN, or security key);
  2. fail to add it, since keepass cant ask for passkey: passkey adding page opens, browser opens QR-code window, and on popup close page redirects to an error. No way to "try again" without page reloading.

Debug info

KeePassXC - 2.7.9 (flatpak) KeePassXC-Browser - 1.9.3 Operating system: Linux x86_64 Browser: Chrome/Chromium 128.0.0.0 (flatpak ungoogled chromium)

varjolintu commented 2 weeks ago

This is a difficult one. The extension already injects the passkeys script immediately to the tab. If the site itself triggers some script before that which calls the browser's own passkeys implementation, there might be no way to prevent it.

But, AFAIK there are few different options when to trigger content scripts, and currently the default value is to wait for the page content to be loaded. For passkeys the script could be modified to be loaded much earlier. Gotta investigate it.

Grundik commented 2 weeks ago

It could be easier to reproduce with gitlab, if you have own instance: you can try to add passkey to your account, and try to enter admin mode. Second factor authentication asked at the page loading, so keepass misses it too. But gitlab has "try again" button, which works without page reloading, so second try would work fine.

varjolintu commented 1 week ago

I did some testing with this. Moved the passkeys inject function to a separate script so it's immediately loaded at document_start. With Firefox this worked great. With Microsoft site there was no problems creating a new passkey, and it was the same with GitLab. Chrome however did not work any better, and creating a passkey for Microsoft failed every time. GitLab still required the "try again" method with GitLab when using Chrome.

Gotta investigate this further.