Prompt to insert yubikey if missing on autoreload

[DanMoJo]

I've tested the "Tools-Settings->General->Automatically reload the database when modified externally"

Expected Behavior

On my Ubuntu box, KeePassXC 3.2.1, correctly detects a change made by KeePassXC 3.2.1 on Windows.

I use OwnCloud to synchronise between the two hosts. OwnCloud detects the change and automatically overwrites the old file on the host(s) where there was no changes made.

Current Behavior

On my Windows box, a similar change to the file made on the Linux box, isn't detected.

And I just double checked it again, the file is synchronizing correctly from Linux to Windows box. Timestamp and size is updated. KeePassXC on Windows still don't reload.

Possible Solution

KeepassXC on Windows should detect the change.

However, when, I did this, I first changed the database on Ubuntu, Windows didn't detect this, then I changed the database on Windows (without reloading). When I then made the change on Windows, the Ubuntu box picked up the change, but did NOT merge the file, with the one it had in memory. Thus the change on the Ubuntu box was lost (if it wasn't because I also enabled the "Backup database file before saving" and then did a manual merge).

Steps to Reproduce (for bugs)

Change file on one host
Wait and see if host2 (Windows) detects the changed file

Context

I wish to be able to use only one KDBX file across numerous devices. I use:
"Safely save database files"
"Backup database file before saving"
"Automatically save after every change"
"Automatically reload the database when modified externally"

It would be awesome, if KeePassXC would maintain a user defined number of timestamped/named backups (in case OwnCloud connection fails while doing simultaneous changes on the two hosts).

And it would be even more awesome, if the default action was to "merge" when doing an "Automatic reload".

Also, one smaller issue, is that the "merge" or "synchronize" behavior has changed, compared to KeePass 2. In KeePass 2, you would not be prompted for password / keyfile, if only they were the same, when doing a synchronize. In XC it seems to default to prompting regardless of this being identical.

Except from this, big kudos for some lovely and long awaited improvements over the original KeePass 2 and KeePassX. And I also sent a little donation.

Debug Info

KeePassXC - Version 2.3.1
Revision: 2fcaeea

Libraries:

• Qt 5.10.1
• libgcrypt 1.8.2

Operating system: Windows 10 (10.0)
CPU architecture: x86_64
Kernel: winnt 10.0.16299

Enabled extensions:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[droidmonkey]

Good copy on your issue, I wonder why the Windows file watcher doesn't see it changed. I don't use owncloud but this works for me on Google Drive.

Also, merge and synchronize are very different. Merge makes no assumptions on the selected database to merge from, that is why you have to authenticate into it.

[Tau512]

bit of a +1 on this. i sync with 2 windows10 machines and a linux (fedora27) machine. last time i checked the two windows machines were reliably working as expected, but the linux host wouldn't update the database on change.
all machines are on keepassxc 2.3.1, and i use owncloud9.1 with the native clients to sync.

what this means is that i can do a change on the windows hosts, and over write them on the linux host if i do a force save on linux machine. Seems to work fine the other way; a change on the linux host does sync over to the windows machines.

windows hosts are using the installer from keepassxc website, linux machine was installed from src.rpm via website (keepassxc-2.3.1-1.fc27.src.rpm)

Simply closing and re-opening the database on the linux host gets the changes visible in the GUI.

[droidmonkey]

I cannot replicate this bug using owncloud. I setup an owncloud in a VM and successfully synced files with Windows 10 host. Changes made on Windows 10 showed up on linux and changes made in linux showed up on windows. Nothing fancy was done.

[Tau512]

I've double checked my clients. seems completely broken for me now.
all my machines have KPXC left running & unlocked and i rely sleep/suspend along with the OS lockscreen for a bit of safety.
I both amended an existing entry and added in a new entry last night on my linux client & saved the database as usual.
owncloud has synced the file to my work pc (windows10) - the file timestamp within the owncloud synced folder matches the save of the amendments i did on my linux machine last night, however KPXC has not automatically reloaded the database.

to get the updated kdbx contents working, i either need to close & NOT save the database and then re-open. Or lock & unlock the database which then reloads the kdbx file. (i haven't tested two machines side-by-side yet buy using Ctrl+S to see if that picks up the changes or overwrites)

KPXC settings on win10 machine: https://i.imgur.com/PDmweTo.png. Linux (off the top of my head) is configured identically.

just to add a bit more detail; i too use a yubikey for auth, but use the newer Browser Integration and not the legacy like the OP does. I cant see either of those affecting things, but for the sake of accuracy...

[droidmonkey]

Are the times of the two computers set correctly? Does it start auto loading again when you restart keepassxc?

@DanMoJo thank you for the donation. For what it's worth, the auto reload database feature does do a merge with the currently open database. This prevents you from losing data you have not yet saved.

[Tau512]

my work win10 and linux machines are both internet NTP'd - times match.
restarting kpxc does read the synced kdbx file, but the auto reload feature still appears to be broken.

ps, i hope DanMoJo doesnt think i'm hijacking. our symptoms appear to be the same so figured it's better to deal with it in one bug report than many.

[DanMoJo]

All good, happy to see I'm not the only one.

Though I decided that I will stop opening KeePassXC on Windows, it was actually a bit of a legacy thing for me, since I found KeePass 2 for Windows better than KeePassX and KeePass2 with mono was dreadfully slow.

And KeePassXC beats both dead in it's tracks. Sad it took me this long to discover XC.

But, I decided that I want to verify this again.

Just changed the file on Windows. Within a second or 2 after OwnCloud X uploaded and downloaded the file, I could see it reload in KeePassXC on Ubuntu.

And now changed it on Ubuntu. Checked that OwnCloud updated the file on the Windows host, and no reload in KeePassXC. Even minutes after, there is no reload.

You asked about time sync. Well, I also use NTP, so they are less than a sec apart.

However, my Windows host is in a different timezone (UTC) and my Linux box is in CET. I don't know if that could impact it, but I reckon it shouldn't since the timestamp is updated on the filesystem and it matches that of the OS.

There is one more curiosity about my system though. The Windows box, is actually a virtual guest (on another Linux box) and the file is shared using shared folders in VirtualBox. But I can't see that it should have any impact either, again the timestamp is updated and matches the OS. But what could make it behave different is that a "shared folder" from the VirtualBox host OS appears as a mapped network share. Perhaps KeePassXC treats files on network shares differently?

I will leave my KeePassXC open on the Windows box for a while and see if it ever reloads.

[Tau512]

i think i've isolated where the problem is... both OP and myself use yubikeys.

on device1: create new kdbx, use either password or keyfile for master key. add an entry, save, let owncloud/whatever sync up. leave the database open.
on device2: open this kdbx. add another entry and save (keeping the database open). wait for external sync. i found that the auto refresh is working as expected to device1.

do the same but using Challenge-Response master key, and it will fail on device1 when kpxc attempts the auto refresh on device1. In this case, the Yubikey remained on device2 so device1 could not revalid the C-R token and essentially fails. The keepassxc window does flicker but it's so fast i dont know exactly what it's doing. my suspicion is that it's trying to prompt to press the yubikey button, but fails as yubikey device is not present.

unfortunately i dont have 2 keys to test further with both sides having yubikeys present.

whats your thoughts on this - working as expected as keepassxc can't auth due to missing yubikey and simply a limitation of using this security method, or a bug as you don't need to re-auth using the password or (i assume) keyfile methods so essentially the same as no yubikey present?

[DanMoJo]

For what is is worth I don't use yubikey, I only use the key file and password.

[Tau512]

appologies for the confusion. i saw the 'Enabled extensions: Yubikey' and mis-read it as you were actually using that method.

[DanMoJo]

No probs

[DanMoJo]

Two hours has passed. Two changes to the file. And no reload on the Windows client.

And just to verify, I tried between the two host Ubuntu boxes, using OwnCloud to sync, it worked smoothly. So detection on the Ubuntu host, on which Windows runs as a VirtualBox guest, works as expected.

Personally, I'll just stick KeePassXC on Ubuntu, but I am still confident that there is some sort of issue, whether it is the Windows client, the network share setup or the timezone I don't know.

Let me know if you want me to test anything or need more info.

[droidmonkey]

I'll do more testing today given the additional information above. For @veehexx, lacking a yubikey will definitely cause autoload to fail, BUT it should be prompting you to insert it so that the new db file can be decrypted and merged into the open database.

[Tau512]

I see you've marked as 'not reproducible', and at the risk of taking a bug issue into a conversation.... why will a missing yubikey make autoload fail, when using a password allows autoload to work (for me at least). Neither option re-prompts for auth at autoload so it appears as inconsistency where password/keyfile works and yubikey doesn't.

going back to DanMoJo's bug, could his and my missing-yubikey-device autoload failure be something along the lines of an auth token not working quite right, so it's unable to automatically re-auth?

[phoerious]

When autoreload is triggered, it's most likely because the database file was changed externally, which causes the YubiKey challenge to change. Password and key file may still be the same (if not, they will fail as well), so we can reuse what we have in memory, but we can never reuse the old YubiKey response and need to reissue the challenge.

[Olli447]

May I ask whether there has been any progress on this issue?
I use Windows 10 on several devices. When the files have been synchronized, Autoreload doesn't ask to insert the Yubikey and fails instead.

By the way, a similar event occurs when KeePassXC is terminated by shutting down the PC. KeePassXC then seems to forget that there is a yubikey for that database and tries to save without the yubikey.

[droidmonkey]

No movement yet, but not forgotten.

[Olli447]

Thanks for your efforts!