Use DBus interface to unlock with hardware key (YubiKey)

[Zocker1999NET]

Summary

Using the dbus interface, it is possible to unlock a database either using a passphrase only or a passphrase together with a key file. However I'm missing to be able to unlock my database, which is secured by a passphrase and a YubiKey.

Examples

Instead of calling org.keeepassxc.MainWindow.openDatabase(fileName=…, pw=…) either call org.keeepassxc.MainWindow.openDatabase(fileName=…, pw=…, hw=true) to use the first hardware key available (most of the time, only one should be connected for most of the people) or org.keeepassxc.MainWindow.openDatabase(fileName=…, pw=…, hw=<ID>) to select the hardware key by its id (shown by KeePassXC, e.g. YubiKey [<ID>] Challenge Response - Slot 2 - Press). If the concept if slots is applicable to other keys as well, it could be introduced as another parameter or by concatenating it to the id, e.g. <ID>:<SLOT>.

Context

I want to build a script which would be able to unlock my database nearly automatically by retrieving my database passphrase using my TPM or another secret service (I'm not sure yet how to make this in a secure enough way) when inserting my YubiKey, so I would just need to press the button on my YubiKey to open my database.

[droidmonkey]

If you have enabled "Remember database keys" we will remember the yubikey used to unlock a database after the first time. Then technically you can use the dbus with username and password and your yubikey will be selected automatically. We do need to introduce a delay to wait for key polling, so this might not work.

[Zocker1999NET]

@droidmonkey That's a workaround, however this would require that KeePassXC needs to check again for all keys connected. Currently, if I launch KeePassXC before inserting my YubiKey, it will not use the key (before because it might still run but the database was locked again). So it would require me to restart KeePassXC afterwards so it detects the YubiKey properly.
As I tested even closing all databases and then opening them from DBus again seems not to trigger a rescan of the connected security keys.

[h1z1]

Curious, why would you do this? DBus can be intercepted.

[Zocker1999NET]

Curious, why would you do this? DBus can be intercepted.

I did not found anything relating to the security of D-Bus and because Secret Services are exposed using D-Bus also other tools use D-Bus to transmit passphrases, I determined it might be secure enough for my case. But only the owner of the session bus can do that? If so, then it may be ignored, because then any application which can intercept D-Bus might also attach a debugger to KeePassXC and retrieve the passphrase or the stored passwords from RAM, am I right?

[h1z1]

Indeed. dbus should have been called dumb bus. No need for a debugger, they make it even easier - dbus-monitor

[droidmonkey]

Couple points to raise here:

1. dbus does what it was designed to do very well... connect messages between disparate apps without either one knowing anything about the other besides the API
2. dbus is not meant to be secure. Sensitive data sent over dbus must be encrypted (which it is with FDO Secrets) using a public/private keypair.
3. Everything on a computer can be intercepted at some level. The kernel intercepts everything, root has access to the kernel.

[h1z1]

You're not wrong, but you're not entirely correct. I wouldn't say anything using a private API can do so without knowing anything about its peers.

Just a guy whose had to deal with clients IT departments after security incidents.. keepass is used quite often and unknown to the organization. Some of the changes going into keepass are bizzare but that is better discussed elsewhere.

I do agree dbus is not secure thus should never be used for anything like a password manager though.

[droidmonkey]

closing in favor of #9229