Change Details

**Author:** `herd` **Description:** 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)? -------------------------- **Version**: 1.22.0 **Severity**: enhancement

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, [[ https://www.mediawiki.org/wiki/Extension:Password_Reset | 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

**Author:** `herd` **Description:** 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 alsoIt 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 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=15859There is a non-maintained extension doing this, [[ https://www.mediawiki.org/wiki/Extension:Password_Reset | 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