Quick Unlock stops working with Watch-ID after sleep

[findus]

Overview

Unlocking KeepassXC with the apple watch works flawlessly until my Macbook enters sleep. After that only Touch-ID continues working.

Steps to Reproduce

1. Use a Macbook with an Apple-Watch attached, enable that DB should be blocked after sleep/lock
2. Unlock the Database and lock it again, quick unlock with the apple watch should work.
3. Let the mac sleep by closing the lid or click the sleep menu entry
4. Resume from sleep and click the quick unlock button

Expected Behavior

Watch-ID should also work after sleep

Actual Behavior

Watch-ID stops working after sleep

Context

I tried to debug the problem with the current master branch but I am not really that technically savvy with C++ and the used APIs from Macos. Does the App needs to be signed to have access to the Keychain?

KeePassXC - Version 2.7.4 Revision: 63b2394

Qt 5.15.6 Debugging mode is disabled.

Operating system: macOS 13.0 CPU architecture: arm64 Kernel: darwin 22.1.0

Enabled extensions:

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

Cryptographic libraries:

• Botan 2.19.2

Operating System: macOS

[droidmonkey]

The program needs to be signed to access the keychain. Not sure why touchid would work and not watch after sleep, they use the same exact method for storing and retrieving keys. This could be a bug on macos side. Does watch work again after canceling quick unlock and doing a full unlock again?

[findus]

Hi,

After writing this Bug Report I could not quite reproduce it again as I was able to before. It seems a very inconsistent interaction with a docking station.

After you answered I tried to test what you mentioned only to find out that now everything worked out perfectly. I attached the mac to a Dock and let it sleep for few hours and as I woke up I unlocked it and tried again -> still success.

I am not that familiar with the implementation details but keepass- or the macos side might sometimes get confused if Touch-ID devices (Watch, Fingerprint-Sensor) are getting inaccessible or vice versa, especially if the laptop is sleeping while (un)plugging something.

Sometimes macos then seems to forget that the Watch is still connected and reports that only Touch-ID is available, when the mac is connected to a dock and the lid is closed the macos implementation assumes that the button is inacessible and responds to keepass that no touch-id hardware is currently available, so keepass only shows the password-textfield.

Examples that I managed to reproduce:

• Macbook not connected to dock and lid open -> unlock db -> close lid -> connect to dock -> DONT open lid and login with external keyboard/watch (keyboard without touch-id support)
  • if watch is detected -> watch-id works and you can login
  • if watch is not detected -> touch-id fails completely, you have to login with password and after keepass restart touch-id setting button disappears in settings (because sensor is inaccessible)
• Same as above but lid is open:
  • if watch is deteced -> touch-id dialogs prompts and touch-id and watch-id works
  • if watch is not detected -> only touch-id works -> after restart touch-id setting is visible in menu
• Macbook Connected to dock -> lid closed -> send to sleep -> unplug it from dock and open lid -> keepass show password prompt but after pressing unlock touch-id still works, but only if it was started at a time were touch-id hardware was detected properly. If not (lid closed, dock and watch disconnected) it will only work after restarting keepass.

Sometimes after I do anything above the watch ocassionally stops working and I have to restart the mac to get it back to work for keepass (the watch still works for user session unlocking), touch-id works all the time as long as the lid is open, right now it seems random to me but maybe I’ll find a pattern at some time.

Touch-ID only or Touch- and Watch-ID prompt

Watch-ID only prompt (if lid is closed)

[droidmonkey]

This isn't something we can fix, unfortunately. It would appear to be a macos problem at this time. We just call their APIs to kick everything off.