KeePassDX
KeePassDX copied to clipboard
Kunzisoft
Allow the app to continue in background even when swiped away.
Hello. I often tend to close all background apps to free up memory, but with KPDX, doing so closes the database. AFAIK there's no setting to allow the app to daemon-ify.
This is what the application did several versions ago, but I was asked to do the opposite, which seemed to make more sense because the user is unequivocally asking to kill the application.
Maybe the easiest way is to put a setting in the parameters to let the user choose what is best for him.
That's exactly what i mean, if you or some other contributor were to create a PR to implement this setting, it would be fantastic.
On May 19, 2022 10:19:45 AM GMT+02:00, "Jérémy JAMET 'notifications at github.com'" @.***> wrote:
This is what the application did several versions ago, but I was asked to do the opposite, which seemed to make more sense because the user is unequivocally asking to kill the application.
Maybe the easiest way is to put a setting in the parameters to let the user choose what is best for him.
-- Reply to this email directly or view it on GitHub: https://github.com/Kunzisoft/KeePassDX/issues/1334#issuecomment-1131387911 You are receiving this because you authored the thread.
Message ID: @.***>
Hello. I often tend to close all background apps to free up memory, but with KPDX, doing so closes the database. AFAIK there's no setting to allow the app to daemon-ify.
May I ask kindly about your use case? And is it just a habit to close all apps? I don't understand the benefit when having automatic memory management. Do you leave keepass unlocked all the time?
I'm one of those people who thinks features like leaving it unlocked by a background daemon is dangerous in a sec product. Even as an option.
You will never be sure if the app is closed/locked when it's closed. And couldn't it make new problems possible due to a more complex software architecture?
This would be a nice option to have, but it should definitely be opt-in in my opinion. I have my databases set to lock after a given time, but I don't want to have to keep the app open in the foreground during that time to avoid having to unlock them every time I fill creds.
I understand why some may think it counter-intuitive -- security-wise, at least -- to have your database open in the background indefinitely, and I agree. That is why I have my databases set to lock after some amount of time. Also, -- regarding the user telling the app to close -- after the user opts-in to the setting, they can manually lock a database in-app if they wish to do so early.
I recently made the switch from 1password to a self-hosted solution using KeePass databases, and I am really liking KeePassDX/XC. Thank you all for your contribution to the project!
I want to use KeepassDX but the current behavior prevents me from doing so and I stick to Keepass2Android.
I use a Yubikey in conjunction with a password for my database which is shard on many devices by NextCloud. On Linux I use KeepassXC. Both, KeepassXC and Keepass2Android allow me to keep the DB open. With Keepass2Android I unlock my DB with my password and the Yubikey. I can setup Keepass2Android so I can quit it and reopen the DB with fingerprint.
With KesspassDX I can unlock by fingerpint but in addition I always need my Yubikey. This major annoyance keeps me away from KeepassDX.
It's always a balance between security and usability, and here the behavior won't be changed by default, because killing the application with a swipe clearly means closing the database. I'm thinking about implementing the setting to prevent the base from closing during the swipe, but this requires a lot of testing.
In the case of Yubikey, this is a strong security mode. It's very surprising to leave your database open when you're using a very strong security mode. In any case, you can change the timeout in the settings.
My DB resides on a network storage on the internet. This is the reason for using the Yubikey. The DB needs to be protected while on the internet storage. On my devices I neither want nor need this. The trade off is the one time unlocking with the Yubikey. When I'm at e.g. at home my phone is always with me, my Yubikey is't. When I need a password in this case I need to go and get my Yubikey to unlock. For me a major annoyance which prevents me from using the in many other aspects far better KeepassDX. With Keepass2Android this issue does not exist.
Keepass2Android has an other weakness. The DB is writable without the Yubikey. For me KeepassXC offers the best balance of security and usability. With KeepassXC I need to tap my Yubikey when opening the DB. Then it stays open for the login session, no matter if the screen gets locked or not, but when I want to write to the DB I've to tap the Yubikey again.
I'm planning to make a physical key emulator in the KeyDriver app, but it will take some time to build.