passkey incompatibility with keepassxc / bitwarden

[daaku]

Description

I'm trying to migrate from BitWarden to a combination of KeePassXC on Linux and KeePassium on iOS. I've successfully imported my BitWarden data into KeePassXC, which is synced via Dropbox (native integration) to KeePassium. On Linux/KeePassXC, the Passkeys imported from BitWarden work as expected. These imported passkeys do not however work with KeePassium.

The behavior I see is that when the browser triggers a passkey get request via navigator.credentials.get, KeePassium shows me the iOS "Sign In to "website" with your passkey for "user"? prompt with the "Use Passkey" and "More Options" buttons. At this point, clicking "Use Passkey" does nothing - no error, no progress. Tapping the button just silently does nothing. I can keep tapping it and this dialog doesn't go away.

Clicking "More Options", then "More from KeePassium..." and "Continue" goes through the flow, but the Promise from navigator.credentials.get is rejected with the typical "not allowed or denied" error.

Adding a new passkey and using that works, this is just for imported passkeys from BitWarden. I'm trying to migrate my extended family for 9 to from BitWarden and having everyone create new keys isn't an appealing option.

The only noticeable difference I see in the additional attributes is KPEX_PASSKEY_FLAG_BE=1 and KPEX_PASSKEY_FLAG_BS=1. So I tried to manually add these to an entry I imported from BitWarden, but it didn't seem to help resolve the issue.

How to reproduce
Steps to reproduce the behavior:

1. Go to https://www.passkeys.io/, create a passkey in BitWarden.
2. Export your BitWarden data.
3. Import it into KeePassXC.
4. Open that DB in KeePassium.
5. Try using that passkey on iOS Safari.

Expected behavior
Expected passkey to work.

Environment:

• Device: iPhone 17 Pro
• OS: iOS 26.5
• KeePassium App Version: 2.5
• KeePassXC Version: 2.7.12

[daaku]

My current best guess is that the PEM data is marginally mangled in the import into KeePassXC. Notably the -----END PRIVATE KEY----- isn't on it's own line (real bug), and there is no trailing newline (possibly irrelevant). KeePassXC seems to work around these issues and manage to use the passkey anyway (or possibly Brave is, but iOS Safari isn't?). Unfortunately manually fixing those two issues in an imported entry still demonstrates the same behavior.

[daaku]

Confirmed the issue - the PEM data imported from BitWarden using KeePassXC is all in one line, not just the trailing bit as I mentioned in the last comment. This works fine on at least Brave/KeePassXC, but KeePassium silently fails to handle this.

I manually:

1. Put -----BEGIN PRIVATE KEY----- on it's own line.
2. Put -----END PRIVATE KEY----- on it's own line.
3. Split the data into lines of no more than 64 characters.

This made the key work in KeePassium on iOS/Safari.

I'm not sure where this should be fixed, here or KeePassXC and it's BitWarden process. RFC 7468 requires the wrapping - but maybe being lenient to match KeePassXC wouldn't be a bad thing?

[daaku]

This can help anyone else facing the same issue to fix their data: https://gist.github.com/daaku/00f5f10e6c7282a0577b8484e857c07a

[keepassium]

Thank you for the report and thorough analysis!

This is odd, though. KeePassium's PEM parser ignores newlines and trims leading/trailing whitespaces. So it should already be resistant to this kind of issue.

Would you mind sharing a sample database with just a demo passkey?

[daaku]

I can reproduce this trivially using any passkey where I remove all the new lines in the PEM data.

1. Go to https://www.passkeys.io/.
2. Create passkey.
3. Remove all newlines from KPEX_PASSKEY_PRIVATE_KEY_PEM.
4. Try to login on iOS/Safari.

I'm using the App Store build - v2.5 - is this something fixed after that?

[KyleDSwarner]

I'd like to chime in and confirm @daaku's findings - I also recently migrated from Bitwarden and have the exact same problem. I didn't use his code above, but manually adding newlines & ensuring the key's rows are exactly 64 characters in length did indeed fix the problem.

I've attached a sample database (compressed in zip so Github will let me upload it) with a single passkey for Passkeys.io with the newlines removed and confirmed that I see the issue when using KeyPassium. Password for the database is 'test'.

passkey-test.zip

[keepassium]

@KyleDSwarner , thank you, that helped.

It seems the issue depends on passkey's algorithm. Apple's CryptoKit library provides a built-in PEM parser for P256, and that's what KeePassium uses. However, there are no built-in parsers for Curve25519 and RS256, so KeePassium relies on its own lightweight and rather forgiving implementation.

The offending key is a P256, so it's processed by Apple's RFC-strict parser :) I'll add KeePassium's parser as a fallback there.