#229: Shared, secure password distribution
----------------------------------+------------------------
Reporter: jflory7 | Owner: jflory7
Type: enhancement | Status: assigned
Priority: normal | Milestone: Fedora 24
Component: Internal operations | Severity: not urgent
Resolution: | Keywords: meeting
Blocked By: | Blocking:
----------------------------------+------------------------
Comment (by jflory7):
'''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:
1. Transparency
2. Continuity
3. Capability of acting swiftly in the event of a breach
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.
--
Ticket URL: <https://fedorahosted.org/marketing-team/ticket/229#comment:7>
Marketing Team <https://fedoraproject.org/wiki/Marketing>
The Trac site for the Fedora Project Marketing team. This Trac serves as a place to list out tasks, define objectives, and work on monitoring our progress with key tasks and goals.
--
Fedora Marketing mailing list
marketing@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/marketing@xxxxxxxxxxxxxxxxxxxxxxx
