(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.

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...

In T273607#6905867, @Laurentius wrote:

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.

As far as I can tell, this task ("Avoid storing secrets on wiki.wikimedia.it") has been completed. The part "not to require complex ACLs" is unclear so it could be dropped from the title.