Backup YubiKey not working with a locked database due to wrong serial number

[mbrausen]

Overview

I have my database configured to require a YubiKey token. Due the database's importance I have configured a backup YubiKey according to the documentation.

To test things, I've locked the database and tried to unlock it. During the course of unlocking KeePassXC throws the "Error while reading the database: Unable to calculate database key: General: Could not find interface for hardware key with serial number ###. Please connect it to continue." error message and keeps the database locked. This is reproducible.

After a while I figured this only applies to a locked database that has been opened with device with a different serial number (obviously) and that quitting and reopening KeePassXC will actually enable the device with "the other" serial number.

This is not a duplicate to #10656 (but somewhat related to the topic).

Steps to Reproduce

1. Open database using the primary YubiKey.
2. Lock database.
3. Remove primary YubiKey from system, plug backup YubiKey.
4. Try to unlock database.

Expected Behavior

Either unlock the database with the backup YubiKey OR display a hint that exiting and reopening KeePassXC will enable a device with a different serial number.

Adding a paragraph to the documentation explaining the behavior (and probably the reason to require a specific serial number for database unlocking) would also do no harm.

Actual Behavior

Database stays locked and the error message gives user no clue that this problem could be resolved by restarting the application.

Context

The behavior is not exactly faulty though it's very irritating, especially because it is not documented.

I imagine the following scenario: When I go out for lunch, I lock my device and database. During lunch I lose my YubiKey and notice when I'm back at my desk. I'm happy to have the backup key in my desk and plug it – and then run into this problem. Not sure I'll be in a mindset to figure out the solution quickly.
An enhanced error message would likely improve the user experience and get me back working more quickly.

KeePassXC - VERSION
Revision: 2.7.9
Operating System: macOS (14.7.1)

[droidmonkey]

Are you using quick unlock? That's the only scenario when we care about the previously used serial number on unlock.

[mbrausen]

Yes, that's where I have noticed the described behavior. (To be exact, until now I had not been aware about an alternate mechanism since quick unlock was what it ever defaulted to. Being aware, I now exited quick unlock and can confirm the standard unlock accepts the changed YubiKey without error message).

Out of curiosity, what is the quick unlock caring about the serial number while the other does not?

[droidmonkey]

We have to "bind" to a specific yubikey since we need that one to unlock the database. We have no way of knowing that some other yubikey is actually a backup/duplicate unless we try each slot on each key, which can take many seconds depending on how many keys are detected.

Either way, this is expected behavior, and simply canceling out solves the problem.