Password Managers

I’m thinking about changing password managers yet again… Why? Because I’m not happy with my current one anymore.
As of now, the password managers I’ve been using (in order) are:

When I used KeePass, at some point I felt like I needed to switch to a different one (although I don’t remember the specifics), which is why I used pass. Quickly, I noticed pass doesn’t fit my use case properly. I wanted something with nice browser integration and seamless synchronization, which Bitwarden offered, the password manager I’m currently using.

I trust all 3 of these solutions, but ideally I want to keep my data to myself and have the highest degree of customizability.

So far, Bitwarden has been the least appealing on paper so far, requiring my password store to be stored on their servers1 and offering next to no customizability, e.g. by having a nice custom client to be used instead of their solution, which is an Electron client of all things. A nice tool to mitigate the downside of the Electron client is rbw, an open source command line client for Bitwarden written in Rust. This makes it possible to use it like pass, which is the ultimate password manager experience for me (more on that later).

To mitigate these downsides I could use KeePass (or more specifically KeePassXC, a community maintained fork), which stores passwords locally in a file. It’s then up to the user to sync this with other devices.
This is where I stumbled when I first used it. I had to sync this password database manually, making it really clunky and, most notably, annoying to use. I feel like this is the reason I switched to pass for a while afterwards.
KeePassXC has a few nice features, like scanning the password database against HIBP or Browser Integration (which felt mediocre at best).

The ultimate password management option for me is pass, though, which stores all passwords (and accompanying information) in single text files encrypted with GPG. This makes it trivial to write scripts for use with pass, like passmenu, a script that allows easy copying of passwords through dmenu.
The downside for using pass for me is similar to KeePass: Syncing across devices. This is usually mitigated by using git in combination, but this inevitably requires me setting up a repo somewhere (either on a service like Sourcehut or on my own server), but this exposes the “database” to the internet, which makes me feel a little uneasy.

By far the most important “feature” I need is being able to access my passwords on my phone, though. All 3 options make this possible, but Bitwarden is by far the simplest option since the syncing is seamless, without the need to set up some synchronization.
Ultimately, this is the feature that pushed me to Bitwarden in the first place, but I am rethinking this decision and feel like either pass or KeePassXC is the way to go forward.


  1. Setting up my own Bitwarden instance, e.g. with vaultwarden, is a viable solution, but mitigates the upside of having a nice and simple synchronization solution. Instead of setting up my own Bitwarden instance I might as well use any of the other 2 options listed. ↩︎

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

Posted on: June 09, 2022

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