Let's investigate and solve where needed a couple issues we think might be in play.
It appears that when wikitech ldap password is either blanked or scrambled by an admin in an effort to block a malicious actor, the attacker is able to evade this block by following the password reset flow and obtaining a new credential. We would like to verify this still works and if it does come up with a solution to prevent it.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | bd808 | T219316 Cannot reset password for Wikitech account | |||
| Resolved | • JBennett | T219277 Wikitech password reset flow |
We also removed (LDAP) or reverted (Wikitech MySQL) the email address though, so this should not be possible given that they can't receive mail anymore?
Yeah, there's no reason why that wouldn't work, it looks like a legitimate use of password reset from MediaWiki's point of view. I guess it should check whether the user is blocked and $wgBlockDisablesLogin is set.
User::newSystemUser() (the part where it acts on the steal option) is, in theory, the way to reliably revoke access from a user. We should probably have a maintenance script that does that.
Let's not have edit wars on the priority of tasks, especially just to signal that people are annoyed by the issues.
Sorry, I did not think that through. The temporary password is stored in the user table, not in LDAP. And the user can't login with it due to $wgBlockDisablesLogin. So I don't think how this could happen. I'll test just in case but I don't think there's any problem here.
More specifically, login for blocked users is aborted by CheckBlocksSecondaryAuthenticationProvider, which precedes ResetPasswordSecondaryAuthenticationProvider which is the one that handles password resets.
Also confirmed manually that this works as expected.