keepassxreboot/keepassxc-browser

KeepassXC passkey integration has less precedence, than browser internal one

Opened this issue · 5 comments

Grundik commented

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

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

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.

  • 👍1
varjolintu commented

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.

EDIT: Keeping track this as well: https://github.com/tc39/proposal-arraybuffer-base64. It could help a lot when implemented.

  • 👍3
benbucksch commented

Keepass plugin should have a precedence over browser internal passkey mechanisms

This depends on your circumstances. Usecase: Start with KeePassXC, then gradually switch over to a hardware key. Or wanting to use both the hardware key and KeePassXc for the same site, i.e. as alternative keys. So, I think there should be a setting - on a global level (always prefer one over the other), on a domain level, and on a case by case level (choose every time).

Grundik commented

KeepassXC can fallback to hardware key, there are already option for that: "Enable passkeys fallback". There are no need to modify browser extension for that: if you want to use hardware key for some site, then just hide/delete key entry in KeepassXC, or hit "cancel" button on keepass auth request. Its already working like that.

Problem is: hardware keys cant fallback to keepass ones, and this issue is about it.

  • 👍1