Page MenuHomePhabricator

Wikitech password reset flow
Closed, ResolvedPublic

Description

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.

Event Timeline

JBennett created this task.Mar 26 2019, 1:17 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 26 2019, 1:17 PM
chasemp changed the visibility from "Public (No Login Required)" to "Security (Project)".Mar 26 2019, 1:20 PM
chasemp triaged this task as Normal priority.

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?

Tgr added a subscriber: Tgr.Mar 26 2019, 4:37 PM
Tgr added a comment.Mar 26 2019, 4:49 PM

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.

This comment was removed by chasemp.
chasemp changed the visibility from "Security (Project)" to "Public (No Login Required)".
bd808 added a subscriber: bd808.Mar 26 2019, 7:35 PM
WingedBladesofGodric raised the priority of this task from Normal to Unbreak Now!.Mar 26 2019, 7:36 PM

Obvious.

Restricted Application added subscribers: Liuxinyu970226, TerraCodes. · View Herald TranscriptMar 26 2019, 7:36 PM
bd808 lowered the priority of this task from Unbreak Now! to High.Mar 26 2019, 7:41 PM

Let's not have edit wars on the priority of tasks, especially just to signal that people are annoyed by the issues.

Tgr added a comment.EditedMar 26 2019, 8:49 PM

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.

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.

Tgr closed this task as Resolved.EditedApr 3 2019, 12:55 AM

The temporary password is stored in the user table, not in LDAP. And the user can't login with it due to $wgBlockDisablesLogin.

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.