Password Managers: Part 2

Around half a year ago, I wrote an article about Password Managers. Since then, a few things have changed, so I wanted to write down my reasons for the current situation.

If you don’t feel like reading too much of this, my current password manager of choice is KeePassXC. For the people that would like to continue reading, here are my reasons for using it.

At the time of my last article about password managers, the one I used was Bitwarden, although I was already looking for a different solution, with the alternatives being pass and KeePassXC. Ultimately, even though Bitwarden is open source, its API isn’t, as far as I know. This makes tooling be in a weird place, as the API has to be reverse engineered, and I’m not aware of any documentation on it. I mentioned rbw, a commmand line tool to interact with Bitwarden, which is nice to use.

In contrast, pass is completely open source and easy to understand. It’s a bliss to use pass since it’s simply a small script that wraps GPG to store secrets. What I love about this is that if you’re ever having problems they’re easy to debug.
On paper it’s the best solution for me so far as I value the simplicity and ability to reason about as well as debug it… if you don’t count the fact that it’s exposing a bunch of metadata to anyone who might have the vault fall into their hands one way or another. The way I would store secrets, being in a tree with paths like example.org/username, this would not only give a hint where I have accounts, but also what the username for this account is. Personally, this is a bit too much information for me, and I don’t want to store secrets any other way while using pass, so I decided not to use it, even though everything else about it sounds good.

Lastly, KeePassXC. It’s the only KeePass desktop client that I think is really viable to use, so that’s what I’ll be talking about.
KeePassXC is a lot more complicated, having a custom database format, but the database is also way more expressive than that of pass. There are attributes (standard ones like username, password, etc., but also custom attributes one can define), notes, even attachments if that’s something you want.
What really convinced me to start using it again and keep using it over pass was that no metadata is leaked. You have a database file and that’s it. Everything inside, including what accounts you have, is hidden and encrypted.

In order to use KeePassXC like I would use pass to get passwords, usernames, etc., I wrote a little script that fetches that info for me using the keepassxc-cli(1) tool that is shipped with KeePassXC.

#!/bin/sh

database="$1"
shift

password=$(secret-tool lookup database password)
choice=$(printf "%s" "$password" | keepassxc-cli ls -Rf "$database" | sed '/\/$/d' | dmenu -i)
printf "%s" "$password" | keepassxc-cli clip $@ "$database" "$choice"

The integration with secret-tool(1) makes it possible to look up the database password from within the database, having created an entry for it, which is used to unlock the database. The script lists all entries in the database, filters out the folders, and makes a selection of these available through dmenu(1). Upon selection of an entry, the entry is then queried for an attribute. This is given on the commmand line when calling the script – Passing no arguments gives me the password of an entry, --attribute username gives me the username, --attribute totp gives me a generated TOTP key. Setting up keybinds for these makes it super simple to get each attribute.

In the future I want to do more to keep my passwords safe, though. My passwords are still accessible on the internet, even if they’re still behind a username and password. Ideally I would set up a small home server in the future, something like a Raspberry Pi would already be enough for this, and store my passwords on there, without access from the internet at all, minus a Wireguard interface to access my home network. This feels like the most secure method to use my passwords, so that is the plan.