= Problem =
In [https://lists.fedoraproject.org/archives/list/marketing@lists.fedoraproject.org/thread/BPG7YWGSACVQHEIONTBD4723FTUSKSSK/#BPG7YWGSACVQHEIONTBD4723FTUSKSSK previous discussions], we had talked about secure password management and distribution to safely and securely distribute confidential information such as passwords for social media accounts or other Fedora-related, shared accounts.
We need a system that can handle having multiple "caretakers" that manage all the passwords, user accounts that can individually access certain accounts / passwords, have some kind of convenient way to regenerate passwords if a user is removed or has their privileges changed.
= Analysis =
When we discussed this originally, we decided to approach the Infrastructure team to get their feedback / ideas on such an idea about how to manage this. We also wanted to answer questions such as…
= Enhancement Recommendation =
=== pass === The Infrastructure team originally proposed for us to consider using [https://www.passwordstore.org/ pass], a Unix command line password management utility. Pass uses GPG keys to encrypt passwords and can synchronize them via git.
'''Advantages''' Lightweight, easy to maintain (theoretically) Uses tried and trusted tech to secure passwords (GPG) * Little overhead to maintain a secure repository within Fedora's Infrastructure
'''Disadvantages''' No per-user customization (anyone whose GPG key id is added to the repository has access to all passwords) Requires anyone with access to have understanding and reliability to use GPG as expected * A compromised key could cause issues if someone who needs access is not extremely familiar with using GPG. * Changing passwords in the event of a dropped GPG key means changing ALL passwords in the entire repository for everyone (no modularity in terms of a user who should have access to a subset / specific password)
=== Rattic === I've never used Rattic or do I know much about it, but it seems like a more complete solution than pass. I'm going to CC Brian Proffitt to this ticket in case he can add more context to this discussion.
Eventually, after discussing in a meeting, we'd like to take a vote on this and bring a formal proposal to the Infrastructure team.
'''Discussed in [https://meetbot.fedoraproject.org/fedora-meeting-1/2016-06-29/marketing.2016-06-29-20.57.html 2016-06-29 meeting].'''
= What happened today =
We briefly discussed this during the meeting, and I put out a [https://lists.fedoraproject.org/archives/list/marketing@lists.fedoraproject.org/thread/EBVK5AG5BGRVA6SBIRQ3PSQSCKTPXRZZ/ call on the mailing list] for some other Marketing team members to review this ticket, add comments, and take votes on the two solutions.
= What would be helpful =
I tried to add my best interpretation of advantages / disadvantages to using Pass for our password distribution, although I am biased towards it as I am an active user of it already. I don't know much about [http://rattic.org/ Rattic] nor have I used it, so if anyone who does know more about it could offer up advantages / disadvantages to using it, that would help add context to this discussion.
Looking through the [http://rattic.org/ Rattic website], the developers even provide [https://github.com/tildaslash/RatticWeb/tree/master/docs/ansible Ansible playbooks] for deploying it. Whoa! That's pretty cool, might also be a good factor to consider for Fedora Infrastructure if we choose this tool.
= Taking a vote =
I'm going to withhold taking my final vote on this until either next week's meeting or if someone can add more context / personal experience about using Rattic to the ticket. Looking at Rattic, it seems to cover all of the bases of things we need very well, but I'd like a human verification / +1 from someone else about it before wholeheartedly backing it.
Rattic's last commit was 22 Aug 2015. Lots of unresolved issues on Github [1] as well.
-1 for Rattic.
pass, although having lesser features, seem to have a healthy dose of contributors on their Git repo. Since pass's passwords can be synchronized via Git, I think it is sort of viable since Fedora infra already have a Git system integrated with our current Fedora login. On top of that, Fedora's system supports GPG.
+1 for pass.
[1] - https://github.com/tildaslash/RatticWeb/issues
Sharing passwords is a superbly bad idea.
In case you hadn't seen yet, Rattic is dead: https://github.com/tildaslash/RatticWeb/issues/404 (ironic issue number).
I would strongly object to using that at the very least.
Just wondering, but would it be an idea to instead of sharing the passwords, use a tool that allows social media posting from a web interface without having to share the password?
I bet there's even wordpress plugins to do such things right from within WP...
Just inputting "Open source social media management" showed me http://socioboard.org/....
'''Discussed in [https://meetbot.fedoraproject.org/fedora-meeting-1/2016-07-06/marketing.2016-07-06-21.00.html 2016-07-07 meeting].'''
Firstly, I should have updated this ticket immediately after the meeting last night, which was my mistake. Here's a quick summary of where we're at with this.
= Why =
To add context as to why we're doing this, I think it's important to look at how it's being done already. There seems to be some degree of password sharing already going on with the handful of people who have access to the accounts. I assume the passwords either are or were distributed in a secure manner between the two parties.
Having a standardized method of storing these passwords and distributing them to trusted members ensures that the best practices are being followed with how these passwords are managed. By having a clearly communicated process behind this, it helps prevent less vectors from being exposed from however passwords are distributed now.
Brian put forth three principle needs for defining a policy when it comes to password management and distribution:
The purpose for distributing passwords is so that we can log into the accounts to generate new content (that may not always be from a Fedora source, like the CommBlog and Magazine), engage with our audience, and help build a positive brand.
It's worth noting that same platforms have ways to do this already (Facebook allows you to add accounts to a page, Google+ lets you add page managers). I don't know of a way to do this with Twitter, YouTube, diaspora, or some others. Ideally, storing as little data as possible in a hypothetical database / repository would be preferred.
= Rattic =
Looking at the current state of Rattic and the feedback from woohuiren and puiterwijk, we agreed this is probably not the best solution for us.
= HootSuite / Socioboard =
We recognize the benefits of not storing this data or coming up with alternative means to do so. Having a platform that we could assign a user account to, versus granting a password, would be simpler to manage and make it easy to revoke credentials from a user.
'''HootSuite''': HootSuite is the most powerful and "best" tool for the job, but it is neither free as in freedom or as in beer. After a certain number of users added to an account, the pricing rises sharply to "enterprise" tier. However, it does meet all of the capabilities we'd need from software like it. I think using this comes more of a question about our project principles than anything.
'''Socioboard''': I've spent a far bit of time looking at Socioboard today because it looked exciting and a potential solution to the problem, but there was a catch. There's a paid, "enterprise" version (socioboard.com) and a free, open source core platform (socioboard.org). Going through the FOSS version, it appears to just be the source for the client and server, with not a whole lot of instructions on how to use it. As far as I could tell, we would also have to set up an instance ourselves, as compared to using a hosted instance from the Socioboard team.
With the FOSS version, I could not find such an option available. I left three issues [https://github.com/socioboard/socioboard-core/issues/36 [1]][https://github.com/socioboard/socioboard-core/issues/37 [2]][https://github.com/socioboard/socioboard-core/issues/38 [3]] open on their repository, but I don't know if this project is stable enough for our needs, unfortunately. :(
= Using pass =
pass seems like the best solution available given the context of the above. In our meeting, we had a few ideas how the technical side ''could'' work, but some of the policy questions are still a little bit open.
One idea we thought of to maintain a clear count of who has privileges and access is a git repository locked to members of a particular FAS group. The FAS group would essentially maintain a roster of who has access, and if I understand how some other repositories work, it could be view/write limited to only members of the FAS group.
We also were unsure if using different keys for different directories was possible as linuxmodder mentioned, but he also said it was very difficult to use, so it might be easier to just use one pass repository.
I'm curious: Are there a lot of shared accounts that need to be managed?
Twitter allows teams to be defined through their Tweetdeck.com web site with no need to share passwords. Facebook also allows multiple admins on pages. Hootsuite of course does too (and they may offer a discount to a FOSS project) but they charge per person and the cost does add up.
There are other alternatives like LastPass (mix of propietary & free) which allows shared folders as long as one person pays for a "premium" account, as well as KeePass & KeePassX (both FOSS) and maybe Seahorse. I don't know how the latter ones would work for sharing, e.g., via a private git repo, but it should be easy enough to find out.
Just "food for thought". :-)
Replying to [comment:8 downey]:
Thus far, we manage @Fedora, Fedora on Facebook, the community and brand pages on G+, a Diaspora account, and a Reddit page.
Alas, HootSuite offers no such discount. Would that they did, because this would pretty much solve the situation.
We are looking at pass, coupled with a private git repo. (See next comment.)
In order to manage the Fedora social media accounts, there needs to be a solid plan for managing the accounts to ensure there is no unauthorized access to the accounts. Three principles for defining such a policy should be maintained.
To assist with the management of passwords across a group of users, we can use pass, a command-line tool that will enable a password store (collection of passwords) to be maintained within a git repository.
This repository would be private, and maintained on GitHub, GitLab, or another Fedora-accessibly repo of our choice. Only these people would always have access to this repository:
In addition, other members of this group could include:
This would not only keep an accurate list of who has access to the social medai passwords (via the repo's authorized user list), but would also be a quick and safe way to share changed passwords if a breach occurred on a given social media channel and a password had to be quickly changed. Any changes would be pushed to the remote repository and subsequently pulled into the local forks.
Drawbacks to a single-repository approach would be that all authorized users would have access to all social media channel passwords. This is good for cross-coverage, but could pose a security risk. This risk should be minimized by the vetting of social media content volunteers.
Action Items:
'''Discussed in [https://meetbot.fedoraproject.org/fedora-meeting-1/2016-08-10/marketing.2016-08-10-20.58.html 2016-08-10 meeting].'''
Okay, so there's a lot to summarize!
= Identifying services / tools =
One of the first things we will need to do to move forward on this is identifying any and all services that fall into the case where we cannot "add" a personal account for posting / sharing privileges, like we can with Facebook or Google+.
Twitter is the most obvious example of this off-hand. Diaspora may also fall into this too (but it may just be easier to hook Diaspora up to Twitter, as per [https://lists.fedoraproject.org/archives/list/marketing@lists.fedoraproject.org/thread/M6M42H7AVPTMMN22UEITAY7LXU3A2KEO/ ongoing mailing list discussion]). Are there other things, services, or applications that would need to be stored in a repository like this? If so, what are they? Having a list of them ahead of time will be helpful.
= Skipping password sharing with FAS =
In the IRC meeting, Patrick (puiterwijk) was brainstorming and offering solutions on ways we could bypass the need for having such a repository (it's still not a popular idea in Infrastructure). He was looking into it, and he asked for all current users of the Fedora Twitter to come to a consensus on a client that we want to use for @fedora.
From our discussions, he would be able to write a Firefox add-on / script that allows us to use FAS to log into twitter.com with issuing tokens from a Fedora-controlled source. Alternatively, if we're not fans of twitter.com, if we can find and agree on an open source Twitter client, he offered a way to also build FAS login capabilities for Twitter into that (he described it like it would be fairly easy). I probably butchered this explanation a fair bit, but I'm sure he could leave a more detailed explanation if necessary. :)
Anyways, I'm going to CC a few people to this ticket to try to come to a consensus so Patrick knows which way to attempt (he understandably doesn't want to build this for all different clients and tools). For me, personally, I'd be fine with just using twitter.com for handling all Twitter activity. I know bkp uses HootSuite for social media, though. What about the rest of you?
Oh, forgot to add in, Eduard (x3mboy) found a client called [https://github.com/satanas/Turpial Turpial] that could meet the requirements for a FOSS desktop client for Twitter… for added consideration. I haven't had a chance to give it a spin yet but wanted to leave it here in this ticket for reference.
I'm curious: Are there a lot of shared accounts that need to be managed? Twitter allows teams to be defined through their Tweetdeck.com web site with no need to share passwords. Facebook also allows multiple admins on pages. Hootsuite of course does too (and they may offer a discount to a FOSS project) but they charge per person and the cost does add up.
The main one was twitter. I did not know that tweetdeck.com allowed you to do this!!!. This pretty much solves the twitter issue here, IMHO.
Replying to [comment:13 ryanlerch]:
Details are here: https://support.twitter.com/articles/20171753
Right, Tweetdeck enables you to to manage Twitter channels with multiple users who never see the actual Twitter password. The problem is, since Tweetdeck was acquired by Twitter, it only manages Twitter accounts, not Facebook or G+, as HootSuite, Sprout Social, or Socioboard do.
We can build a day-to-day workflow that enables multiple (free as in beer) tools to handle the various social media channels (we really will be with pass anyway). But ultimately we still need to have a safe location to store the primary account passwords in case someone gets hit by the proverbial bus.
Discussed in [https://meetbot.fedoraproject.org/fedora-meeting/2016-08-16/marketing.2016-08-16-12.59.html 2016-08-16 meeting].
(I'm writing this one in wiki formatting because I think it will be closed before we move to Pagure. ;) )
= Short-term =
= Long-term =
Anyone that currently has access to social media accounts should be aware of this ticket as it will affect access to some services going forward. Once bkp and puiterwijk successfully exchange information and reset passwords, this ticket (and the subsequent one in Fedora Infra Trac) can be closed.
I provided puitewijk credentials for the Twitter account.
The account has been locked down, and all further access should happen through tweetdeck. The current password is stored in the private sysadmin repository.
Login to comment on this ticket.