Can't we store the flag inside KeePassXC? For new passkeys, we default to true, but when we use existing passkeys, we use whichever value is stored or false if there isn't any.

Can't we store the flag inside KeePassXC? For new passkeys, we default to true, but when we use existing passkeys, we use whichever value is stored or false if there isn't any.

I'll try if that's possible to do. And I missed setting the default flag in BrowserPasskeys::buildAuthenticatorData().

Only problem with that is if other clients are not storing the flags then we would still flip flop the BE flag.

True, but since there's no official spec, everyone does kind of their own thing anyway.

The only way to get this to work is to store the flags as a new attribute during register, as phoerious already suggested.

Since KeePassium is already doing that, I think that's the way to go. Wasn't aware of this issue (or forgot about it): keepassium/KeePassium#444

Since KeePassium is already doing that, I think that's the way to go. Wasn't aware of this issue (or forgot about it): keepassium/KeePassium#444

I agree. We need to set BS flag true as well. I'm making the changes today.

If we default to true if it's not set, we could offer users a fallback if authentication fails.

If we default to true if it's not set, we could offer users a fallback if authentication fails.

Made the core changes. Not sure how we should offer the possible fallback. The popup dialog could have an option "Ignore backup flags" but that will probably confuse a lot of users. Adding attributes manually with false values is also a bit cumbersome.

I guess it's fine, you can manually add those entries if needed. We should mention that in the changelog.

@varjolintu The current check expects true, but both KeePassDX and KeePassium use 1. We need to align this behavior or add compatibility for both.

Uh, this is annoying. I check the KeePassDX source code and "1" seems to be indeed the value they use, but String.toBoolean() would also convert "true" to true. https://github.com/Kunzisoft/KeePassDX/blob/60fea86e69ed9eeaaad2d163e68f4adfc3d1029d/database/src/main/java/com/kunzisoft/keepass/database/element/security/ProtectedString.kt#L78

This is where the conversion happens in KeePassium. I'm not entire sure, but this might also recognise "true". https://github.com/keepassium/KeePassium/blob/4dc000da761217d1f8fab7ac40c4195d7b2ff37b/KeePassiumLib/KeePassiumLib/db/passkey/Passkey.swift#L104

@keepassium could you shed light on this?

Not too late to use "1" instead of true

Not too late to use "1" instead of true

Changed from "true" to "1". #13122

@keepassium could you shed light on this?

It does expect a "1" and won't parse "true". The rationale was the relevant part of the specs refers to flags as numeric values.

Ok, thanks! We'll default to "1" also, but accept "true" as well.

The notes of the latest release state that it MAY BREAK EXISTING PASSKEYS. What does that mean? Reading the comments here or those in the corresponding issue do not really clarify. The blog post states:

Important note about the new passkey flags: Previously, the BE and BS flags were hard-coded to false. We now default to true and store the values with the entry for new passkeys. This may break existing passkeys for which the flags were not stored, since the values are considered immutable. To fix this, users can add the following two string attributes to an entry (under “Advanced”): KPEX_PASSKEY_FLAG_BE=0 and KPEX_PASSKEY_FLAG_BS=0 to restore the previous behaviour.

Does that mean that these attributes are set to 1 even for existing passkeys?
I just tested my stored passkeys from Google and passkeys.io, and both of them continued to work.

keyword: MAY

We have no idea, because its on the server side to decide to accept or reject the passkey if the BE flag changes.