Page MenuHomePhabricator

Checkuser option "get users" should point out when user password is changed
Closed, DeclinedPublicFeature

Description

When checking an IP *edits*, we can notice when this IP was used to change password. However, when checking IP *users*, it doesn't show this user that had password changed with this same IP.

It would make things easier to find accounts used by same IP. We may have been missing to identify some accounts as "get users" is used to do it.

Thanks,
--Teles
https://pt.wikipedia.org/wiki/Usu%C3%A1rio:Teles

Details

Reference
bz52849

Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:45 AM
bzimport added a project: CheckUser.
bzimport set Reference to bz52849.
bzimport added a subscriber: Unknown Object (MLST).
Riley_Huntley renamed this task from Checkuser option "get users" should should point out when user password is changed to Checkuser option "get users" should point out when user password is changed.Feb 18 2020, 5:15 PM
DannyS712 changed the subtype of this task from "Task" to "Feature Request".Oct 16 2020, 9:26 PM
DannyS712 subscribed.

The cu_changes row should not store that the account had a password change unless the temporary password was used or there was a use of Special:ChangePassword.

This is because a password reset can be sent by any user for an account, and unless they have access to the email, this does not allow them to get access to the account. Therefore, when the user uses the temporary password, we can be sure that the person(s) with access to this email either gave out or used this temporary password. At this point (unless 2FA is enabled) they would have access to the account regardless if it's the intended person.

Dreamy_Jazz raised the priority of this task from Low to Medium.Jul 18 2022, 11:00 AM
Dreamy_Jazz updated the task description. (Show Details)
Dreamy_Jazz lowered the priority of this task from Medium to Lowest.EditedAug 29 2022, 1:40 PM

Actually I've misunderstood what this task is about. This is adding to the get users results whether an IP was used to make a password reset, not logging when a user has their password successfully reset

I think this is not something that's going to work. While the get users page needs design improvements, adding that the IP was used to make a password reset on the account is going to add extra information. At minimum for this to work there would need to be some kind of text saying "Made a password reset on this account" and possibly for it to be useful also need to include a timestamp. This adds extra content to a current interface that already is confusing (as evidenced by T69811).

Plus at the moment whether a password reset is actually successful (i.e. the user used the temporary password and then reset the password) is not logged. What is logged currently is whether the temporary password was sent to the user via email. Even if this was instead for when the password reset was actually fully performed what does this information provide that a CheckUser would need to see even if they didn't use get edits. If a CU is looking for compromises they would surely use get edits so that they could see the UA used for the password reset request / the successful login with the temp password.

Also for this to work T145265 needs to be solved.

Dreamy_Jazz closed this task as Declined.EditedAug 29 2022, 1:53 PM
Dreamy_Jazz raised the priority of this task from Lowest to Needs Triage.

Based on the above, I'm declining this ticket. If there is disagreement please first address the concerns:

  • Why is this important enough to be shown in get users over other events and to justify the extra content being shown in the get users results?
  • Why can't get edits with a find in page operation be used, which would also show the specific UA and XFF used for the password reset request / successful password reset?
  • What use case is there where a CU using get users would need to see this information? Finding the same accounts on an IP or IP range doesn't seem as a possible use case here because just that an IP has requested a password reset won't connect two users as anyone can make a password reset email be sent.

This ticket would not be possible to implement until T145265 is solved as without that there is no way to know what cu_change entry is associated with what log like action, so adding that as a subtask.