Keepassxc: Allow unlocking KPXC database using passphrase stored in system keyring

[lofidevops]

User story: I am a GNU/Linux desktop user used to storing secrets (passphrases for SSH keys, GPG keys, etc) in my system keyring. I want to use my system keyring to store KPXC passphrases, so that unlocking any encrypted data has the same workflow.

Expected Behavior

New file

• Double-click on a new KPXC file
• Prompted for passphrase with an option to "Remember this passphrase"
• Tick the "Remember" option
• Passphrase is stored in system keyring
• (Prompted to unlock system keyring if it is currently locked)
• KPXC file is opened

Known file, system keyring locked

• Double-click on a known KPXC file
• Prompted to unlock system keyring
• KPXC file is opened

Known file, system keyring already unlocked

• Double-click on a known KPXC file
• KPXC file is opened

[eNTi]

OT: it's KPXC not KXPC. :)

[zzflux]

I think it'd be cool to allow storing the master password, the keyfile, OR both using the keyring. Currently, if the user uses a keyfile on Linux, there's really no way to easily protect this file more than any ordinary file (no way to e.g., transparently encrypt it like on Windows via NTFS encrypted files).

[droidmonkey]

I believe this was implemented with #2726

[lofidevops]

@droidmonkey I'm happy to test it out! Should I see it in 2.4.3?

[droidmonkey]

No this feature will be in 2.5.0. You can test it out using our snapshots: https://snapshot.keepassxc.org

[Gigadoc2]

I'm not sure if #2726 is implementing this, isn't this the other way around?

This seems to be a duplicate of #1405 instead: Unlocking KPXC with the system keyring.

EDIT:
This is similar to #1405, but goes beyond that. If KPXC itself asks the passphrase with libsecret, it would not only be possible to unlock the database at login, but lock and unlock it after suspend and screenlock as well.

[droidmonkey]

2726 allows KeePassXC to act like the system key ring, thus it obviates the need to move your secrets from KeePassXC into the actual key ring. Which, in my opinion, doesn't make any sense, why use KeePassXC in the first place if you want to expert everything to another service.

[Gigadoc2]

This proposal is only asking for the unlock passphrase to the Keepass database to be stored in the system keyring, not the content of the Keepass database.

I can see an use-case for that (which I am interested in myself):
With the setup described in https://github.com/keepassxreboot/keepassxc/issues/1405#issuecomment-359172794, one can unlock KPXC at login, but not afterwards. If KPXC itself would query the system keyring, one could lock KPXC on suspend or screen lock and then have it unlock automatically on screen unlock. Some system keyrings (gnome-keyring) already support unlocking themselves with the login password (if login password == keyring passphrase), and they can be made to lock themselves on suspend and screen lock (that was the default some time ago, unfortunately is not anymore).

An alternative to achieve the same would be to create a PAM module for KPXC and unlock it the same way the system keyring is also unlocked. This may even be the better option, as otherwise, when KPXC is asking for its passphrase with libsecret but also provides the secrets-api at the same time, things will probably not work.

[droidmonkey]

@Gigadoc2 that is not what the OP requested.

I want to use my system keyring to store KPXC passphrases, so that unlocking any encrypted data has the same workflow.

You can use the proposal from #1405 at any time through either a global keyboard shortcut, script file, or other means. There is nothing special about startup. It doesn't make any sense to create a PAM module for one application. It has been discussed before and was rejected.

[Gigadoc2]

@Gigadoc2 that is not what the OP requested.

I want to use my system keyring to store KPXC passphrases, so that unlocking any encrypted data has the same workflow.

Apologies if I am annoying, but I think this is what the OP requested, storing the passphrases to KPXC databases in the system keyring (of course this can only work when KPXC is not acting as the system keyring itself).
Look at the points in expected behaviour, this is about automatically unlocking by storing the database passphrase in the system keyring. Furthermore #1405 was also created by @david-libremone, related to this request, quote:

This is a specific scenario to be tested after implementing #1404

You can use the proposal from #1405 at any time through either a global keyboard shortcut, script file, or other means. There is nothing special about startup. It doesn't make any sense to create a PAM module for one application. It has been discussed before and was rejected.

This is true, but a somewhat hackish solution. You'd have to kill KPXC on screen lock, suspend, etc (as opposed to having it lock itself) and then restart it. In particular, you need to have your screen lock start KPXC, or have a daemon that watches for screen unlock and then starts KPXC.
This is all possible to do manually, but not likely something that popular desktops or distributions will do automatically.

I'd like to explain why I am so annoying interested in this feature request:
I like to recommend the use of some kind of password manager for "normal users", who usually use the same few simple passwords for all their online services (the problem probably is well-known to the people here). However, normal users (I as well tbh) usually don't want to enter multiple passwords on login/screen unlock. Even if I can convince them to do so, it will only increase the effect of security fatigue. Since the passwords chosen for login and KPXC are often the same and an attacker managing to log into the computer can easily install a keylogger, having to log in and unlock KPXC separately also does not increase the security much.
So I would like to recommend them a solution that does not require a separate unlock procedure. So far the possible solutions are:

1. Use the system keyring to save passwords. This is usually encrypted yet does not require a separate unlock procedure when passphrase == login password. However, this is not easily synchronizable between machines, and there is no working browser integration (most of the time). Also, while all platforms have such an "encrypted store" of sorts, I am not sure if the Windows one can easily save passwords.

2. Save passwords directly in the browser (native or some cloud-extension). This often works without a separate unlock procedure, but only because the passwords are saved in plaintext either on your harddrive or someone elses.

Right now, KPXC already supports synchronization between a lot of platforms, by just syncing the database, and the browser integration is consistently good (better than anything else at least). If it now had the possibility to somehow unlock itself through the login password (direct or indirect), it would be the go-to solution to recommend to "regular" users.

Truth be told, this could also be solved by having the Browsers query their "master passwords" from the system keyring. However, neither Mozilla nor Google would be willing to do so, as they both don't want to integrate with the OS too much (a wholly different discussion). Also, KPXC supports more than just website passwords, even if this is the main usage of it.

So, apologies for the long post (without an attached merge request as well), but this is why I believe this feature to be worth pursuing (even if it conflicts with #2726).
I can script KPXC to be unlocked with the login password, but the average user can not.

[droidmonkey]

OK I read everything another time and I agree with you, I was incorrect.

[Nokia808]

I would like to comment here so as to receive update about this issue that, originally, I asked about in issue 3206 which closed because it is a duplicate of this.

I was very happy when I saw this feature is already included (before your comment on 3206 & closing it). Unfortunately now it is clear that this feature is still not included. I'm afraid that we will wait for long time before see it ..... Please can you included this issue in list of issue that should be fixed/included in version 2.5.1 milestone ?

[phoerious]

You can now use KeePassXC AS the system keyring, so in most cases, there shouldn't be a need to use the system key ring to unlock KeePassXC. In any case, there will be no new features in a minor release such as 2.5.1.

[Nokia808]

@phoerious
Dear what you mean by "You can now use KeePassXC AS the system keyring" ?
I did not understood due to language + technical language barriers. Do you mean by that, that there is a way to do the reverse: KeePassXC unlock the system instead of system unlock KeePassXC ? If this, then how? & on which version of KeePassXC?

All what I need is that: instead of master pass-phrase that currently needed to unlock my database which contain my passwords, I need that this database to be unlocked AUTOMATICALLY when I login to my user account when I enter the password of this user account to login to it. Is this possible now? If yes, then can you explain to me how? & on which version of KeePasssXC exactly?

Any help is very appreciated.

[phoerious]

You can use KeePassXC as a server for libsecret, i.e. as a replacement for Gnome keyring.

[innerand]

@phoerious Would it be unlocked with the login when used as libsecret server?

[SleeplessSloth]

I personally launch the app like so
secret-tool lookup application keepassxc | keepassxc --pw-stdin ~/keepass.kdbx
and it works like a charm. To save your db password to your keyring use
secret-tool store --label "KeePass" application keepassxc

[Gigadoc2]

@innerand I think it is not.

@SleeplessSloth This works for initial startup, but not for the other things like screenlock & unlock, suspend, etc. See my post https://github.com/keepassxreboot/keepassxc/issues/1404#issuecomment-510482344

[SleeplessSloth]

@Gigadoc2 Relocking the db after suspending/locking can be disabled in settings, can't it? Or are there some security implications to it?

[Gigadoc2]

@SleeplessSloth I think there are:
If the database is not locked on suspend/screenlock, the encryption key will be held somewhere in memory and the database would be easily accessible to anyone who manages to gain control of the UI.
I have two scenarios in mind, both involve you locking/suspending your notebook and leaving it alone for a time:

The more unlikely (but still somewhat valid) scenario is that while you are gone, someone dumps your notebooks RAM. This might happen in the movie-style "remove the memory bars while cooled with liquid nitrogen", or more realistically by attaching to a firewire port or expresscard slot, if your OS does not use the IOMMU to isolate those ports (Linux by default does not). Still, this scenario is a bit paranoid.

The way more likely scenario is that someone gets control of your desktop while your are gone. On all Linux Desktops I know of, except maybe GNOME (but I am really not sure of that), all you need to do to unlock the screen is to somehow crash the program that displays the screenlock, or convince the window manager behind it to not put in in foreground anymore. Luckily those programs don't tend to crash very often, but it is still possible (I believe there was some time where the Ubuntu screenlock crashed when you kept entering characters into the password promt).
Someone getting access to your desktop is already pretty bad, but it would be even worse if they could immediately read all your passwords and decrypted ssh private keys.

So, while it is not immediately fatal for most of us to just keep KPXC unlocked, it would be nice if KPXC locked and unlocked itself with locking and unlocking the desktop. It would add more security, especially if you suspend your notebook all the time instead of shutting down, while not being more annyoing.

For comparison, the gnome keyring used to do this (unfortunately it stopped locking itself some time ago due to no one maintaining it), it would lock itself on screen lock (which is also invoked before a suspend) and unlock itself with a pam module which is loaded by the screen lock. The idea here is that you can't get access to the keyring by just killing or tricking the screenlocker, the keyring needs the correct password to be passed via the pam module or it can't decrypt the database.

If KPXC would now be able to unlock itself by querying the secrets service (as opposed to scripting it in autostart) it could piggyback on this (hopefully soon restored) behavior, instead of requiring a pam module for this (which has been rejected, probably rightfully so).

[sirius-c]

To add support, the points discussed above in https://github.com/keepassxreboot/keepassxc/issues/1404#issuecomment-510482344 are also exactly my use case.

The description of the password storage issues with Firefox (and Thunderbird) is spot on. They compromise nowadays usability by not supporting the system key ring (automatically unlocked at login) to store their master password.

I do use the workaround keepassxc --pw-stdin, but it would be as substantial usability improvement if one could simply tell KeypassXC to store the database password in the system key ring, and then use it's excellent browser integration (hopefully soon also with Thunderbird) to secure those.

In the end, for me the mandatory usability requirement for any password management is that I enter my login password exactly once after starting my computer, or once to unlock it, and no more. It would be great if that could also apply to the KeypassXC database.

[Nokia808]

Is there any progression in this issue ? This feature till now not implemented, though it is very needed by huge number of users .....

[droidmonkey]

Very valid solution to this problem: https://github.com/keepassxreboot/keepassxc/issues/1404#issuecomment-551267244

[phoerious]

Although that is possible, I'd say your holding the wrong way. You don't unlock KeePassXC WITH the system keyring, you should be using it AS the system keyring.

[Nokia808]

@droidmonkey
I'm talking & asking about GUI option to achieve this not a command line approach ....

[SleeplessSloth]

Although that is possible, I'd say your holding the wrong way. You don't unlock KeePassXC WITH the system keyring, you should be using it AS the system keyring.

I personally don't want to use it as the system keyring. A lot of apps use the system keyring to store their data and I don't want them to pollute my personal keepass database that I sync between all my devices.

[Gigadoc2]

Although that is possible, I'd say your holding the wrong way. You don't unlock KeePassXC WITH the system keyring, you should be using it AS the system keyring.

In this case it would be nice if KPXC would be unlockable with the login password somehow, but I think this discussion has already happened further up in this thread.
At the end of the day, I am not a developer of KPXC so I can't "demand" anything, and I'll accept whatever decisions you will make. But I am using KPXC precisely because I want to enter less passwords, not more, so that the passwords I do have to type in can be more complex. It would be very nice if this idea could not only be applied to Web Browsers & co, where KPXC manages my passwords for me; but the other way around as well: That KPXC trusts the operating system in one way or another to supply the Database password.

[droidmonkey]

@SleeplessSloth you can have an unlimited number of KeePassXC databases... And the FDO Libsecret plugin even let's you expose only certain groups in a database. So I would definitely call our approach a one-stop solution that meets everyone's needs.

[innerand]

@droidmonkey, @phoerious could you please clarify if you plan to implement this feature?
When I read your comments I have to assume that you did not understand why it would be needed and conclude that you will not implement it either. Nevertheless the feature request is moved from one milestone to the next.
So if you ar not going to implement it please say so but please do not add it to a milestone. If it is in a milestone, I (and probably others) assume that it will come and wait for it instead of looking for another solution to my problem.

And no, using KPXC as the system keyring does not solve the problem.
Using the system keyring to unlock a KPXC database as described by the feature request would solve the problem.

Thank you!

[droidmonkey]

This issue is all over the place and we won't be doing anything further with this.

[innerand]

In case you also miss this feature, I wrote a q&d workaround script (for gnome).
It requests the passwort from the system keyring and (re-)opens a KPXC database at login and after sleep / screen-lock.

https://gist.github.com/innerand/405025e7fbae1b270025666418655d8b

[droidmonkey]

We can include this in our utils folder if you want.

[Nokia808]

@droidmonkey
Hi. I did not understand what you meant by "include this in our utils folder" !
Do this mean including this script within the binary packages of this program & configure it as a built-in new option ? This will be good .... But I'm afraid that I miss-understood you ....

[droidmonkey]

Was referencing what @innerand posted