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.
Here are the known password managers currently in use:
Puppet generates passwords on the fly using a puppet-specific token (this might get replaced by trocla eventually, see #30009 (closed))
Tor browser team's "military-grade post-quantum encrypted point-to-point subspace transmission"
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
Possible replacements:
password-store AKA pass AKA OpenPGP encrypted files in a git repository, replacement for pwstore
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.
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 legacy/trac#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.
Puppet generates passwords on the fly using a puppet-specific token (this might get replaced by trocla eventually, see legacy/trac#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.
Puppet generates passwords on the fly using a puppet-specific token (this might get replaced by trocla eventually, see legacy/trac#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
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 :)
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.
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.
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.
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.
doesn't autogenerate passwords, which makes password rotations harder
stores secrets in Hiera, which you might not want because Hiera is often replicated in a bunch of places
doesn't support the multiple hash formats like Trocla, so you need an external tool to generate those
secrets are "encrypted", but the server (and clients!) actually need to know the secret to be able to access the plaintext and then hash it again
Trocla:
supports many hashes, so can keep a "hash-only" version of the password, if the client only need that, or, in other words, neither the client or the server need access to the plaintext
does not need to be stored in Hiera, but can act as a (separate, so not necessarily in git) Hiera backend
can automatically generate passwords, which makes rotation easier (just erase the password from the database, and it gets rebuilt)
can also act as a CA and therefore do automatic certification rotation and revocation
The Trocla authors actually store the plaintext of the passwords out of band, in a separate password manager (e.g. we'd store them in pwstore, for example) and keep them out of trocla as much as possible. So in that sense it's not a replacement for a password manager, but a complement.
With that in mind, i wouldn't recommend hiera-eyaml in our infra.
Can we move this issue into the backlog so we consider it sooner rather than never?
Icebox doesn't mean "never", as far as I know. "Never" is "Closed". :) And trust me, I don't hesitate to close issues. ;)
I interpret "backlog" as "next month" so I'm a little hesitant in committing to overhauling the entire password management system at TPI by the end of january. ;)
Yes. Icebox does not mean 'never' but it is for a future that we do not even see :) I didnt realized you had backlog as 'next month'. In that case just leaving it in icebox is fine. Otherwise I would put it at the bottom of the backlog.
I'm thinking that this could be something for next year (not next month for sure).
Yes. Icebox does not mean 'never' but it is for a future that we do not even see :) I didnt realized you had backlog as 'next month'. In that case just leaving it in icebox is fine. Otherwise I would put it at the bottom of the backlog.
I'm open to suggestions as to how to create a long-term roadmap. Right now I'm struggling with keeping the Backlog somewhat meaningful: there's already so much stuff in there that it's hard to wrap our head around it. If we start shoving everything in there, we'll never get anything done in it and it becomes a meaningless tool.
Ideally, Icebox would basically be "next 6 months" or something.
How are other teams dealing with this? What's the timeline associated with those labels elsewhere?
I plan on working on the 2021 roadmap in Januaray, for what it's worth, after the user survey (#40061 (closed)). :)
Can we move this issue into the backlog so we consider it sooner rather than never?
Another way to ensure this will get picked up eventually is assign the issue to someone, right now it's unclaimed so it's unlikely someone will pick it up. I'd be happy to see a more concrete task list here to have a set of clear goals for the issue..
Right now I'm mostly at the brainstorm stage and it's not clear to me what the objectives are outside of TPA. My personal todo would be:
I'm doing a similar evaluation as @anarcat regarding which password manager(s) to use in a new project for a narrow use case: how to generate (locally), backup, distribute (among sysadmins) and deploy Onion Services' keys.
The following considerations might be specific for my use case but perhaps they could also help the broader issue addressed in this ticket. And perhaps you have suggestions on how to proceed in my case, but that's not meant to hijack this issue in any way :)
I wrote keyringer (also available on Debian and it's known to run on *BSDs) when trying to address the issue of sharing secrets among teams of developers/sysadmins.
It's designed to be easy to use, to audit and to understand the code, supporting separate keystores and relying basically on GnuPG (crypto layer) and Git (distribution), meaning that you can manage a repository without even have keyringer installed in your system and just using Git and GnuPG directly.
I use it daily in many projects and it fits the case of a being a canonical repository for secrets (not only passphrases or keys, but any file).
It's similar to password-store but supports more than a single repository out-of-the-box.
I'm strongly considering to use it for Onion Services' key handling but I'm also looking for other options. Some users might not have their own OpenPGP keypair, so I'm considering if the project should have a procedure to manage a contextual OpenPGP keypair for each sysadmin managing an Onion Services pool.
About hiera-eyaml versus trocla, it seems the later fits more in the use case discussed here in this issue, but I only have experience with hiera-eyaml with a masterless Puppet setup.
It's similar to password-store but supports more than a single repository out-of-the-box.
I'm strongly considering to use it for Onion Services' key handling but I'm also looking for other options. Some users might not have their own OpenPGP keypair, so I'm considering if the project should have a procedure to manage a contextual OpenPGP keypair for each sysadmin managing an Onion Services pool.
For what it's worth, i'm aware and familiar with keyringer of course. :)
i have maintained a ridiculously large inventory of password managers at
my previous work here:
keyringer is second, right below password-store. i tend to favor
password-store, in general, because it's more well known and it has
multiple clients (e.g. GUIs and other implementations) and integration
(e.g. web browser plugin, rofi, etc).
but I understand if you would prefer using it for your project. after
all, it's just OpenPGP-encrypted files, right? what could possibly go
wrong? :)
are the storage layouts compatible with each other?
i will also point out that password-store also supports multiple
repositories...
About hiera-eyaml versus trocla, it seems the later fits more in the use case discussed here in this issue, but I only have experience with hiera-eyaml with a masterless Puppet setup.
we have now adopted trocla in puppet, for what it's worth. it's also
possible to plug it into hiera.
...
On 2022-02-16 13:36:52, Silvio Rhatto (@rhatto) wrote:
--
Antoine Beaupré
torproject.org system administration
I could go as well in adopting password-store in the project I'm working, as it looks like nowadays it supports multiple OpenPGP keys (which it didn't when I wrote keyringer).
The storage layouts aren't compatible, but I believe it's easy to migrate from one format to the other.
i want to review this in 2024. we're wasting a good amount of time fighting with pwstore for various things. most notably, the storage is somewhat clunky: it has a convention of storing everything in a single file that looks like YAML but i bet probably isn't. so it's hard to extract stuff programmatically from it. it's also yet another keyring to maintain, with no clear security benefit.
the latest concrete example where i needed something from pwstore and it failed to provide was "please allow me to retrive a kgb-bot client credentials, including username, from the password store programmatically". at the very least, i'm not currently able to parse the hosts-extra-info file as YAML:
tor-passwords$ gpg -d < hosts-extra-info | yq .yq: Error running jq: ScannerError: while scanning for the next tokenfound character that cannot start any token in "<stdin>", line 1, column 9.
to be reviewed, but i'm considering just converting everything into a pass password store.
a key concern i have with pass (and pwstore, for that matter) is revocation: it's one thing to understand that someone can keep a copy of your secrets as they leave, but it's kind of an order of magnitude worse if they keep the whole HISTORY of those secrets. git is useful as a synchronisation mechanisms (especially because it marks conflicts), but maybe we should consider other options for this specific repository. i'm actually thinking syncthing could be a good option here, but that also need a little more thought.
to be reviewed, but i'm considering just converting everything into a pass password store.
while doing some offboarding (tpo/tpa/team#41519), i fought with pwstore again, maybe key management issues. password-store works around those because it relies on the built-in keystore which isn't as secure, but it does have a key fingerprint hardcoded in the repo, so it should be Fine.
i'm actually thinking syncthing could be a good option here, but that also need a little more thought.
i don't have a solution for this, but i will point out that having individual files will make conflict resolution easier in such a scenario. so first step is to split the secrets.
i would start from a clean history too.
i would also make sure we keep the current access levels and go one step further: we should have a separate level for really critical stuff like joker and hetzner.
i've had two different people ring my ears about Bitwarden now, saying they are happy with it and that it would serve us well. i'm a little worried about the open core aspects, according to Wikipedia, those are the features that are "paid":
1GB encrypted file attachments
Yubikey TOTP logins (FIDO2 free)
Bitwarden authenticator ("code generator and automatic fill-in" according to wikipedia, TOTP secret storage free)
encrypted file sharing (text free)
emergency contacts
"Exposed, Reused, Weak passwords reports" (password testing and haveibeenpwned free)
My main concerns with it, are:
what happens when/if the server gets compromised? it seems to stored the derived encryption key for users, which could then be attacked, especially a problem since password strength controls are voluntary in the free version
no packages in debian: the server (C#), and client (Typescript) are not packaged in Debian, and seem to be available as "app images" upstream... there are also mobile clients and browser plugins
extra maintenance: currently, the password manager is hosted in a git repository and has very little overhead, bitwarden would be yet another server that would need to be available for things to work, although apparently it uses a "sync" model so that clients can still work offline...
I would focus less on Bitwarden, and more on Vaultwarden its a free software, rust re-implementation of the bitwarden server. Its way more lightweight, and it provides nearly all the same functionality as Bitwarden itself. You do use their clients to access it, but that is a feature, not a bug.
That said, bitwarden does publish their audits on their code, which they do get, and they get certification as well, so free software alternatives maybe have to be weighed against those considerations.
About the server getting compromised... I think, without more understanding of the architecture, it would result in access to the encrypted vault(s), not the actual clear-text of the vault contents or the passwords used to decrypt them. This seems to be an improvement over what is there now: random people storing passwords on their personal computers in all kinds of different ways. I'm sure people have passwords stored in their firefox password managers, in clear text in files on their computers, some have them stored encrypted to their openpgp keys using pass, which is good, but it does spread the attack radius around to every single person's machine and how they handle passwords needs to be secure.
About the server getting compromised... I think, without more understanding of the architecture, it would result in access to the encrypted vault(s), not the actual clear-text of the vault contents or the passwords used to decrypt them
that is my understanding of the architecture as well, but my concern would be that this exposes the master password to a dictionary attack. but i'll read their whitepaper before making a fool of myself.
This seems to be an improvement over what is there now: random people storing passwords on their personal computers in all kinds of different ways. I'm sure people have passwords stored in their firefox password managers, in clear text in files on their computers, some have them stored encrypted to their openpgp keys using pass, which is good, but it does spread the attack radius around to every single person's machine and how they handle passwords needs to be secure.
Oh yeah, for sure: having this as a policy would be a great improvement and, as always, a policy without offering people the tools to implement it, is crap. :p Bitwarden certainly seems like an interesting project for us.
And thanks for vaultwarden, really interesting as well! Would probably match with our infrastructure (e.g. postgresql) better than the official server (MSSQL!) although i do wonder if they have been audited...
that is my understanding of the architecture as well, but my concern would be that this exposes the master password to a dictionary attack. but i'll read their whitepaper before making a fool of myself.
i'd be less concerned about a brute force attack, with a proper KDF/argon2id setup, it would be pretty resource intensive.
I'd also not consider a dictionary attack as a problem, as this is a policy problem, and it appears with everyone's personal gpg key on their computers. Compromise anyone's computer who runs pass and then dictionary attack their secret key passphrase, same issue. It comes down to ensuring that people use strong passwords, setting a policy of something like minimum 5 word diceword password would at least eliminate the dictionary attack.
i'd be more concerned about if the server is compromised, the best approach for an attacker would probably be to just phish your master password, by adding some middleware on your compromised machine, to grab it on your next input.
that is my understanding of the architecture as well, but my concern would be that this exposes the master password to a dictionary attack. but i'll read their whitepaper before making a fool of myself.
i'd be less concerned about a brute force attack, with a proper KDF/argon2id setup, it would be pretty resource intensive.
I'd also not consider a dictionary attack as a problem, as this is a
policy problem, and it appears with everyone's personal gpg key on
their computers.
True, but one could argue a server is more exposed than an individual
workstation, and also holds access to all the keys, as opposed to a
subset.
i'd be more concerned about if the server is compromised, the best approach for an attacker would probably be to just phish your master password, by adding some middleware on your compromised machine, to grab it on your next input.
Yeah, that too! :) But then again, the same argument could be made with
a workstation attack.... hmmmm