Almost all my passwords in "pass" also have "url" and "login" fields defined. Many have additional fields including the passphrases for authenticators. I've got a pass file with all my credit card and bank information (in case I lose my wallet while traveling) and another with all the bonus programs I belong to.
It’s very much a work in progress, but enough of the base implementation is done that I’ve started using it as a daily driver replacement for pass.
$ pass age
..
9 months ago Debian/wiki.debian.org.gpg
8 months ago Git/bitbucket.gpg
8 months ago Websites/hub.docker.com.gpg
8 months ago Websites/heroku.com.gpg
8 months ago University/helsinki.fi.gpg
7 months ago Financial/ukko.fi.gpg
...It's not too bad to set up.
It takes about a minute to generate a gpg key pair minus the time it takes to generate a 4096 bit rsa key.
I made a video (and cheatsheet) the other week going through the process of creating a gpg key pair with an expiration date, how to export / import, revoke and backup your keys at https://nickjanetakis.com/blog/creating-and-managing-a-gpg-k....
It's totally worth it, I've been using pass for like 4 years and have hundreds of passwords in it. It works great. Also having a gpg key pair is handy to have around if you want to sign your git commits.
Creating a single key on one machine is not hard. Following proper best practices for gpg using subkeys and setting up pass to work nicely on multiple devices is a bit more involved and requires a decent understanding of gpg keys in general, which (correct me if I'm wrong), even most developers aren't super well versed in.
It's not simple but it's really not too bad. Just make a key that expires and understand the details around revoking certs and backing up / restoring and you'll be good to go. All of that can be summed up in a few commands and a couple of minutes of video (and it is in the above video).
Getting your gpg keypair and pass synced across multiple devices can be done with rsync or whatever mechanism you use to share data between machines (dropbox, etc.). I happen to use rsync to sync it between my workstation and a laptop.
And then, the fact it has a ready-made agent which can be forwarded etc., means you have built in means to cache the password etc in a way that is extremely well vetted and trusted.
encpass.sh only needs a POSIX compliant shell and uses OpenSSL. This is nice for restrictive computing environments (think big enterprise IT) where you may not be able to control the software that is installed on the machine.
The implementation turned out to be so useful and easily adaptable that we created an extension to it for Keybase (https://github.com/plyint/encpass.sh/blob/master/extensions/...) and have a whole workflow built around using the tool to manage secrets with teams and Keybase's builtin encrypted Git repos. (Primarily used in our automation scripts to hold API keys and other application level secrets)
I stop short of recommending the Keybase extension for others, since the acquisition of Keybase by Zoom, but the original OpenSSL version might prove useful for people who are looking for a simple secret management solution that is easy to plugin and extend.
As opposed to symmetric encryption? The advantage is that you don't need to provide the encryption password to write new passwords or replace old ones, since it uses the public key for that. It's a matter of convenience rather than security, in my opinion.
Using PGP also allows you to use related technologies, like agents and OpenPGP smartcards like Yubikey. I use my Yubikey to read my pass passwords. With the right setup using agent forwarding, I could also decrypt my passwords on a remote computer with the Yubikey through an ssh connection.
Besides, gpg is so versatile that you might be using it for loads of other stuff already and you may as well use it for passwords too. For example, you can use it for your ssh keys, to authenticate to PAM for `sudo` and `login` (local and remote (probably) using agent forwarding through an ssh connection).
> rather than gpg, which is in itself complex
gpg is complex, but you don't need to use all its features. You can just stick to a simple subset.
Otherwise, just the metadata that gpg already had to let you know what key to use.
That is, what do you gain by not using it?
Moreover, there isn't any support for Yubikey or smartcards.
[0]: https://captnemo.in/blog/2020/01/04/security-setup/#mobile-p...
pass will try to create the file in /dev/shm but if this fails it will use $TMPDIR.
If you're on a platform without /dev/shm you'll want to use some other equivalent such as a small ramdisk, or at the very least be sure your $TMPDIR is not synced into the cloud.
For multi-user, however, I use 1password. Its vault sharing and management, federation under an organization, onboarding/offboarding controls etc are a must-have when you have hundreds of people needing to share passwords. All organizations I've worked in before that had more than 20 users, any less-featureful alternative was absolutely not tenable. It becomes a shitshow as soon as teams cannot get SSO for internal systems under one roof and start trading credentials, or when teams have to trade API keys and so on because of disjunct secret management processes/platforms (unifying 1000s of developers and 100s of teams doesn't happen that fast, if at all). As of now, we have read-only vaults that internal customers can access right there on the desktop, in which we provide secrets that are being rotated, updated, etc in sync with our backend system password management, over 1password API. If 1p has one use for my team at my company presently, it's not so much the great password management, but as a corporate-approved terminal for end-user secrets, like API keys, and so on.
(and yes, I do appreciate that this is not a feature that everyone wants/needs)