Page MenuHomePhabricator

Allow user with a certain user right change/reset the passwords of others
Closed, ResolvedPublic

Description

It was suggested that this Special: page could allow a special rights group, such as 'resetpassword', to change passwords for other people. However, directly allowing Stewards (or staff, bureaucrats, whatever, using the word "Stewards" here for convenience) to change passwords directly, is a bit nasty itself.

After some discussion it was further suggested that the form could, when changing the password for another user, simply set user_new_password to a random password (as per "email me a new password") thus allowing the old password to remain active, and letting the usurpation or recovery still work. This also implies a change of the password once logged in, so the steward would not know the ultimate chosen password.

Suggested options would be:

  • Show the user's autoconfirmed state and current email address (useful for password recovery research).
  • Email the new password to a given address OR display it in the window directly (for convenience on manual usurpation).
  • Disable the old password

A mock-up of the possible UI can be seen at: http://test.wikipedia.org/wiki/Image:Newpassform.gif

There is a non-maintained extension doing this, Password Reset.

Notes:

  • If the old password were disabled, but the account set emailconfirmed, the vandal could simply request a new password. This implementation would not be ideal for disabling purely vandalism-based accounts. Mostly this would be for recovery/replace of lost passwords, usurpation of unused accounts, and recovery of hacked accounts.
  • Should disabling the old password destroy it by blanking the hash table entry, or reversably corrupt it such as flipping the MD5 (rot13, string reversal, adding a tilde, etc)?

Version: 1.22.0
Severity: enhancement

Details

Reference
bz15876

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:18 PM
bzimport set Reference to bz15876.
bzimport added a subscriber: Unknown Object (MLST).

herd wrote:

Further discussion on this can be seen at:

Mostly discussed between: brion, Simetrical, Emufarmers and Splarka.

Some of this bug was done in r43841 by Mr.Z-man.

On a side note, current array is:
'Resetpass' => array( 'ResetPass', 'ResetPassword', 'ChangePassword' ),

It would probably be better if it were:
'Resetpass' => array( 'ChangePassword', 'ChangePass', 'ResetPass', 'ResetPassword' ),

Pass is ambiguous. And regular users aren't resetting it, they're changing it.

  • Bug 15859 has been marked as a duplicate of this bug. ***

Added ability to change others' passwords in r47569.

Which was reverted in r48780. Don't know why we never reopened the bug

*blows dust off*

This would be a fun project to fix. The revert in r48780 was nearly complete, just had issues with temporary passwords.

Sincere apologies for bugspam.

I was about to file a new bug called "allow resetting passwords for accounts without email" but then came across this. The mock-up linked above is very close to what I was about to suggest. Has any consideration been given to taking this further since 2011?

No news here so far; somebody would have to pick up the code from r48780 and improve it.

This task needs to be updated to account for subsequent developments. Namely, I believe Special:ChangePassword is now its own Special page, living outside of Special:Preferences, so at least half of this task should be complete. It's difficult to figure out what the remaining work needed here is, so we should narrow the scope of this task or file a new, clearer task, in my opinion.

Tgr renamed this task from Special:ChangePass: move password change form from Preferences, and add reset/usurp features to Allow user with a certain user right change/reset the passwords of others.Sep 2 2015, 9:00 PM
Tgr updated the task description. (Show Details)
Tgr set Security to None.
Tgr subscribed.

Edited to reflect remaining parts of the task. Note that Special:ChangePassword might change drastically with T110280.

Tgr claimed this task.

Users can already send password reset for another user (no special privilege needed; it would be pointless since password reset has to be usable anonymously anyway). The capability for seeing the password reset token that's sent out (ie. actually performing a password reset on behalf of another user) existed in the past, but was deemed a sufficiently bad idea that it got removed (see T150930: Remove capture feature from Special:PasswordReset). Revoking access via a special page is already possible via the DisableAccount extension. So nothing left here.