Using Multiple Yubikeys Is Unstable At Best

[HUGHUSR]

Have you searched for an existing issue?

• [x] Yes, I tried searching and reviewed the pinned issues

Brief Summary

There are multiple issues using KeePassXC when more than one YubiKey (with touch required) is inserted into the system, especially when trying to unlock a previously open kdbx. Among the issues are:

1. No keys are presented when trying to open a kdbx file. Or, not all keys are presented, A scan for keys usually only identifies one key, not all keys present.

2. Any key(s) that are found are often not usable, throwing the error shown in the attachment.

When this error occurs, the key is plugged into the system. When it occurs on a save, the key has not been removed from the system, yet KeePassXC does not find it despite its previous use. Unplugging the key and plugging it back in does not fix this problem most of the time.

3. When problem 2 occurs, multiple retries MAY eventually get the key to work.

4. Sometimes the above error is thrown when trying to save after editing an entry. This apparently leaves the kdbx in an unknown state, and there is no simple way to retry the save, as KeePassXC seems to think the kdbx file has been saved. If you try to close the kdbx file, you are not prompted to touch they key.

5. WORSE, sometimes when problem 4 occurs, the data is actually saved and other times it is not.

The only way to successfully correct the above issues is to close KeePassXC, remove all YubiKeys and reinsert them, then restart KeePassXC. This is problematic, as other apps which are using the SmartCard feature of one of the YubiKeys quits (for valid security reasons) if their YubiKey is removed.

Steps to Reproduce

The most consistent way to reproduce this problem is to:

1. Insert two YubiKeys configured with Challenge-Response and required Touch.
2. Open a kdbx file which requires one of the keys.
3. Switch user to a different user (which automatically closes the kdbx file).
4. Switch user back to the original user.
5. Attempt to reopen the kdbx file.

Expected Versus Actual Behavior

Expected: To correctly automatically recognize all YubiKeys present and have those keys function properly without having to unplug them and plug them back in.

Actual: Doesn't find any YubiKeys. Scan doesn't find all YubiKeys. YubiKeys found are often not functional. Keys may work with retries, or they may not. Retries are often not easily performed, especially on 'save' operations. When a YubiKey error occurs on save, the kdbx file may or may not have been actually saved.

KeePassXC Debug Information

KeePassXC - Version 2.7.10
Revision: b342be4

Qt 5.15.11
Debugging mode is disabled.

Operating system: macOS 14.7
CPU architecture: arm64
Kernel: darwin 23.6.0

Enabled extensions:
- Auto-Type
- Browser Integration
- Passkeys
- SSH Agent
- KeeShare
- YubiKey
- Quick Unlock

Cryptographic libraries:
- Botan 3.1.1

Operating System

macOS

Linux Desktop Environment

None

Linux Windowing System

None

[droidmonkey]

What keys are you using, version/type?

Given the prevalence of use and lack of negative feedback like yours, I am leaning much more on your keys or your system are the problem and not keepassxc.

[HUGHUSR]

YubiKey 5C Nano Firmware 5.4.3

I should add that I don't have an issue when using a single key at a time. It is only when I have multiple keys plugged in.

EDIT: I should add that I have touch enabled on all of my YubiKeys for Challenge-Response.

[droidmonkey]

@phoerious do you run into this at all?

[phoerious]

Will have to check. I have two YK5 that I use regularly (no Nano), but I never have them plugged in at the same time.

[HUGHUSR]

I think the key here (no pun intended) is while the kdbx file is open, to switch to another user, spend a little time there, then switch back to the original user, and resume changes to the kdbx file (which was autolocked).

Also, is there a way for me to enable detailed debugging information which would capture what is occurring here?

[HUGHUSR]

A little more information...

I just ran into the problem again where KeePassXC said it couldn't open one of the YubiKeys. Here's the exact sequence of what happened, with an additional verification step added.

1. Switched back to a user. KeePassXC showed the kdbx files locked (as expected), gave the password prompt for the last kdbx file I was using, but showed no keys.
2. Clicked on the button to refresh the keys, and the one key that I needed is all that showed up.
3. Entered the kdbx password and selected the key. However, KeePassXC now claimed that it could not find the key it had just discovered seconds earlier. (Error message in original posting.)
4. I opened Yubico Authenticator and it showed both keys present. I then closed that app.
5. I again tried to unlock the kdbx file and it again failed.
6. I tried once again to unlock the kdbx file, and it opened successfully.
7. I then tried to unlock the other previously-opened kdbx file. When switching to its tab, it showed no keys found.
8. I refreshed the keys, and the same key which previously showed up, again showed up this time. It was the key that I needed, so I tried to unlock the kdbx file. It took 4 attempts before it finally opened.
9. I then tried to open a third kdbx file. When the password prompt showed up, it presented the full list of YubiKeys present. I had no problem opening that kdbx file.

So, when opening a kdbx file from scratch, it appears that KeePassXC must follow some different logic path to determine the present keys. This appears to be reproducible, where kdbx files which were autolocked don't discover all keys, but opening a different (closed) kdbx file finds all the keys present. (At least I was able to reproduce it 3 times in a row.)

[droidmonkey]

when opening a kdbx file from scratch, it appears that KeePassXC must follow some different logic path to determine the present keys.

This is simply not true, unfortunately

[HUGHUSR]

I have discovered a "workaround" for when KeePassXC stubbornly refuses to "find" a key which is plugged and was previously used to open/unlock the kdbx file.

That workaround is to attempt to open a different kdbx file (OPEN, not unlock!). Bringing up open's password dialog finds all inserted keys. If you now simply close this kdbx file (no attempt to unlock it), the previous kdbx file which was continually failing to find the key will now find the key and work. This fix works even when unplugging a key and plugging it back in fails.

Also, when KeePassXC stubbornly refuses to find a key, move the key to another unused USB-C port has the same results as unplugging the key and plugging it back into the same port: KeePassXC will still claim the key is not plugged in.

[HUGHUSR]

when opening a kdbx file from scratch, it appears that KeePassXC must follow some different logic path to determine the present keys.

This is simply not true, unfortunately

Well, mine was simply a speculative guess on what made logical sense based upon behavior.

I have a new MBA that I've yet to find time to set up. I'll try to get it configured and test this out on that box, hopefully in the next couple of days. I would hope that should answer the question of whether this is a platform issue or an app issue (or even a little of both?).

[HUGHUSR]

This is 100% reproducible on my new MBA. The only hardware in common between previous reports and the MBA are the YubiKeys. Furthermore, I have a duplicate set of YubiKeys (each YubiKey is identically configured to another YubiKey) and the problem occurs regardless of whether using the primary or backup YubiKey(s).

Some additional observations of the problem:

1. Sometimes when KeePassXC claims it cannot find a key, I notice the key is being interrogated (lights up briefly) either concurrent with or shortly after the "can't find key" error is thrown. When this occurs, a retry of the save will almost always work.

2. If I have multiple KDBX databases open, quite often when one database repeatedly cannot find a given key, another database using the same key has no problem using the same key. In this circumstance, I notice that the "can't find it" database appears to never interrogate any keys (none briefly light up). Also, once a database gets into the state where it never interrogates the key, the only correction is to discard changes, lock the database (or close it), and unlock (or re-open) it--which fixes the problem. (Note: When I say 'never interrogates', I base that upon the fact that when interrogated, a YubiKey will very briefly light up, and I use 'never interrogates' to mean the key never briefly lights up.)

QUESTION: Is there some way to enable a debugging trace which may help pin down what is occurring? If so, how do I enable it?

[droidmonkey]

I truly believe that this PR will fix your problem: #12053

I think what is happening in your case is a yubikey is being "locked up" in discovery and preventing it from being used afterwards.

[HUGHUSR]

Reading the details and history of that issue, it makes perfect sense. Admittedly, I'm not a Git user... I'd like to try a 2.7.11 beta, and I searched for a beta or nightly but didn't find one. Is there a link where I could download a copy to test? Thanks!

[droidmonkey]

Once we merge that PR you'll be able to test it from https://snapshot.keepassxc.org

[HUGHUSR]

Please let me know when it is ready for testing. Message ID:

[Zackarie78]

How exactly can I connect two Yubikeys to one Keepass XC database? Unfortunately, I cannot find any information on this. I tried connecting two keys, but unfortunately only one key works. I used the same encryption key for both, but it does not work.

[droidmonkey]

You cannot register more than one key to each database. If you create multiple keys with the same secret on them, you must use the same key you unlocked the database with to save it. You can use either key to unlock the database.

[HUGHUSR]

(Oops! Ninja'd by @droidmonkey !!)

First, you can only use one Yubikey per database.

The issue in this bug report arises when you have multiple Yubikeys plugged into your computer (or, at least multiple Yubikeys plugged into a Mac).

I use multiple Yubikeys because I have different KDBX databases with different scope/security requirements. But, each KDBX database only has one challenge-response key (unique slot#-keySerial# Yubikey identifier). And, each Yubikey identifier has a different challenge-response secret. (Note: Be sure you backup your secrets! I make 3 identical copies of each Yubikey [same c-r secret] and each set's secret is archived in a KeePassXC database entry. That is, I have 4 sets of unique Yubikey secrets, but 12 total Yubikeys.)

Also, you have 2 slots per YubiKey where you can store c-s secrets, but each KDBX database has to have a unique slot#-keySerial# Yubikey identifier. You can use the same Yubikey identifier across multiple KDBX databases, but only one Yubikey identifier per KDBX database.

If you are using "encryption keys" then you are setting up your Yubikeys for KeePassXC incorrectly. You need to use challenge-response to properly configure KeePassXC for Yubikey. This is a very basic "How to Yubikey for KeePassXC" guide. It is probably more basic than you need, but it covers the major details.

I hope this helps!