• Home
• Source Code
• Archives
• About

Team Password Management

A while back I started looking for alternate means to manage my passwords, specifically because I started playing more with pgp encryption. I thought it'd be neat to be able to use pgp to encrypt a password database and/or use git to version the passwords. It turns out that someone had the idea before I did: the developers of password-store.

Password-store, or pass, is a [very impressive] command line bash script that uses git to version passwords, and pgp keys to encrypt/decrypt each password. Specifically to this post though, it implements support for something that pgp/gpg supports: the --encrypt-to switch.

gpg --encrypt-to

The --encrypt-to switch for the gpg command allows for encryption of the given stream to multiple recipients. For the purposes of password management, it allows for each user of the password database to add their pgp key to the .gpg-id file. The effect is that each subsequent save of the given password re-encrypts it using every pgp key listed in the .gpg-id file.

Effectively, each user of the password repo can have their own password (the password to their pgp privat key), whilst not knowing the passwords other members are using. This means that if for example, an employee leaves the company, the remaining repo members can just remove that person's key from the .gpg-id file, and all further changes (regenerations) of the passwords will not be encrypted with the departed employee's key, thus revoking their access.

Setup

Setup for this is fairly simple, if you're accustomed to using git and gpg/pgp. The commands for pass are very intuitive.

To create a pass database (assuming you already have it installed), execute...

pass init user@gpg-id-to-be-used.com

To add other user's pgp keys, just add their ids to the .gpg-id file located at ~/.password-store/.gpg-id. Each password created after that will be encrypted to each user listed in that file.

NOTE: Remember that each key that you're adding to the .gpg-id file must at least have marginal trust in gpg.

Questions

What about arbitrary users adding themselves to .gpg-id?

The nice thing about gpg is that it will not allow usage of the --encrypt-to switch (amongst other switches) without a measure of trust given the key in question. This means that if any user does add their key to the .gpg-id file, every subsequent password change will yield an error, indicating that the password file cannot be encrypted to the given untrusted key.

Another perk to pass is that it versions all changes to the password "database" in git, so the user who added their key to the .gpg-id file will have left a log entry (assuming they didn't rewrite history to conceal their subterfuge), and thus they can be dealt with appropriately.

What if I want to run more than one database?

Add the following to your .bashrc file.

#
# Function to override calls to pass binary. Allows for multiple password-store
# backends. Based on the first argument given to "pass", selects a different
# password store backend.
#
# Example Usage:
#   # Will edit default password-store foo
#   pass edit foo
#
#   # Will edit alternate, team, password-store foo
#   pass team edit foo
#
function pass {
  alt='team'
  if [[ ${1} == ${alt} ]]; then
    export PASSWORD_STORE_DIR=~/.password-store.${alt}
    # Shift off the first argument
    shift
  else
    export PASSWORD_STORE_DIR=~/.password-store
  fi

  # Call the actual binary
  /usr/bin/pass ${@}
}

That will override calls to the pass binary (usually /usr/bin/pass), intercepting the first argument. If the first argument is team, it will look in ~/.password-store.team for passwords. If the first argument is not team, then it looks in the default location, ~/.password-store.