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

Articles from blogs I read

OpenSSH introduces options to penalize undesirable behavior

In a recent commit, Damien Miller (djm@) introduced the new sshd(8) configurations options, PerSourcePenalties and PerSourcePenaltyExemptList, to provide a built in facility in sshd(8) itself to penalize undesirable behavior, and to shield specific client…

via OpenBSD Journal June 7, 2024

Your Node is Leaking Memory? setTimeout Could be the Reason

This is mostly an FYI for node developers. The issue being discussed in this post has caused us quite a bit of pain. It has to do with how node deals with timeouts. In short: you can very easily create memory leaks [1] with the setTimeout API in node. You…

via Armin Ronacher's Thoughts and Writings June 5, 2024

The state of SourceHut and our plans for the future

Good morning! It’s been a tough year for SourceHut and I know many of our users are waiting to hear from us. Our last update was the post-mortem following the DDoS attack we sustained in January, and we have some additional news following this update as well…

via Blogs on Sourcehut June 4, 2024

Generated by openring