Hacker News Reader

Comment by okennedy | Hacker News Reader

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)

View on HN

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.

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.

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.

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

> this approach

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

Reply on news.ycombinator.com