Opened 15 months ago

Last modified 3 weeks ago

#29677 assigned task

evaluate password management options

Reported by: anarcat Owned by: tpa
Priority: Low Milestone:
Component: Internal Services/Tor Sysadmin Team Version:
Severity: Major Keywords:
Cc: gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by anarcat)

during the org/meetings/2017Montreal/Notes/BusFactor session, one of the things that was discussed was the password management system that is (was?) stored in SVN. Specifically:

  • We need a better password management solution than the one we have in corporate SVN right now.
  • We should look over if the password's in this database should be rotated.
  • Figure out if the passwords for paypal have been rotated by Jon et al and ensure that it will be put in the password database. We should also look into the "paypal dongle" or 2-step authentication?

I have some experience reviewing password managers, so I might be able to provide some advice here if someone expands on the requirements and problems with the current approach.

Child Tickets

Change History (11)

comment:1 Changed 15 months ago by anarcat

I just found out there's a password manager database in git, in ssh://git@git-rw.torproject.org/admin/tor-passwords.git, which is built with weasel's pwstore. not sure how it relates with the discussion in brussels.

comment:2 Changed 15 months ago by anarcat

there's also a KeePassXC instance somewhere used by jon, sue and sstevenson at least.

comment:3 Changed 14 months ago by anarcat

note that another form of password management is the hkdf() function implemented in puppet, for which I am considering using Trocla as a replacement. but that's not really a user-visible password manager, see #30009 for that discussion.

comment:4 Changed 10 months ago by anarcat

Description: modified (diff)

comment:5 Changed 8 months ago by anarcat

Description: modified (diff)

Known password managers:

  • TPA has a tor-passwords repository which uses weasel's pwstore
  • administration also store passwords in SVN
  • Puppet generates passwords on the fly using a puppet-specific token (this might get replaced by trocla eventually, see #30009)
  • each worker probably has their own individual password managers, brains, and post-it notes on screens (hopefully no!) which we don't exactly know about

anything else?

comment:6 Changed 3 months ago by anarcat

might be worth taking a look at arver, a program specifically designed to handle LUKS cryptographic keys, if we're going to reconsider tor-passwords at all.

comment:7 in reply to:  5 Changed 3 weeks ago by sysrqb

Replying to anarcat:

Known password managers:

  • TPA has a tor-passwords repository which uses weasel's pwstore
  • administration also store passwords in SVN
  • Puppet generates passwords on the fly using a puppet-specific token (this might get replaced by trocla eventually, see #30009)
  • each worker probably has their own individual password managers, brains, and post-it notes on screens (hopefully no!) which we don't exactly know about
  • Tor Browser-related passwords:
    • passphrase-protected OpenPGP signing key (package signing)
    • passphrase-protected NSSDB MAR signing key (Tor Browser updates)
    • passphrase-protected Windows Authenticode signing key
    • passphrase-protected MacOS code signing key
    • passphrase-protected Android code signing key
    • user/admin accounts on macOS/linux/windows signing machines
    • Google account (for publishing Android apps)
    • ...

Currently, these are only shared in person (via military-grade post-quantum encrypted point-to-point subspace transmission).

While this "works", I'd really appreciate having an easier and more fault-tolerant way of securely sharing this information (given the importance of keeping this information private). I don't know if such a system exists as a solution that Tor can deploy, but that's another wish-list item of mine :)

#34123 is related, but currently those keys are separate from the above list.

comment:8 Changed 3 weeks ago by anarcat

Currently, these are only shared in person (via military-grade post-quantum encrypted point-to-point subspace transmission).

Could you clarify how subspace transmissions work? I'm actually curious in having a solid inventory of the different mechanisms.

While this "works", I'd really appreciate having an easier and more fault-tolerant way of securely sharing this information (given the importance of keeping this information private). I don't know if such a system exists as a solution that Tor can deploy, but that's another wish-list item of mine :)

What do you mean by "fault-tolerant" here? And I'll note that there are *many* password managers out there, and surely there is one that would fulfill your dreams.

One question, for me, is also whether we should have "one big password manager" for everyone or multiple databases. And even with multiple databases, we should decide whether we use the same software everywhere so that user on team A doesn't get a bad surprise when they try to work with team B.

comment:9 in reply to:  8 Changed 3 weeks ago by gk

Cc: gk added

Replying to anarcat:

Currently, these are only shared in person (via military-grade post-quantum encrypted point-to-point subspace transmission).

Could you clarify how subspace transmissions work? I'm actually curious in having a solid inventory of the different mechanisms.

While this "works", I'd really appreciate having an easier and more fault-tolerant way of securely sharing this information (given the importance of keeping this information private). I don't know if such a system exists as a solution that Tor can deploy, but that's another wish-list item of mine :)

What do you mean by "fault-tolerant" here? And I'll note that there are *many* password managers out there, and surely there is one that would fulfill your dreams.

One question, for me, is also whether we should have "one big password manager" for everyone or multiple databases. And even with multiple databases, we should decide whether we use the same software everywhere so that user on team A doesn't get a bad surprise when they try to work with team B.

I am not even sure sysrqb has the same problem as described in this ticket: it seems comment:7 is talking about the issue of *sharing* the password securely while this ticket is about *storing* the password securely. Those are different issues. Even if you store Tor Browser related passphrases in whatever super secure environment you have you still have the sharing problem unsolved.

Last edited 3 weeks ago by gk (previous) (diff)

comment:10 Changed 3 weeks ago by anarcat

i'm running with the assertion that a password manager solves both the storage and sharing aspects of the password management problem. sharing and storing are, generally, tangled together in any case: when you send an email, for example, it gets stored in a queue. there are mechanisms to store passwords without sharing them (e.g. secure enclaves) but those can have dubious properties (e.g. being exploitable, like Intel's).

but it is true it might be useful to consider hardware tokens for signing things, in the case of software releases and, indeed, that is how Debian is deploying secureboot right now. the advantage is that even in a compromise, the private key cannot (in theory) be stolen, so you have a limit to what an attacker can do.

is this part of your threat model?

Last edited 3 weeks ago by anarcat (previous) (diff)

comment:11 in reply to:  10 Changed 3 weeks ago by sysrqb

Replying to anarcat:

i'm running with the assertion that a password manager solves both the storage and sharing aspects of the password management problem. sharing and storing are, generally, tangled together in any case: when you send an email, for example, it gets stored in a queue. there are mechanisms to store passwords without sharing them (e.g. secure enclaves) but those can have dubious properties (e.g. being exploitable, like Intel's).

This was my thought, as well.

but it is true it might be useful to consider hardware tokens for signing things, in the case of software releases and, indeed, that is how Debian is deploying secureboot right now. the advantage is that even in a compromise, the private key cannot (in theory) be stolen, so you have a limit to what an attacker can do.

is this part of your threat model?

Yes, (almost) all of our keys are stored in hardware tokens. We have separate signing infrastructure where these are attached to machines. However, I'd like a way for sharing the passphrases that allow signing.

Note: See TracTickets for help on using tickets.