Last modified: 2013-05-09 13:30:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17876, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15876 - Special:ChangePass: move password change form from Preferences, and add reset/usurp features
Special:ChangePass: move password change form from Preferences, and add reset...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.22.0
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 15859 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-07 02:23 UTC by Splarka
Modified: 2013-05-09 13:30 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Splarka 2008-10-07 02:23:41 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)?
Comment 1 Splarka 2008-10-07 02:33:12 UTC
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.
Comment 2 MZMcBride 2008-11-24 05:27:17 UTC
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.
Comment 3 Chad H. 2009-02-20 18:30:08 UTC
*** Bug 15859 has been marked as a duplicate of this bug. ***
Comment 4 Chad H. 2009-02-20 18:36:57 UTC
Added ability to change others' passwords in r47569.
Comment 5 Chad H. 2010-01-14 01:15:02 UTC
Which was reverted in r48780. Don't know why we never reopened the bug
Comment 6 Chad H. 2011-01-31 17:34:55 UTC
*blows dust off*

This would be a fun project to fix. The revert in r48780 was nearly complete, just had issues with temporary passwords.
Comment 7 Scott Martin (http://enwp.org/user:scott) 2013-05-08 16:00:16 UTC
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?
Comment 8 Andre Klapper 2013-05-09 13:30:04 UTC
No news here so far; somebody would have to pick up the code from r48780 and improve it.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links