Add support for WebAuthn (Passkeys)

[varjolintu]

Enables support for sending/receiving Passkeys/WebAuthn requests to/from KeePassXC. Intercepts navigator.credentials.create() and navigator.credentials.get(), modifies the ArrayBuffer's to base64 strings and sends them to KeePassXC. Then waits for a reply.
A fallback option is added. When it's enabled, the browser's own implementation will be called instead (for example after cancel).
The protocol documentation has been updated.

New options are added (disabled by default):

Related KeePassXC's feature PR: keepassxreboot/keepassxc#8825

[droidmonkey]

When registering a new PassKey, the website url is not set. Is this intentional?

[varjolintu]

When registering a new PassKey, the website url is not set. Is this intentional?

To the entry? Relying Party is used instead. Of course we could add the Relying Party also to the URL field if we want to leave it for filtering purposes. Still, there's a possibility that user modifies the existing entry, gives it a different URL and password if the same entry is being used for normal login. That would break the Passkey. As far as I know StrongBox allows setting Passkey to an existing entry, so the username and URL Passkey is using should not collide with the normal ones.

[droidmonkey]

Sorry, what I meant was we should set the url on the entry created for a passkey. More of a convenience thing to be able to go to the website easily. FWIW, in the passkey report you show urls but not relying parties. Seems backwards based on your comment above.

[varjolintu]

Sorry, what I meant was we should set the url on the entry created for a passkey. More of a convenience thing to be able to go to the website easily. FWIW, in the passkey report you show urls but not relying parties. Seems backwards based on your comment above.

Just forgot to change that to the report page. And sure, we can set the URL also.

[varjolintu]

Let's merge this in.

[droidmonkey]

This works exceptionally well!

[mcrocker]

https://passkeys.guru/ (recommended in keepassxreboot/keepassxc#8825) does not want to let the browser extension find the username field or inject the password into it. Auto-type does work though, and then passkeys support works fine from there.

This is probably unrelated to passkeys support, but since it is one of the recommended demo sites, I thought I would mention it.

[varjolintu]

@mcrocker You must add Username-Only Detection for the site for the single username field.

[mcrocker]

Thanks for your quick reply @varjolintu. I did have an entry for "https://passkeys.guru/" under "SITE PREFERENCES" in the KeePassXC-Browser extenstion settings page with "Username-only Detection" checked and that did not help.

It was interesting that https://webauthn.io had a similar issue, but adding the "Username-only Detection" for that site worked as expected and as soon as I clicked the button, the KeePassXC icon appeared in the username field. I was expecting I might have to reload the page or the browser, so it was impressive to see how quick it was.

Unfortunately, this did not work with https://passkeys.guru. I also tried using the "Redetect Login fields" button and the "Choose a Custom Login Field" button. In the last one it would not let me select the login field.

On a fresh reload, the extension button did display the "Select the login information you would like to get entered into the page." message after failing to insert a username from the right click KeePassXC-Browser > Fill Username and Password menu items, fails to produce any output.

After your suggestion, I tried again and noticed that some of the "SITE PREFERENCES" included a wild card. I tried deleting the existing entry and replacing it with an entry without a trailing slash, but KeePassXC-Browser setting added the trailing slash back in. I also tried adding the entry as "https://passkeys.guru/*" with "Username-only Detection" checked, but this did not help.

Finally, I tried it with "Improved Input Field Detection" checked, with and without the wildcard version of the URL, too.

My best guess is that this is some synthetic JavaScript generated view that attempts to look like an input field without using enough of the semantics for the extension to find it. Again, I think this is probably not an issue with the PassKeys functionality, but I just wanted to be thorough for the record.

[mansoorcheema]

It seems that the fallback option to default system Passkey handler (iCloud Keychain) does not work for me on MacOS Sonoma 14.4, Firefox 123.01 and KeePassXC 2.7.7. Only after disabling the passkey in the browser extension the browser uses the system passkeys.

[varjolintu]

@mansoorcheema It's already fixed for extension version 1.9.0.2. Just wait until it's updated to stores.