KeepassXC doesn't recognize existing passkey from Strongbox

[kvn-be]

Overview

I am using Keepassxc for Windows and Strongbox for Mac and iOS. I have stored some passkeys in Strongbox before (I'll be referencing to my passkey use for the website "ebay"). Yesterday I downloaded v.2.7.7 of keepassxc, with the implementation of passkeys.
Unfortunately Keepassxc does not recognize any previously set passkeys from Strongbox and vice versa. If I have set a passkey with strongbox, keepassxc won't accept the passkey and asks me if I want to overwrite the one for that entry (ebay). If I hit yes, I'm able to log in with keepassxc, but not with strongbox anymore.

I'll continue calling keepassxc simply kp and strongbox sb.

Steps to Reproduce

1. Set up a passkey for any entry that can use a passkey with kp or sb
2. Sync both instances so the passkey is accessible on sb and kp ( here the key will be stored in "advanced" and "additional properties")
3. Try to log in using the passkey with the opposite software / operating system the passkey was created with (created on sb try to log in with kp)

Expected Behavior

1. The passkey should be recognised and valid for either operating system or software used to create the passkey.
2. The login should work with one key, created on either software

Actual Behavior

1. The login on kp does not work with the one created from sb (and the other way around)
2. The Error notes that the passkey is not recocnized.
3. I get prompted if I want to use passkey on keepassxc and I have the option to override the existing passkey.
4. Once I do that, I can’t use the passkey on strongbox (macos) anymore and get promted if I want to override the existing one.

Context

I have found a Workaround, as I noticed, that Kp does not store the passkey directly with the entry that contains the password and username, but rather as a separate entry itself.

Workaround

1. When I create a passkey on kp first, I can on only create a new entry entirely and cant safe it to my existing entry which holds username and password
2. One I do that, I have two entries: Ebay (username and password) and Ebay (passkey)
3. If I go back to strongbox, I can create a passkey for the existing entry Ebay (username and password)
4. That way, the Ebay (username password) entry uses the strongbox passkey and the Ebay (passkey) uses the keepassxc passkey.

KeePassXC - v.2.7.7
KeepassXC Browser Extension: v.1.9.0.1

Operating System: Windows & macOS

[droidmonkey]

@strongbox-mark I think we have an incompatibility

[varjolintu]

This is probably caused because of the change for the final release:
KPEX_PASSKEY_GENERATED_USER_ID is renamed to KPEX_PASSKEY_CREDENTIAL_ID

[kvn-be]

This is probably caused because of the change for the final release: KPEX_PASSKEY_GENERATED_USER_ID is renamed to KPEX_PASSKEY_CREDENTIAL_ID

I guess that has to be implemented in future releases because I tried to simply rename it, which didn't work.

[strongbox-mark]

Hey @droidmonkey @varjolintu - Ruh roh 😅 It looks like some incompatibility has creeped in for sure. I think we had sort of settled on field names after our discussion here:

#8825 (comment)

but this change will have broken compatibility:

KPEX_PASSKEY_GENERATED_USER_ID is renamed to KPEX_PASSKEY_CREDENTIAL_ID

Couple of options. Strongbox can take this into account when reading a database, and also we could use the new field name in new Passkeys going forward, but we'll still have a lot of our users with "invalid" Passkeys when used in KeePassXC.

Similarly, KeePassXC could look for the old name and the new name when getting the credential id so that users that have passkeys created with Strongbox, will be able to use KeePassXC?

Another option, and maybe this is a none runner, would it be possible on your side to revert this change? I wonder how many people out there now have the 'new' version of Passkeys?

[varjolintu]

@strongbox-mark We could add the old attribute name back for compatibility, but the saved data will use the new one. Then again, we could just rename the attribute if an old name is found?

@kvn-be reported that renaming the attribute did not do the trick, so I wonder what else could it be.

[strongbox-mark]

Yes @varjolintu - we've got nearly 6 months worth of users with passkeys using the old name now. So, definitely, if you guys can check for the old field name when reading the passkey, and use the new field name when writing.

We'll do the same on the Strongbox side, so we'll be back to compatibility.

[varjolintu]

Yes @varjolintu - we've got nearly 6 months worth of users with passkeys using the old name now. So, definitely, if you guys can check for the old field name when reading the passkey, and use the new field name when writing.

We'll do the same on the Strongbox side, so we'll be back to compatibility.

Let's do that.

And sorry for not informing about the change :/

[kvn-be]

This is probably caused because of the change for the final release: KPEX_PASSKEY_GENERATED_USER_ID is renamed to KPEX_PASSKEY_CREDENTIAL_ID

I guess that has to be implemented in future releases because I tried to simply rename it, which didn't work.

@droidmonkey @varjolintu @strongbox-mark

I just double checked the problem again.

It is infact the renaming that causes the issue.

If I use the name KPEX_PASSKEY_CREDENTIAL_ID , I am able to log in with Keepassxc but not with Strongbox.
After renaming it to KPEX_PASSKEY_GENERATED_USER_ID the login is possible with Strongbox but not with Keepassxc anymore

Another thing which I've noticed - when I'm trying to use the passkey - name KPEX_PASSKEY_CREDENTIAL_ID with Strongbox - safari crashes completely

[varjolintu]

@kvn-be I already provided a fix for this.

[kvn-be]

@kvn-be I already provided a fix for this.

Ah thanks just saw that. Just to clarify - for the time being I could just add a copy of the KPEX_PASSKEY_GENERATED_USER_ID and rename it to KPEX_PASSKEY_CREDENTIAL_ID so that i just have two custom fields that hold the value of the passkey?

[varjolintu]

@kvn-be I already provided a fix for this.

Ah thanks just saw that. Just to clarify - for the time being I could just add a copy of the KPEX_PASSKEY_GENERATED_USER_ID and rename it to KPEX_PASSKEY_CREDENTIAL_ID so that i just have two custom fields that hold the value of the passkey?

That should work as workaround, yes.

[kvn-be]

Thank you vm :)

Issue can be closed If its not needed anymore.

[varjolintu]

Thank you vm :)

Issue can be closed If its not needed anymore.

It will be closed after the fix has been merged.

[sirdavidxvi]

I think there might be a second field name compatibility issue between KeePassXC and Strongbox.

@strongbox-mark referenced the discussion on proposed field names in #8825 (comment) and one of the field names is KPEX_PASSKEY_USERNAME. However, when I save a passkey in Strongbox, the field name is KPXC_PASSKEY_USERNAME. The KPXC prefix is inconsistent with the other field names and the referenced discussion, which all use KPEX.

As a result, after upgrading to KeePassXC and the Firefox extension, entries for which I saved a passkey in Strongbox now display in with (- no username -) (see screenshot) instead of either the value in the Username standard field or the KPXC_PASSKEY_USERNAME additional attribute created by Strongbox, and the entries no longer correctly autofill the user name.

I just created a new passkey for Google on Strongbox to confirm it's still using the KPXC prefix. If I manually change the field name to KPEX_PASSKEY_USERNAME, then the user name displays and autofills as expected with the KeePassXC Firefox extension. This seems like more of a Strongbox issue but I thought it was relevant to this discussion so I wanted to mention it here.

KeePassXC - 2.7.7
KeepassXC Firefox Browser Extension: 1.9.0.1
Strongbox: 1.59.7
OS: Windows 10 22H2 & iOS 17.4

[strongbox-mark]

Oh no, that's my bad, what a mess! 🙈 @varjolintu - Sorry about this, can you check for this alternative field name:

KPXC_PASSKEY_USERNAME if KPEX_PASSKEY_USERNAME isn't present. Of course we should use KPEX_PASSKEY_USERNAME as canonical going forward.

Apologies.

[varjolintu]

Oh no, that's my bad, what a mess! 🙈 @varjolintu - Sorry about this, can you check for this alternative field name:

KPXC_PASSKEY_USERNAME if KPEX_PASSKEY_USERNAME isn't present. Of course we should use KPEX_PASSKEY_USERNAME as canonical going forward.

Apologies.

I can add that to the exception PR I did yesterday.