Page MenuHomePhabricator

CheckUser login: Some failed login events appearing as logging into an IP address
Closed, ResolvedPublic

Description

Summary

Several users have reported seeing IP addresses as the username for failed login attempts in CheckUser. We should investigate the cause and fix the issue so that the username entered is displayed.

Background

  • The CheckUser extension allows users to see failed login attempts on accounts
  • Some of these failed login attempts on WMF wikis are appearing where the username is the IP address used to make the login attempt
  • This should not be occurring as it is unlikely that users are entering their actual IP address in when attempting to sign in to an account

Acceptance criteria

  • The cause of these incorrect events is determined
  • The events no longer appear as incorrect

Event Timeline

@Dreamy_Jazz are these user reports still occurring? Are there recent examples you can link in a private paste?

@Dreamy_Jazz are these user reports still occurring? Are there recent examples you can link in a private paste?

A rough count suggests about ~9,000 of these invalid failed logins in the last 90 days just on the English Wikipedia. Today there were 64 of these on the English Wikipedia. Added more detail to P79351.

I think the first step we could take is to create a logstash log for debugging purposes when this happens. That would likely help us find where the issue is coming from.

Change #1170413 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/CheckUser@master] Warn when login log is created for login to IP address

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

Need to wait until we start getting logs sent our way and then we can pick this task back up.

Change #1170413 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Warn when login log is created for login to IP address

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

This appears to be caused by:

  • The IP address of the user is blocked on a local wiki
  • An existing user attempts to login on a wiki where they do not have a local account
  • The login fails because the autocreation is denied by the local IP block

This appears to be a bug where:

  • AuthManager::autoCreate to resets the $user to an anon user if the autocreation fails
  • This means that the AuthManagerLoginAuthenticateAudit hook run uses the anon user for the "User being authenticated against"

Fixing it so that the $user object passed to the hook is the user which was being authenticated against should address this problem.

Change #1173962 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/core@master] AuthManager: Don't use anon for audit hook if autocreation failed

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

Change #1173963 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/CheckUser@master] CheckUserPrivateEventsHandler: Update warning for failed login to IP

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

Change #1173963 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] CheckUserPrivateEventsHandler: Update warning for failed login to IP

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

Change #1173962 merged by jenkins-bot:

[mediawiki/core@master] AuthManager: Don't use anon for audit hook if autocreation failed

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

I see all patches associated with this task have been already merged, and T390051#11043496 suggests the cause for the error was already found and fixed by those patches (1173962). Should this be moved forward for QA?

This appears to be caused by:

  • The IP address of the user is blocked on a local wiki
  • An existing user attempts to login on a wiki where they do not have a local account
  • The login fails because the autocreation is denied by the local IP block

This appears to be a bug where:

  • AuthManager::autoCreate to resets the $user to an anon user if the autocreation fails
  • This means that the AuthManagerLoginAuthenticateAudit hook run uses the anon user for the "User being authenticated against"

Fixing it so that the $user object passed to the hook is the user which was being authenticated against should address this problem.

Moving to QA, we can verify when wmf.13 is in production next week.

It is possible that we find other instances when the log is created, so this may need to move back to in progress if we see more logs.

It looks like the fix to AuthManager may have done it, but want to verify next week that we see no entries in cu_private_event which are an issue in enwiki from today.

Dreamy_Jazz closed this task as Resolved.EditedAug 11 2025, 12:34 PM

We can skip QA because we are no longer seeing these kinds of events in cu_private_event on WMF production enwiki:

(enwiki)> select count(*) from cu_private_event where cupe_log_action = 'login-failure' and cupe_title = cupe_ip and cupe_timestamp > '20250808000000';
+----------+
| count(*) |
+----------+
|        0 |
+----------+

We can leave the warning in the code in case this happens again through a regression.