Saving Database fails with Yubikey 2FA Challenge-Response

[stmllr]

I have a database with Yubikey 2FA Challenge-Response enabled.
If I remove the yubikey from the USB port and re-insert it, then saving the database fails with

Writing the database failed.
Unable to issue challenge-response.

This error also occurs, after the OS woke up from the suspend-to-ram state.

Expected Behavior

Database is always saved

Current Behavior

Database is only saved, when Yubikey has never been removed before.

Possible Solution

Scan for Yubikey before Saving Database

Steps to Reproduce (for bugs)

1. Create a database and enable Challenge-Response with Yubikey inserted
2. Add entry
3. Save database --> success
4. Remove Yubikey from USB port
5. Add entry
6. Re-Insert Yubikey to USB port
7. Save database

Result: Error

Writing the database failed.
Unable to issue challenge-response.

Workaround

1. ...
2. ...
3. ...
4. ...
5. ...
6. Re-Insert Yubikey to USB port
7. Open "Change master key" dialog
8. Activate "Challenge Response" checkbox
9. Cancel "Change master key" dialog
10. Save database

Context

Build: -DWITH_XC_YUBIKEY=ON

Your Environment

Debian Linux Jessie
KeePassXC - Version 2.1.4
Revision: ad79162

Libraries:

• Qt 5.3.2
• libgcrypt 1.6.3

Enabled extensions:

• KeePassHTTP
• Auto-Type
• YubiKey

[stmllr]

The setting "Remember last key files and security dongles" is activated

[mritun]

This is an extremely annoying problem while using YubiKey with KeepassXC (my prime reason for using XC in the first place). I shall take a look and see what can be done.

[droidmonkey]

Its fixed in a PR already

[stmllr]

PR #880 fixes this issue for me. Thanks @droidmonkey

[stmllr]

didn't see the fix because there was no cross reference in the pull request into here.

[Tormen]

Hi,

I ran into this as well. Glad to see that there is already a solution for this in the making.

I just noticed the "MERGED" ... so perfect: The fix seems released since 3 days in version 2.2.1 :)

Thanks a lot!

Tormen

Also @stmllr : Thanks a lot for the described workaround! ... I had not yet succeeded in finding one ;)

[droidmonkey]

Looks like this can be closed.