Hacker News Reader

Comment by mongol | Hacker News Reader

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?

View on HN

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

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

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.

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.

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

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?

Reply on news.ycombinator.com