Currently, there are two ways to assert control of a wiki account:
- By knowing its password (which allows you to change the password and the associated email)
- By having access to its email (which allows you to reset the password)
(plus a few 'detached' ones, such as identity commits or additional accounts linked from the account)
A wiki account may be compromised by compromising any of those methods.
If the email account was compromised, the only recourse of the user is to change the email associated to the account before the attacker resets the password.
If the account password was compromised (which is probably more common, does anyone have numbers here?), the old owner receives a notification email about it,¹ but the attacker will have changed both the email and password by the time the original owner reads it. Moreover, the victim is simply told "If this was not you, contact a site administrator immediately.", which is an acceptable advice for a generic MediaWiki install, but suboptimal for Wikimedia sites.
To begin with, from that message the user would go to contact a sysop (if any), which is completely unable to do anything about it, or even know if that person is in any way related to the account. T95829 proposes that the "real user" should be able to override it. However, here we don't know who the "real user" is. We have a split identity. It could be a case of a compromised password or a compromised email. Nevertheless, letting a compromised account unactioned is also a wrong choice, and it will bite you later.
I thus pose that when there is an email change, the notification message should contain a link with a token, valid for one week² which lets the holder open a page where they can fill out a textarea explaining the issue (e.g. "Help! I am hacked." or "I didn't change the email or password, but no I can't login") that, on submit, automatically locks the account and opens a ticket to be reviewed.³ By having an actual human, we can protect from an attacker trying to game the system, and assess the arguments given by both parties. the technical evidence relative to the account and its prior usage, as well as other means that may link it to other accounts.
Automatically locking the accounts, means the account may do no harm once detected by the owner (with no need to somehow demonstrate that they _are_ the real user to get it blocked), and allows giving a clear actionable to the victim: it is possible that someone stole your car, click here to stop it from being driven.
¹ notificationemail_body_changed / notificationemail_body_removed
² quite arbitrarily set, but this seems about right
³ By the Trust-and-Safety team, probably