Simple Password Management with GPG | Hacker News Reader

Simple Password Management with GPG

tylerlmz1.github.io

96 pointstodsacerdoti76 comments

There's one advantage to this approach that, as far as I've seen, no other password manager has been able to replicate. Pass is simple. It is literally a few hundred lines of clear, easy to read bash shell script (yeah, that's a phrase I never thought I'd hear myself saying, ever). It's simple because it's created by composing standard, simple off-the-shelf technologies (bash, gpg, git). Compared to more monolithic solutions, it's easy to compose those very same technologies in a different way. That, in turn, makes it easy to adapt to new settings, and super resilient to new use cases like different sync technologies.

(and yes, I do appreciate that this is not a feature that everyone wants/needs)

last time I looked at it, it revealed too much information even if you didn't have the pass-phrase

Yes it is simple. I like it a lot. But could it be made even simpler? For example, rather than gpg, which is in itself complex, could it use something else? What is the point of using a public key crypto for something entirely private?

> For example, rather than gpg, which is in itself complex, could it use something else?

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.

I'm an avid pass user too, but I think claiming that managing gpg keys is _simple_ is a bit of a stretch.

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.

> but I think claiming that managing gpg keys is _simple_ is a bit of a stretch.

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.

Well it is somewhat convenient to not have to enter a passphrase on initial creation.

We use pass for our whole team. When someone creates a new password it is encrypted with everybody's public keys and everyone can just git pull the repo and use it. It's great for sharing passwords between people.

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.

Sharing passwords/secret keys itself isn’t good practice, though, so I hope most teams don’t find a need to use pass to achieve that.

There are times when you simply can't avoid it, and in those cases pass is great for doing so because you can revoke keys and rotate the password when someone leaves.

It lets you add passwords without needing your security key. So that is nice.

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?

I agree. I’ve been working on a version of pass [1] that uses age [2] instead of gpg (it’s also written in Rust instead of bash so is considerably faster).

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.

[1]: https://sr.ht/~gpanders/passage

[2]: https://age-encryption.org

I wrote an extension to pass to show password age, using the git history. To see "age" listed was momentarily confusing to me!

   $ 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
   ...

Yes, I think so. In the vein of simplicity, we created a lightweight secret management script called encpass.sh (https://github.com/plyint/encpass.sh) Our use case initially was to have a simple and relatively secure way to handle secrets within shell scripts. By simple I mean does not require a lot of external dependencies and likely may already have its requirements installed on a machine.

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.

> What is the point of using a public key crypto for something entirely private?

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.

pass is simple on *nix. Pass is just painful on Windows and Android, probably on iOS too. I used to use pass for my passwords, but one day I switched to KeePassXC, which is a nice multiplatform GUI, has all the GUI niceties (and auto-type), there are mobile apps to work with it, and I keep my database synced with OneDrive.

I've been wary to trust the sync behavior of tools like dropbox or onedrive, as they permit concurrent edits of files. For things like encrypted password databases, there isn't an automated merge strategy that can be applied. I think they support versioning, so if two edits happened concurrently then the losing edit would be recoverable via versioning. Maybe that's not really a concern for a password database, as you'd likely be online when making a change? Anyone see issues with KeePass and sync tools?

Yes, in my experience, using dropbox, you end up with two versions of the keypass file (one listed as a conflict). I've been using this setup for ~10 yrs, and it has only happened 2 or 3 times, but as I'm the primary user, I would expect this to happen more often with a family sharing the same file. If things are working correctly, the keepass lock file created when opening a db is synced via dropbox, so any second attempt at opening the file on another system results in a warning to open it as readonly.

Because Keepass uses GUIDs internally for most operations, merging the conflict files is usually trivial (use the Sync options in the Keepass UI of your choice from your main file, then you can safely delete the file marked as conflicting). (The GUIDs thing has also meant that I've had some success merging unrelated files too over the years, though that is probably less advisable.)

pass works great on Android. There's an app for it: https://github.com/android-password-store/Android-Password-S...

Pass works great for me on iOS for years now and it's open source too [0].

[0]: https://github.com/mssun/passforios

It's okay, not great. I use a second GPG key for the phone so as to reduce the number of passwords accessible there. While it works out of the box, getting it to work nicely needed a bit of plumbing[0].

Moreover, there isn't any support for Yubikey or smartcards.

[0]: https://captnemo.in/blog/2020/01/04/security-setup/#mobile-p...

just dumped pass for the fact that it is extremely unpleasant on windows. it's actually pretty good on ios.

One feature I like about pass is that it stores each password as a file. This makes syncing a lot more pleasant, rather than having to resync the entire DB each time a new password is added. Additionally, it is git-compatible and when you sync you can see what has been added/removed using standard *nix tools.

Your mention of OneDrive made me remember that pass creates a cleartext copy of your password file, while you are editing it.

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.

But the phrase "I’m aware of pass and tried it before I came to this setup, but I want to put more info than just a password string in my files, so that’s why pass doesn’t fit my need." is simply incorrect.

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.

> this approach

What is that? The article isn't about pass, but you seem to be talking about pass.

pass has excellent terminal UX (shell completion), can be versioned using git. Currently it's a perfect fit for me in the private environment, because I keep browsers 100% jailed and all passwords out of browser context (so I wouldn't use a pass<>browser integration in any case).

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.

I hope this is not too obvious a thing to mention, but if you want a really bare bones plaintext password manager on Linux, then use vim with its encryption mode:

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:

vim /path/to/passwordfile

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.

As for emacs users, the EasyPG package (https://www.emacswiki.org/emacs/EasyPG) offers a similar feature - it uses GPG directly, though.

Emacs also have its own internal password system with .authinfo.gpg a nice small walkthrough of the system is here https://www.masteringemacs.org/article/keeping-secrets-in-em...

Good to know, thanks !

Please, do not use vim crypto for anything serious, such as password storage. It has a weak KDF, is malleable (especially important if you decide to sync your password files), and most important, the authors disregard suggestions of competent people https://github.com/vim/vim/issues/638

From the article: > I’m aware of pass and tried it before I came to this setup, but I want to put more info than just a password string in my files, so that’s why pass doesn’t fit my need.

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)

Yeh, I wonder if it's due to the fact that `pass generate` and `pass insert` commands, by default, create one-line files that gives this impression.

Well, this exact use case is mentioned on the pass website [0].

> 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 [1] also handles this format, interpreting the first line as the password and displaying the subsequent lines as additional information.

[0] https://www.passwordstore.org/

[1] https://github.com/android-password-store/Android-Password-S...

I use my own wrapper over pass, https://github.com/cipherboy/p, to use the remaining space as a JSON blob and pretty-print it with jq.

Blog post author here, yes you are correct, I falsely assumed that I can only insert and manipulate one liners in the file due to these commands being the first things I learned about how to use pass, so I just moved away quickly without looking deeper.

The only thing that is required (if you want the clipboard integration to work correctly) is that the first line of the file is the password. You can have other info in the file. Many of mine have my "secret questions" and their random gibberish answers, for instance.

Pass will store arbitrary text, and various pass frontends (qtpass, and ansible's passwordstore lookup plugin) will also allow you to put in key-value fields, and query them.

I use pass and store all sorts of stuff in there.

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.

To store:

   $ cat tax_return.pdf | pass insert -m taxes/returns/2017

To view:

   EDITOR=/usr/bin/evince pass edit taxes/returns/2017

While this works, at a certain point it starts to make more sense to use something like Nextcloud.

Looked at the wikipedia page for that project briefly, seems like just a private file server type thing.

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.

Or just use plain old gpg and a git repo or backup service. Pass is good because it is roughly domain specific to passwords and secrets. I wouldn't exactly consider tax forms "secrets", but rather just private information. Adding everything private and the kitchen sink seems like a misuse, but if it works, it works!

Yeah, after reading that sentence I kind of just stopped reading the article. Pass' multi-line flag lets you save whatever text you want.

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.

If anyone wants a self-hosted password manager I'd highly recommend BitWarden.

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.

Why would you need custom scripts when both Browserpass and GoPass Bridge have browser extensions for pass?

This was over 5 years ago, before those projects existed, or at least they weren't on my radar at the time.

I'm a pretty big fan of plain text for many things, but in this case it seems significantly simpler to just use a more full-featured password manager. I'm not sure I really see the benefit of a system like 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.

That's a valid critique for some use cases, I guess. Doesn't really apply to my uses, but there are some ways around this including having the presumably few very sensitive accounts saved using alias names that only you know.

Is pass-tomb not a decent solution to that? I've not considered it necessary in my threat model, so don't know.

You could use (say) UUIDs as the filenames and maintain an encrypted table containing the mapping between human readable filenames and UUIDs.

GPG and simple aren't something I can say goes well together.

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.

I'll stick with keypass, thanks... not sure what this solution offers that others do better

I've been using gopass to store and share passwords with team members at work https://www.gopass.pw

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.

Blog post author here, I'm very glad to see my post on HackerNews since I've been a long time reader.

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!

The only thing this is missing is OTP generation. 1Password does this for me, I don't know of any open source toolchain that makes this simple.

Bitwarden does TOTP generation and is open source (also has a CLI tool), but I do not know if it would fit your use cases and needs.

gopass[0] is more or less a superset of pass written in Go that will do this for you. I’ve been using it for a few years syncing between iOS and macOS with no issues.

[0]: https://github.com/gopasspw/gopass

I think `pass` has an official extension to handle OTP, but here is how I do it:

  #/bin/bash

  clip $(oathtool -b --totp "$(pass show otp/$1 | head -n 1)")

Basically there is a really handy utility called `oathtool` you can install that has all the one time password logic built into it.

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

And then the code is copied to my clipboard and I can just paste it.

Pass already has OTP. It is usually in the pass-otp package, both the Android app and the browser extensions support it as well.

Why not simply use BitWarden?

bitwarden_rs is especially good if you're looking to self host. https://github.com/dani-garcia/bitwarden_rs

I saw something on the Bitwarden site about needing a paid license if you wanted to self host and use sharing features and got confused as to how “free” it is. Do you know more about this?

Im really curious as to why you wont want to pay for a license for bit warden its very cheap and adds a lot of value. Any way you can self-host on free tier https://bitwarden.com/pricing/

My point and question was not about me not wanting to pay. It was about what's meant by "free" and "open source" if you have to pay to use it on your own running costs if you want certain features (the sharing feature is one example I mentioned).

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.

So you can self host for free. Most of the older premium features are included in the open source server - it does have a license check, which loads a license file you're provide by Bitwarden if you purchase one. These older premium features and the license check are themselves AGPL licensed last time I looked. Alternatively, you can use bitwarden_rs, a re-implementation of the server under GPLv3. Many of the premium features (such as yubikey support) are implemented in bitwarden_rs out of the box so you don't need a license for those.

Some of the newer premium features, such as SSO integration are under the Bitwarden license, which is more of a visible source license.

Thank you for taking the time to provide more clarity on this. I’ll take a look at bitwarden_rs.

Quick tip.

%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.

pass is really the best way to do gpg encrypted password management (imo)

https://www.passwordstore.org/

I'm looking for a simple solution like this to easily keep encrypted .Md files as a journal.

For passwords keepassxc does everything I need.

That the beauty of the KeePass format, if you don't like the UI, there's usually another app that can read it.

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/

And why not to use https://passwordlive.github.io/ instead?

That appears to be a password generator. Given a secret and a name, it generates a password. You memorize that one secret, and use that and a name associated with each site to generate a password for that site.

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.

Some discussion of flaws of deterministic password managers can be found here [0] (HN discussion [1]).

Security experts generally seem to agree that a stateful password store is a more security password manager than a deterministic scheme.

[0]: https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...

[1]: https://news.ycombinator.com/item?id=13016132

Reply on news.ycombinator.com