evaluate password management options

added component::internal services/tor sysadmin team owner::tpa priority::low severity::major status::assigned type::task labels

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.

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

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 (moved) for that discussion.

Trac:
Description: 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.

to

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.

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 (moved))
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?

Trac:
Description: 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.

to

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.

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.

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 (moved))

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 (moved) is related, but currently those keys are separate from the above list.

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.

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.

Trac:
Cc: N/A to gk

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?

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.

mentioned in issue #34123 (moved)

mentioned in issue tpo/tpa/team#29671

evaluate password management options

Child items 0

Activity