Depending on how your process works, you can maybe just make use of the changeAuthenticationData method on the user object. changePassword.php is just a wrapper around

$status = $user->changeAuthenticationData( [
	'username' => $user->getName(),
	'password' => $password,
	'retype' => $password,
] );

An alternative is revoke the password completely (such as https://phabricator.wikimedia.org/diffusion/EDAC/browse/master/SpecialDisableAccount.php, though we need to make sure this will also work for CentralAuth user).

One important point: we also need to (1) remove the email, otherwise password can be reset using email; (2) revoke the session.

Change #1050675 had a related patch set uploaded (by Mimurawil; author: Mimurawil):

[mediawiki/extensions/CentralAuth@automate-account-vanishing-phase-3] Make password unusable for Vanished accounts

https://gerrit.wikimedia.org/r/1050675

See also my comment at T214722#9936533 (this is the first part; the second part, not directly related to this task, is in another task, now merged into T53837).

Account locking already exists and could be used, while providing the means to undo a bad "vanish" still.

Yeah, but one may argue whether not having a feature to remove password and email complies with GDPR (many website did remove password and email on account closure; they may even have their accounts hard deleted. cf T34815#9437885).

In Stack Overflow, user can delete their account without approval, including when under a suspension (similar to block in Wikimedia); and account deletion is also commonly used to handle VOA/spam-only accounts, sockpuppets and long-term abusive accounts.

BTW: in T214722#9936533 I propose to split the "steal" logic to a new function.

Change #1050675 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@automate-account-vanishing-phase-3] Make password unusable for Vanished accounts

https://gerrit.wikimedia.org/r/1050675

After discussion with Stakeholders, we agreed that at this stage, the current implementation that changes the email and blanks the password is enough to fulfill the scope of the requirements. Followup tasks can be completed if required to improve this.

Then what is the process for "undoing" an "account vanish"? There may be a collision in the terminology and expectations here that need clarification.

In T368524#9948534, @Xaosflux wrote:

Then what is the process for "undoing" an "account vanish"? There may be a collision in the terminology and expectations here that need clarification.

The user rename can be reversed. If necessary, system admins can reset user's password and email so user can log in again.

Note in many sites (such as Stack Overflow and GitHub), account deletion is permanent and irreversible, where user may still register a new account after deletion of the old one. If the purpose of undoing vanishing is prevent avoiding scrunity, simply linking two accounts without reenabling the old one is enough.

So the collision seems to be between parallel use cases/workflows:

a) Courtesy vanishing, handled manually, reversible
b) Whatever this is, which should more likely be called "account deactivation", automated when certain rules are met, irreversible (anything that requires manual dev work is functionally irreversible)
c) Some sort of manual process that allows triggers the "b" output.

Many of our communities have policies about forcibly "unvanishing" accounts in certain conditions, that will either need to adjust their expectations or be accommodated for technically.

forcibly "unvanishing" accounts

I updated my comment above, but say here again: If the purpose of undoing vanishing is prevent avoiding scrunity, simply undo renaming (and linking two accounts public in user page, if policy requires that) is enough. The old account will still be unusable.

Whatever this is, which should more likely be called "account deactivation"

We need this option because app store require it (T292688: iOS app needs option to delete account), and GDPR may also require removing email and password (as PII too).

Courtesy vanishing, handled manually, reversible

When I read the Courtesy vanishing page, I feel very confused ("for whatever reason wishes to make their contributions harder to find" - which use case global rename and clean start did not solve?) so this is my idea:

• Rename "account vanishing" to "account closure" - account closure will be irreversible (without sysadmin work).
• Depracate the current Courtesy vanishing page, mark it as {{historical}}, and replace it with a guide let users to select the current options - if you want to quit permanently and remove all PII, use account closure; otherwise use global rename or clean start. You can be renamed to something like User7992713 that does not involve PII but is still a valid username complies with policy.
  • BTW, user pages may also contain PII so we need to have an option to delete all user pages cross-wiki.

Note: "option to delete all user pages cross-wiki." has been contested by the community. Especially as anything that the user published was already released under an irrevocable license.

I'll admit I have always found the concept of vanishing to be silly, but ...:

may also require removing email and password (as PII too).

How is a password hash personally identifiable information?

BTW, user pages may also contain PII so we need to have an option to delete all user pages cross-wiki.

I don't think the communities will want some script they have no control over to usurp their authority to delete pages. https://meta.wikimedia.org/wiki/Synchbot comes closest, but it has a lot of extra safeguards like not deleting pages if the account has ever been blocked. Presumably it would be uncontroversial to do the same thing Synchbot does, though.

Many of our communities have policies about forcibly "unvanishing" accounts in certain conditions

I don't think any of these will be affected - we won't be able to undo the resetting of the password and email, but that doesn't matter since we can't force the user to resume editing either. What those policies presumably care about is how things appear to other uses of the wiki, not what is stored in the database.

These are likely good things, I've added this topic to next weeks steward meeting (it's been an ongoing topic). We also likely need more phab tasks on this to ensure we delivery a consistent result for the user story of "I want to deactivate my account" regardless of the mode of intake.

How is a password hash personally identifiable information?

It may be, especially when combined with passwords leaked in previous database leaks (in unrelated websites).

Update: Google "is hashed password PII in GDPR" will return some articles saying it is.

In T368524#9951393, @Xaosflux wrote:

These are likely good things, I've added this topic to next weeks steward meeting (it's been an ongoing topic). We also likely need more phab tasks on this to ensure we delivery a consistent result for the user story of "I want to deactivate my account" regardless of the mode of intake.

So if account closure involves removal of password and email, we may want a functionality to allow stewards to revoke password and email of a user (if user privately contact stewards to request account closure). This may however be risky given it is irreversible without sysadmin work.