[gen220]

If you're already a UNIXy kind of person, you might want to check out https://www.passwordstore.org/.

If you're comfortable in the UNIX world, it's easy to migrate from all the big players, it's trivial to host the encrypted passwords on gitlab.com or [e-mail].

To me, the key differentiating feature, that made it better than bitwarden + co, is that it implements nothing on its own, it's just a wrapper around git, gnupg, etc. This also means that, 10 years from now, if you want to migrate to a hosted solution, you can (since everything is plaintext at the deepest level, migration-out should be easy).

It has mobile clients / multiple-device-sync, too. And it's easy to manage, because it's just git under the hood.

I hadn't heard of them before doing some deep searching in this space recently. It's a product with zero marketing budget, but a good-sized community, so you wouldn't hear of it unless you were googling search terms in the space.

[vdqtp3]

Of course it's a fucking zx2c4 project. Does jason do anything that's not cool?

[justusthane]

My problem with pass is that none of the other clients are official, so you end up having to trust the developers of whatever other clients you use as well. Seems like a larger attack surface than something like Bitwarden.

[gen220]

This is true, and there's nothing we can do about it except mitigate the risks. I'll list some mitigations, but underscore that they're mitigations, and do not invalidate the problem.

First, the clients are open source, so you can scrutinize them to your heart's content. (also true with bitwarden, but the code surface area for BW broader)

The only compromising snippets would be code that tries to do i/o with a decrypted password, which shouldn't be too hard to grep the codebase for. But, yes, this is an insurmountably high barrier to entry for most people.

On the other hand, BW requires constant communication with an API Server, which is much easier to hide compromising code within. Using git to synchronize state, so that no network traffic with an API server is required, is an elegant security advantage to `pass`, imo. The trade-off is that your encrypted secrets are in each of your clients, and the implications of that should be understood.

So, you're comfortable with the code as it is today. What about a nefarious update, that introduces some offensive code? Since the apps are dead-simple, you can comfortably block the app from being automatically upgraded on your phone.

You'll bump into problems when you need to upgrade the app to be compatible with the latest OS, which means you have to redo your audit once-per-year at worst. But at that point, you should be able to do a `git diff`.

In the absolute worst case, you can fork the client, load the app, and make the necessary upgrades yourself. Although, again, this is an insurmountable barrier for most people.

I think self-hosted Bitwarden still has a large attack surface, because they're a .NET + SQLServer application, instead of a dumb wrapper around UNIX tools. Don't get me wrong, UNIX tools have a big surface area, but we're screwed in countless other ways if we assume they're compromised.

I think the trade-offs are pretty debatable in both directions, reasonable people can disagree on the best solution, and the right solution probably depends on the administrator.

[qudat]

I’ve been using gnu pass for years and love it.