Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potentially connected issue between current KeePassXC version and Strongbox virtual hardware key functionality #10727

Closed
2 tasks done
unicorn855 opened this issue May 10, 2024 · 1 comment

Comments

@unicorn855
Copy link

unicorn855 commented May 10, 2024

Overview

Saving a .kbdx database file which uses a hardware key as part of the composite master password in KeePassXC version 2.7.8 appears to lead to being unable to use a virtual hardware key programmed with the same HMAC secret to be used to unlock that database again. Using a physical hardware key still works.

Steps to Reproduce

  1. save a database secured with physical hardware key (HMAC challenge-response)
  2. attempt to open that database in Strongbox (which uses virtual hardware keys (in my case, that is used to auto-fill on iOS) via virtual hw keys

Expected Behavior

database should open as expected

Actual Behavior

an error is thrown about the credentials being incorrect

Context

Please refer to the thread linked just below for further information regarding this, I will also gladly provide more specific input if/where needed. I am still undecided whether the root cause of this less with any of the recent changes to KeePassXC, but it seems reasonably likely, which is why I cross-referenced both issues.

KeePassXC - Version 2.7.8
Revision: f6757d3

Qt 5.15.11
Debugging mode is disabled.

Operating system: Windows 11 Version 2009
CPU architecture: x86_64
Kernel: winnt 10.0.22635

Enabled extensions:

  • Auto-Type
  • Browser Integration
  • Passkeys
  • SSH Agent
  • KeeShare
  • YubiKey
  • Quick Unlock

Cryptographic libraries:

  • Botan 3.1.1

Operating System:

Windows 11 Home
Version 23H2
Installed on ‎12/‎05/‎2022
OS build 22635.3575
Windows Feature Experience Pack 1000.22700.1011.0

Preliminaries

I have ensured that:

  • I am running the latest version of Strongbox on the App Store by searching for Strongbox and clicking into it to see the Update button (or not)
  • I have performed a full restart of my device no matter how annoying that is

Versions

** On iOS:**

  • Device: iPhone 13 Pro
  • OS: iOS 17.4.1

** Strongbox Version **

  • Version: 1.59.10

Describe the bug

When attempting to Auto-fill, strongbox complains that my credentials are incorrect (I am using a virtual Hardware key configured for use with auto-fill only). However, when opening the same database 'normally' in strongbox (with the physical hardware key), I can open the database without problems.
I have recreated a fresh virtual hardware key with the correct HMAC secret and restarted the iPhone and the issue still persists.

To Reproduce

Steps to reproduce the behavior:

  1. Navigate to any password field where auto-fill should fill in credentials.
  2. Attempt to unlock db with virtual hardware key.
  3. Notice error that credentials are incorrect.

Expected behavior

Database should unlock given the correct credentials are provided.

Additional context

Could this perhaps be related to any changes introduced in the most recent version of KeePassXC? I only noticed this behaviour after updating to version 2.7.8 yesterday (and subsequently refreshing my db file in Strongbox).

Edit:
Do you know if disabling virtual security keys is a feature of Apple's Stolen Device Protection? Upon further reflection I remembered turning this on (and setting it to always be enabled) a few days ago (and since then I didn't need to log into anything on the phone, so I might not have noticed).

Edit#2:
After disabling Stolen Device Protection, the issue still persists, so this seems unlikely to be related.
Also, I just updated to 1.59.10 with no change either.

Originally posted by @unicorn855 in strongbox-password-safe/Strongbox#780

@unicorn855
Copy link
Author

After some more testing and playing around/repeated resynchronisation, the issue appears to have resolved itself, so I'll close this now :-).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant