Repository for shared, secure password distribution #5423

Closed
opened 2016-08-01 00:21:08 +00:00 by jflory7 · 6 comments
Member

= phenomenon =

In [https://fedorahosted.org/marketing-team/ticket/229 marketing#229], the Marketing team has put together a policy and proposal for managing shared passwords for social media accounts in a secure environment. We'd like to request the advice and the creation of a private repository for managing the passwords.

= background analysis =

Passwords would be stored in a single repository, managed by [https://www.passwordstore.org/ pass], a CLI password management utility. pass uses GPG encryption for encrypting and decrypting passwords. Privileges would be granted based on the [https://admin.fedoraproject.org/accounts/group/view/fedora-socialmedia fedora-socialmedia] FAS group.

[https://fedorahosted.org/marketing-team/ticket/229#comment:10 marketing#229c10] best describes the current proposal.

= implementation recommendation =

We would like to know what the thoughts of the Infra team is on this approach and any ideas for securely managing this information in a shared environment.

= phenomenon = In [https://fedorahosted.org/marketing-team/ticket/229 marketing#229], the Marketing team has put together a policy and proposal for managing shared passwords for social media accounts in a secure environment. We'd like to request the advice and the creation of a private repository for managing the passwords. = background analysis = Passwords would be stored in a single repository, managed by [https://www.passwordstore.org/ pass], a CLI password management utility. pass uses GPG encryption for encrypting and decrypting passwords. Privileges would be granted based on the [https://admin.fedoraproject.org/accounts/group/view/fedora-socialmedia fedora-socialmedia] FAS group. [https://fedorahosted.org/marketing-team/ticket/229#comment:10 marketing#229c10] best describes the current proposal. = implementation recommendation = We would like to know what the thoughts of the Infra team is on this approach and any ideas for securely managing this information in a shared environment.
Owner

So, the only big downside I can think of here (and forgive me if it's already been noted): The way pass words is that it will encrypt all files for the set of keys. If you add a new user, you will need to 'touch' all the password files to get it to re-encrypt including the new person. Also, when removing a user you will need remove their key and change ALL the passwords, because in git history (and their local copies) they can still read/decrypt these (and also of course they could have copied them at anytime they had access anyhow).

Aside from that limitation I think it should work ok.

What about using a pagure repo/project? We don't have private repos yet, but should soon.

So, the only big downside I can think of here (and forgive me if it's already been noted): The way pass words is that it will encrypt all files for the set of keys. If you add a new user, you will need to 'touch' all the password files to get it to re-encrypt including the new person. Also, when removing a user you will need remove their key and change ALL the passwords, because in git history (and their local copies) they can still read/decrypt these (and also of course they could have copied them at anytime they had access anyhow). Aside from that limitation I think it should work ok. What about using a pagure repo/project? We don't have private repos yet, but should soon.
Author
Member

As an update for this ticket: discussion is ongoing in [https://fedorahosted.org/marketing-team/ticket/229#comment:11 marketing-team#229]. puiterwijk doesn't like the downsides to this either and offered to try to build a custom workaround for using FAS to gain login access to the Twitter specifically. More details will be shared here as we have them. But for now, this ticket is still a "work in progress". :)

As an update for this ticket: discussion is ongoing in [https://fedorahosted.org/marketing-team/ticket/229#comment:11 marketing-team#229]. puiterwijk doesn't like the downsides to this either and offered to try to build a custom workaround for using FAS to gain login access to the Twitter specifically. More details will be shared here as we have them. But for now, this ticket is still a "work in progress". :)

This has been fixed in another way.

This has been fixed in another way.

This has been fixed in another way.

This has been fixed in another way.

@puiterwijk changed the status to Fixed

@puiterwijk changed the status to ``Fixed``

This has been fixed in another way.

This has been fixed in another way.
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
infra/tickets#5423
No description provided.