Shared 'pass' Passwordstore

Before I encountered Passwordstore ( ) I adamantly refused to use online password managers. Every week there's news of some database of personal information being dumped on the internet: I imagine the people who run online password managers work harder on security than most websites, but they're also a high value target (ie. they're probably attacked more). What hacker wouldn't want to breach a huge collection of passwords?

Passwordstore isn't, properly speaking, an "online" password manager. It's a password manager, and you can use it in a distributed manner - a lot like git. In large part because its ability to move from computer to computer is based on the use of git. To me, the beauty of Passwordstore is that the security is totally up to you. And it's not centralized at some well-known site - it uses your git server. You mean I manage my own password security? I'm in.

Unfortunately, while Passwordstore is probably a great fit for your Dev/Ops team, it may well be a no-go for your non-technical staff. They're going to laugh in your face when you explain the requirements. Excuse me, no, they won't laugh - they'll glaze over and when you're done they'll say "I have to what-the-what? I don't think so." And they have a point, because what you just told them was "You have to install SSH, Git, GPG, and Passwordstore. Then you'll need to create an SSH key (with a passphrase) so you can use git-over-SSH. And you'll need git installed, although that mostly manages itself - at least for Passwordstore. Then you need to generate a GPG key (also with a passphrase, but a different one). Then you have to initialize the password store with this series of command line commands -" at which point they started snoring, and we hadn't even gotten to how to share the passwordstore between computers as a git repo. As I said, this is a good fit developers and operations people who are already in the git-over-SSH headspace, but even for them it may involve a bit of thought and work.

I highly recommend it, and have been using it heavily for a year and a half now. I'm not going to do a tutorial on personal use of Passwordstore: I found it straight-forward to get it going using Passwordstore's own documentation. Just go to their page and follow the instructions - it's easy to install because it's already packaged for most major OSes. brew install pass on a Mac, dnf install pass on Fedora.

You'll need a working understanding of Passwordstore / pass for the rest of this to make sense.

Recently it's become apparent that my business need a shared password store at work, for a couple reasons. One is shared services: an online service that costs a fortune for a single login that needs to be shared between several people. The other reason that comes to mind is hit-by-a-bus-syndrome. If someone leaves the employ of our company - either through being hired elsewhere or a catastrophic accident - we need the passwords that only they have, to be accessible to someone else.

Paswordstore's binary name is pass. Does pass support all of this? Yes. Is it easy? Not so much. And this feature isn't as well documented on the web as single person use, so I thought a tutorial on the subject was warranted.

The most recommended method online for a pass shared store is to create a subfolder inside your main passwordstore. The default location is ~/.password-store/ so they're suggesting you create a subfolder like ~/.password-store/workshare/. I've found two significant problems with this solution: first, if you intend the shared passwordstore to be distributed to other people as a git repository (and what was the point of this exercise if not that?), then you've just placed a git repository inside another git repository. I'm sure there are git experts out there who have no problem with this, but for most of us intermediate-level git users, this is a very ugly situation that isn't going to end well. The other problem I encountered (this was partly based on a misunderstanding on my part, but it left a hell of a mark) was that the GPG key I was using in the subfolder started to poison my personal passwordstore. New personal passwords were being encrypted with the wrong GPG key, but then pass would try to decrypt them with my personal key. That took some clean-up and left me reluctant to try again for a while.

But it occurred to me: the location of the password store is determined by the value of the $PASSWORD_STORE_DIR environment variable. What if you created a new wrapper command around pass that just reset that value? Then you could use pass for your own passwords, and wpass for your shared passwords. This has some caveats - notably around breaking command line completion - but they can be addressed. I'm pleased to have thought this up, but I wasn't the only or even the first to do so, and most of what you'll find below is based on the work of others smoothing out the problems with this solution.

Setting up a shared store involves a bit of work with the GPG keys of all involved parties. I've read two or three tutorials on the subject, and found this the best: - WITH THE CAVEAT that they're suggesting using the subfolder method. Read that, and combine it with what follows for the separate folder method.

This second command can be implemented as a script:

#!/usr/bin/env bash
# filename: wpass
export PASSWORD_STORE_DIR=${HOME}/.wpasswordstore
pass "$@"

Or - probably better - as a shell function (put this in a shell start-up file like ~/.bashrc, I think it will also work in ~/.zshrc if you use ZSH):

wpass () { PASSWORD_STORE_DIR=${HOME}/.wpasswordstore pass "$@" ; }

Either will work, both will break your Bash completion. So let's fix that:

# Add to ~/.bash_completion
_wpass() {
    # trailing / is required for the password-store dir.
    PASSWORD_STORE_DIR=~/.wpasswordstore/ _pass
complete -o filenames -o nospace -F _wpass wpass

The fix for ZSH completion is simpler:

# Add to ~/.zshrc
compdef -e 'PASSWORD_STORE_DIR=$HOME/.wpasswordstore _pass' wpass

Then follow the directions in the "medium" article linked above.