Skip to content

Instantly share code, notes, and snippets.

@dAnjou
Last active November 14, 2023 11:49
  • Star 24 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save dAnjou/b99f55de34b90246f381e71e3c8f9262 to your computer and use it in GitHub Desktop.
Automatically unlock KeePass database with GNOME Keyring

(Tested with KeePassXC on Fedora 25)

By default when using GNOME Keyring you have a keyring that is unlocked when you log in (usually called "Login"). You can make use of that by storing a KeePass database password in this keyring and using it to automatically unlock your KeePass database.

Store the KeePass database password in GNOME Keyring. You'll have to set a label and at least one attribute/value pair. The label is displayed in a GNOME keyring manager (e.g. Seahorse), the attribute/value pair should be a unique identifier because it's needed for the lookup. I suggest to use keepass as attribute and the database name as value (make sure it doesn't contain any spaces).

secret-tool store --label="KeePass <database_name>" keepass <database_name>

Then create a script to launch and immediately unlock your KeePass database.

#!/bin/bash

secret-tool lookup keepass <database_name> | keepassxc --pw-stdin /path/to/<database_name>

You can now use this script to launch KeePass with your database already unlocked. I recommend to create a desktop launcher for more convenience.

@androidseb
Copy link

Hey guys, thank you very much for these tips, this looks very useful, I tried it and it works like a charm!
I would like to confirm I understand well what this means in terms of security though. From my understanding, assuming you have only a passphrase set for your password database...

1/ Before this trick
A malicious program with user privilege could not access your passwords unless it has the master key of your database, and it had no other way to find it without brute force or key logging

2/ After this trick
A malicious program with user privilege can find the value of the database password by reading your startup script and by running the command secret-tool lookup keepass <database_name> and then read all your passwords.

I'm not very familiar with the Gnome keyring system so maybe I'm missing something. I know it's pretty unlikely but I'd like to see the worst case scenario...

@storyjesse
Copy link

I'd like to know the answer to androidseb's question too. I think they are correct. I at first thought that I'd be able to just use keepassxc-cli to do exactly the same thing as secret-tool but I can't find a way to list passwords from the command line using keepassxc-cli without entering the database password at the same time; so perhaps keepassxc IS more secure than seahorse (gnome keyring).
That said any implementation to automatically unlock keepassxc will have the same issue I believe. I'll mention that I really like Keepass2Android's quick unlock function where it "half-locks" the database and then only asks you for just the last 4 characters of the master password to unlock it. Very handy on a touch screen device but perhaps less so on a device with a keyboard.

@definite
Copy link

@androidseb Before login, the keyring is locked. Thus you need brute force or smart method to crack it.
However, after login, the keyring is unlocked if you use the same password as login password.
So you DO need to worry about malicious programs after keyring is unlocked.

@Organic-Marble
Copy link

This works for me on Ubuntu Linux in that it starts KeePassXC and unlocks the database. But there's still a prompt to enter a password in the terminal window, and the script doesn't proceed. Any thoughts?

@RamiShafikovca
Copy link

RamiShafikovca commented Nov 14, 2023

@Organic-Marble Sorry for the late message, I found that switching the order of the argument works:
keepassxc /path/to/<database_name> --pw-stdin
So the command should read:
secret-tool lookup keepass <database_name> | keepassxc /path/to/<database_name> --pw-stdin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment