Skip to content

TPA-RFC-62: migrate tor-passwords to password-store

In #29677, we have reviewed a bunch of password managers. Bitwarden seems to be emerging as a possible candidate for an organisation-wide password management service, but in the short term however, we do not want to make any major changes to our workflow. There's also an argument to be made that TPA should not be using a global password manager and is best protecting those secrets with a a different mechanism.

In any case, during a recent offboarding process (tpo/tpa/team#41519), it became very clear that our current password manager (pwstore) has major flaws:

  1. key management: in this case, @hiro's key was expired and had to be manually removed from the user's list. this would be similar in pass, except that the keyid file is easier to manage, as its signature is managed automatically by pass init, provided that the PASSWORD_STORE_SIGNING_KEY variable is set
  2. password rotation: because multiple passwords are stored in the same file, it's hard or impossible to actually see the last rotation on a single password
  3. conflicts: because multiple passwords are stored in the same file, we frequently get conflicts when making changes, which is particularly painful if we need to distribute the "rotation" work
  4. abandonware: a pull request to fix Debian bookworm / Ruby 3.1 support has been ignored for more than a year at this point
  5. counter-intuitive interface: there's no command to extract a password, you're presumably supposed to use gpg -d to read the password files, yet you can't use other tools to directly manipulate the password files because the target encryption keys are specified in a meta file (that latter issue is shared with pass, to be fair)
  6. not packaged: pwstore is not in Debian, flatpak, or anything else

The main downside to pass is the .gpg-id system is less secure than pwstore: its signature is not enforced unless the environment variable is set, which is a bit brittle. It's also relying on the global GPG key store although in theory it should be possible to rely on another keyring by passing different options to GnuPG.

Finally, by splitting secrets into different files, we disclose which accounts we have access to, but I consider this a reasonable tradeoff for the benefits it brings.

Update: the above was put in an actual proposal, see https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-62-tpa-password-manager

Edited by anarcat