Last modified: 2013-05-09 13:30:04 UTC
Per IRC: <brion> sticking a password change randomly in the preferences form is really nasty <brion> let's make it a separate form, and link to it from prefs Names could include: Special:ChangePassword Special:ChangePass etc. It would behave probably the same as on the Preferences form for changing your own password. It was also 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 Possibly related bugs this may fix: https://bugzilla.wikimedia.org/show_bug.cgi?id=6761 https://bugzilla.wikimedia.org/show_bug.cgi?id=13177 https://bugzilla.wikimedia.org/show_bug.cgi?id=15859 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)?
Further discussion on this can be seen at: * http://toolserver.org/~amidaniel/chanlogs/%23mediawiki/20081006.txt starting at approx [23:42:19] * http://toolserver.org/~amidaniel/chanlogs/%23mediawiki/20081007.txt ending at approx [01:42:00] 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.