Keepassxc: Security issues, when using the OS' keyring

[sojusnik]

Relating to #440, I'm wondering if it's reasonable at all to store the master password for KeePassXC in f.i. Gnome's keyring (aka Seahorse)?

It's convenient, that's for sure, but it will give a potential adversary another vector of attack and therefore weakens the overall security of KeePassXC. I'm not a security expert, but in such a case KeePassXC would completely rely on the proper implementation of the keyring, with all its consequences. This came to my mind, when reading some remarks from Ubuntu's security team.

On the other hand, typing 3 different secure (like a Diceware passphrase with at least 7 words) passwords (full-disk encryption + OS user + KeePassXC) upon a system startup is tedious.

Any thoughts on that?

BTW, if somebody is interested, I'm currently using the following approach to launch and unlock KeePassXC on Ubuntu 17.10 upon startup, but with mixed feelings regarding the security.

Type in the terminal and enter your KeePassXC password:
secret-tool store --label='KeePassXC' 'keepass' 'default' (This will create a password entry in Seahorse)
Then add the following line:
bash -c "secret-tool lookup 'keepass' 'default' | keepassxc --pw-stdin ~/'PATHTOYOURDATABASE/DATABASE.kdbx'"
to your autostart file in /home/USER/.config/autostart/org.keepassxc.desktop so it will look like this:

[Desktop Entry]
Name=KeePassXC
GenericName=Password Manager
GenericName[de]=Passwortverwaltung
GenericName[es]=Gestor de contraseñas
GenericName[fr]=Gestionnaire de mot de passe
GenericName[ru]=менеджер паролей
Comment=Community-driven port of the Windows application “KeePass Password Safe”
Exec=bash -c "secret-tool lookup 'keepass' 'default' | keepassxc --pw-stdin ~/'PATHTOYOURDATABASE/DATABASE.kdbx'"
TryExec=keepassxc
Icon=keepassxc
Terminal=false
Type=Application
Version=1.0
Categories=Utility;Security;Qt;
MimeType=application/x-keepass2;

[lofidevops]

I'd argue that (optional) support for the system keyring is a useful addition that, overall, enhances security. While additional interfaces are potential attack vectors, the system keyring is a core feature of your desktop and (should) be trustworthy. It doesn't just offer convenience, it offers reliability (users expect their passwords to be stored somewhere). Applications that typically trust it include your email client, backup system (Deja Dup), SSH and GPG. I think a password manager fits in.

However, a system keyring doesn't fit everybody's security model, so obviously integration should be optional. I'd argue that on desktops that already use a keyring (GNOME, KDE) it should still be the default (opt-out rather than opt-in).

[calmarc]

kinda OT: I would use multiple databases - one for not so important stuff, that you can open with your secret-tool, and one with very important and maybe seldom uses stuff that needs manual treatment.
I personally actually also have TOTP tokens (to restore them) in a seperate db - when one would be hacked, (that with user+pass) they have still a problem to solve.. or is that paranoia already? :)
Just saying :)

[sirius-c]

From my point of view, integration with the system keyring (GNOME keyring for me) is a must. I am not willing to enter a complicated password twice when logging into a session.

I also believe this enhances security substantially, noting that ease of usability is a factor to improve security for the typical user.

[rugk]

I personally actually also have TOTP tokens (to restore them) in a seperate db

Actually, BTW, you should really be using this DB on a separate device. (on mobile with an app or KeePassXC on a different desktop or so) That's the whole point of 2FA. Otherwise you can leave it in general.

[foosinn]

You can do this right now using secret-tool:

# store a new password:
secret-tool store --label='Keepass' database pass.xdbx

# query and start keepassxc:
secret-tool lookup database pass.xdbx | keepassxc --pw-stdin ~/pass.xdbx

[rugk]

I guess built-in support would just be preferred. :grinning:

[foosinn]

Oh did not see that this was already mentioned, sorry. Just stumbled on this while looking for something else.

[ianliu]

One additional security measure is to specify an absolute path for keepassxc:

secret-tool lookup database pass.xdbx | /usr/bin/keepassxc --pw-stdin ~/pass.xdbx

This avoids executing unwanted binaries.

[ghost]

Any update on this?

[dacorsa]

OK, thanks works very well....but how can i start keepassxc at boot automatically? not works in this way:
copy to your autostart file in /home/USER/.config/autostart/org.keepassxc.desktop
Best regards

[jfk88]

OK, thanks works very well....but how can i start keepassxc at boot automatically? not works in this way:
copy to your autostart file in /home/USER/.config/autostart/org.keepassxc.desktop
Best regards

Had a similar issue. The command was working from the terminal but not when triggered from the script.

I set a slight time gap and now it works:

Exec=sleep 0.1 & secret-tool lookup database FILE.kdbx | keepassxc --pw-stdin PATH.kdbx

Then simply target the script in your autostart file / settings.