(and yes, I do appreciate that this is not a feature that everyone wants/needs)
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.
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.
What is that? The article isn't about pass, but you seem to be talking about pass.
To create your list of usernames and passwords, create an encrypted file as follows (you'll be prompted to choose a passphrase):
vim -x /path/to/passwordfile
To access or update your list of usernames and passwords:
The above autodetects that the file is encrypted (so the -x is no longer needed) and you'll will be prompted for your passphrase.
Modern versions of vim use Bruce Schneier's highly regarded Blowfish algorithm. Type :set cm? while in vim to verify that it reports the algorithm as blowfish or blowfish2.
I haven't tried vim on Android and iOS, so I don't know how convenient this would be on smartphones, but for Linux, I can't think of any simpler way for keeping an encrypted file of freely formatted text.
I keep a lot more than just the password string in my files. They are just plain text files after all. My largest secret was a full dump of my old Lastpass database as some imports failed due to naming issues.
This looks like an interesting exercise but I think the pass ecosystem provides a more robust tool for day to day use; though neither option are useful for my non-technical family members (IMHO).
(edited for clarity)
For instance, I have five years of tax returns saved in it. It's a simple, secure way to store them for easy retrieval later.
$ cat tax_return.pdf | pass insert -m taxes/returns/2017
EDITOR=/usr/bin/evince pass edit taxes/returns/2017
That seems like a different use case from what I am after, which is safely and redundantly storing secrets in plain sight. I don't put random things in my password store, I put passwords and other sensitive or easy to misplace files that I will likely want to find later.
I agree that you'd be better off storing most of your files on a file server. But that's a different thing, in my opinion.
It's really handy because you can save a couple of things like API keys and what not but have the first line be your password so you can still use it seamlessly as a password manager with the copy to clipboard flag, but then access the extra lines of details on a need to know basis.
> One approach is to use the multi-line functionality of pass (--multiline or -m in insert), and store the password itself on the first line of the file, and the additional information on subsequent lines.
The Android Password Store app  also handles this format, interpreting the first line as the password and displaying the subsequent lines as additional information.
I originally used pass (with some custom scripts to read the current URL from Chrome and copy the password for that domain), but then switched to 1Password when they came out with their cross-platform browser extensions. Having a browser extension to automatically generate and save usernames and passwords, and something that supports syncing out-of-the-box makes password management a whole lot easier.
Earlier this year I switched to BitWarden (with bitwarden-rs as the server) and it is 95% as good as 1Password. I'm happy to have something self-hosted to manage this.
This setup (as well as pass) has one security downside over other password managers like 1Password, BitWarden, etc.: they leak information through the filenames you use to organize your passwords. Depending on who you are and your threat model, it could be pretty bad if someone gets a hold of your password store that contains an (encrypted) file called `silk road` or whatever.
I prefer to use the KeePass 2.x format. Tailored toward storing sensitive data, flexible enough to fit most use-case, and user-friendly enough to be used by an average user.
It's pretty much the same as pass, where each password is stored in a .gpg encrypted file, but written in go so it works with both Mac and Windows.
As many have pointed out, one big flaw in this blog post
is that pass allows multi-line edit, I've corrected that
in the blog post.
Many alternatives have been suggested here, I will sure to try them out someday, thanks!
clip $(oathtool -b --totp "$(pass show otp/$1 | head -n 1)")
Then in my `pass` store I have a `otp` folder where I put the codes for my different services.
So to get the OTP code for paypal for example, I do this:
pass otp paypal
Some of the newer premium features, such as SSO integration are under the Bitwarden license, which is more of a visible source license.
If you read through the link you posted and also the FAQ, you'd see that you can only self host the free tier features for free. If you wish to have some premium features or a family sharing feature and want to self host, you still have to pay. My question was about what the OP was using/hosting and the licensing model.
%gpg -c somefile.txt
Enter a passphrase.
Boom you have somefile.txt.gpg, no need to deal with keys, just do not forget your passphrase.
For passwords keepassxc does everything I need.
There's a list of compatible apps
* KeePass (Windows): https://keepass.info/
* KeePassXC (Windows, Linux, MacOS): https://keepassxc.org/
* KeeWeb (Windows, Linux, MacOS, Web): https://keeweb.info/
* AuthPass (Windows, Linux, MacOS, iOS, Android): https://authpass.app/
* Keepass2Android (Android): https://play.google.com/store/apps/details?id=keepass2androi...
* KeePassium (iOS): https://keepassium.com/
Security experts generally seem to agree that a stateful password store is a more security password manager than a deterministic scheme.
This can seem like a good idea, right up until you run into a site that requires periodic password changes leading to "name" becoming "name2", "name3", ... over time, and you needing to remember which one is current.
That one also requires you to select the password length. Unless you find it acceptable to limit all passwords to the minimum of the maximum lengths allowed at all the sites you use, you will also need to remember for each site how long the password is.
Same goes for character class restrictions and requirements.
Password generators can work reasonable well, but generally only if they are coupled with storage to remember where you are in password rotation, password length, and character set rules for each site.