Page MenuHomePhabricator

Avoid storing secrets on wiki.wikimedia.it not to require complex ACLs
Open, MediumPublic

Description

Preamble

Since a couple of months the Wikimedia Italia's MediaWiki at https://wiki.wikimedia.it could be upgraded and we could introduce some interesting features like VisualEditor T268529.

But... we are blocked by T270456 (internal Task). The underlying well-known problem is that MediaWiki is not designed to keep a secret.

Proposal

We could try to simplify the management of this wiki changing the way it's currently in use.

For example, adopting this rule of thumb:

  • I have something weird that someone should not edit OK for wiki ACLs
  • I have something secret that someone should never see DON'T use wiki ACLs

Dirty work

Someone with a good ACL level (e.g. staff) should research all the current secrets stored in reserved namespaces of that wiki:

NOTE: I have no idea what's in there.

From the list obtained from this research:

  1. move the pages into something else (for example into the nextCloud archive or into the Wikimedia Phabricator's Passphrase component; you know where but just not on this wiki)
  2. delete each secret page once migrated

Event Timeline

(P.S. We was taking about this issue with @Laurentius and @Maupao70 and @Ferdi2005 in the past weeks.)

First steps: Francesca Lissoni said she did a lot of cleaning in the past days and removed all passwords from these namespaces.

In principle no password should be stored on the wiki, but what alternative has been choosen? Where are those passwords?

In general, the best scenario would be to only have personal accounts, linked to an organization that owns the resources (e.g., if you are on GitHub, hosting the repository under an organization, with multiple personal accounts as team members), but in most cases this is not possible (there may be only individuals, without organizations, or only organizations, without individuals). Therefore a way of sharing the password is needed.

Without a shared repository, you get into an hell of lost passwords and secrets shared by email or on post-it notes, with high risk of losing access, and a medium level of security risk due to insecure communications.
Using the wiki solves the first problem with an existing tool, at the cost of enlarging the circle of the people who have access to the secrets.

If the wiki is no longer going to be used, what is the alternative? Is there one in place?

An option is to use a password manager like KeepassXC, storing the database in a file shared on Nextcloud. Pros: it is encrypted; it is not linked to the same credentials of the wiki, therefore access to your browser is not enough to get the passwords; when you say that you use a "password manager" people will think that it must be something secure. Cons: everyone who has access will still have access to all passwords (no granular access); a new tool is needed; there is no history (except for the limited Nextcloud file history), leading to a greater risk of loss of data and reduced auditability.

I would expect that better solutions exists, but I don't know any.

By the way, passwords aside, there is a lot of confidential information in those namespaces. That's the whole point of having restricted-access namespaces.

(Well, actually maybe not so much a lot. The Direttivo namespace has very few pages, most of which confidential. The Ufficio namespace has a lot of pages, most of which don't have much confidential information).

One of the ideas was to download the entire namespace and put it in nextCloud and then go with rm -Rf.

asd

Imagining an ideal future, it would be nice if those namespaces contained publishable information, editable only by certain people. MediaWiki is great in doing this.

What would be the use case of a namespace read-only for some users?
There are things that should not be edited, but it is still annoying if you can't fix a typo or a link...

What would be the use case of a namespace read-only for some users?
There are things that should not be edited, but it is still annoying if you can't fix a typo or a link...

My friend, I also absolutely don't know but "hiding stuff && preventing edit" (current) VS just "preventing edit" may sound like an intermediate solution to give more authority over a given information.

Well, not necessarily. Restricted access and restricted edit have different purposes. Confidential information exists; it may be stored on-wiki or off-wiki. If it cannot be stored on-wiki, it will go somewhere else. Having it read-only would not solve any problem because the problem is exactly with the "reading" part. For things that are not confidential, I do no see a strong case for read-only pages; it is true that, for instance, the text of approved resolutions cannot be changed, but there are still many reasons why one may want to edit the page without editing the text.

We could try to simplify the management of this wiki changing the way it's currently in use.

This is an overkill solution for a very simple problem, i.e. passwords should not be stored in plain text. To solve the issue for the wiki, just create an encrypted Keepass store, share it via Nextcloud with as few users as possible, share the passphrase by secure methods (e.g. PGP email, piece of paper delivered in person, at worst a phone call).

Note that the wiki is not the only or the worst place where people (especially employees) store passwords in plain text.

Nemo_bis renamed this task from Avoid to store secrets in https://wiki.wikimedia.it to Avoid storing passwords and similar secrets in plain text on wiki.wikimedia.it.Jun 12 2021, 11:07 AM
Nemo_bis triaged this task as Medium priority.
valerio.bozzolan renamed this task from Avoid storing passwords and similar secrets in plain text on wiki.wikimedia.it to Avoid storing secrets on wiki.wikimedia.it to do not require complex ACLs .Jul 30 2021, 9:38 AM
Ferdi2005 renamed this task from Avoid storing secrets on wiki.wikimedia.it to do not require complex ACLs to Avoid storing secrets on wiki.wikimedia.it not to require complex ACLs .Jul 30 2021, 10:00 AM