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, 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.



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.

Do you have a comment on one of my posts? Feel free to send me an E-Mail:
To participate in a public discussion, use my public inbox: ~witcher/
Please review the mail etiquette.

Posted on: February 18, 2023
Last modified on: February 18, 2023

Articles from blogs I read

Notes on Podman

Podman is an alternative implementation of Docker which addresses some design issues in Docker. The most obvious/notable difference is that Podman doesn’t require a daemon running permanently, which is nice, but not a huge deal. It also has other design d…

via Hugo Barrera's site March 15, 2023

When to comment that code

My software tends to have a surprisingly low number of comments. One of my projects, scdoc, has 25 comments among its 1,133 lines of C code, or 2%, compared to the average of 19%.1 Naturally, I insist that my code is well-written in spite of this divergence …

via Drew DeVault's blog March 9, 2023

Status update, February 2023

Howdy! This montly status came a bit late, but nevertheless, here it is. I am working on Husky to add more stuff that allows the app to setup itself some features for different ActivityPub backends. This is a very WIP task that I’m doing carefuly and I would …

via captainepoch's log February 22, 2023

Generated by openring