Wikimedia Bugzilla is closed!

This extension is obsoleted by latest MW so that you don't need it anymore.

When logged in as admin with password reset permissions, and entering the name of a user who forgot their password, it only generates an error message

"There is no e-mail address recorded for user "XXX"."

Maybe it has a bug? Is there any documentation how an admin can reset the password of users without an email address? The present function seems limited to sending the email password reminder, a functionality that existed always. Where is the equivalent of the PasswordReset extension to be found in MW core?

Is there a chance to avoid the conflict by using a different special page name in the new version 1.18? 

Mediawiki core could easily use "Special:PasswordReset" instead.

The conflict seems to be introduced only in this version (at least it was not present in the 1.17alpha/SVN we used previously).

(In reply to comment #3)
> Mediawiki core could easily use "Special:PasswordReset" instead.
Did you mean to say something else here, or do you mean core could take Special:PasswordReset and the extension could switch to a different name?

> > Mediawiki core could easily use "Special:PasswordReset" instead.

thanks emufarmers! I did mean:

"Mediawiki core could easily use "Special:ResetPassword" instead."

This depends on someone confirming that the use of Special:PasswordReset is indeed new in 1.18. I can find the term in neither the release-notes of 1.17 nor 1.18 (per SVN branches/1.1X/phase3). I can only confirm that in r79596 there seemed to be no conflict yet. This is after the 1.17 branch point r77974, which is why I assume that it can still be changed. I think it is bad policy to break a useful, 4-year old extension without a real need.

Note that not only canonical special page names should be different, but also ALL localised names, including aliases. This is troublesome, suggest merging all useful functionality from this extension to core and do away with it.

Big solution: yes, greatly preferred, provided it can be done soon and backported to 1.18.  Can you tackle this?

My propopsal is more guided by pragmatic considerations: We need a solution for the 1.18 deployment in the near future.

With this issue untouched and 1.18 deployment starting: the option that  "Mediawiki core could easily use "Special:ResetPassword" instead." (i.e. using a new special page name rather than overwriting the functionality of the extension) seems to be eliminated?

CCing Happy-melon, since he added PasswordReset to core.  I'm sure this could still be resolved in 1.18 if someone shepherds it through: rename the core page, rename the extension, merge them, whatever.

What does this extension do?

See http://www.mediawiki.org/wiki/Extension:Password_Reset

It allows an admin (with 'passwordreset' permission) to reset the password for another user. It is necessary if users are in an collaboration/organisation context, where accounts are created by an admin and where users have not entered mail adresses. It is not necessary on WMF or self-registering, email-requiring wikis, but is necessary for mediawiki usage in small scale, managed collaborations. It worked fine in 1.17 and beyond (trunk), but naturally broke with the capturing of its SpecialPage name by mediawiki core.

Renaming the SpecialPage in the extension is possible, but would create some confusion in existing installations. Renaming the NEW mediawiki core page to ResetPassword seems to make more sense in the short term. In the longer term, adding all functionality (the user-disabling function of Extension:Password_Reset is actually no longer needed) would be nice, of course. The urgent issue is, however, whether managed wikis can easily upgrade to 1.18 or need to be warned that essential extension functionality will break.

To be honest, this extension a) scares me, and b) provides relatively little functionality that is not already available in core as of 1.18.  

The biggest problem is the complete lack of logging: this system effectively gives people carte blanche to access other users' accounts since they can simply change the password silently and then log in as the user.  Although the user themselves knows that their account has been hijacked because the password has changed, there is no way they can possibly prove that they are *not* in control of the account (can't prove a negative, and all that).  Basic principles of security dictate that it should be very hard if not impossible to justify someone knowing someone else's plaintext password, even administrators of internal wikis.  

Overall, I don't think the remaining functionality of this extension should be put into core, and I'm not particularly enamoured with it as an extension either.  At most, I can fix the name collision by renaming the special page in the extension to ResetUserPassword or somesuch.  But I'd rather delete it altogether unless presented with a justifiable usecase.

I think the functionality should be in core, probably disabled by default. I tried implementing it in the past, but had an issue that I never worked out where if you reset someone else's password, you'd get logged in as them as well ;-)

(In reply to comment #13)
> I tried implementing it in the past, but had an issue that I never worked out
> where if you reset someone else's password, you'd get logged in as them as well
> ;-)

Add it to the list of things we no longer understand about the current login/auth code... :(

(In reply to comment #12)
> The biggest problem is the complete lack of logging: this system effectively
> gives people carte blanche to access other users' accounts since they can
> simply change the password silently and then log in as the user.  Although the
> user themselves knows that their account has been hijacked because the 

You are presenting the use case of a large open community wiki with self-registering and self-managing users, like Wikipedia. This extensions is not installed there, lack of logging is a good reason.

The use case where this extension is needed is mediawiki installations with managed users. Typically users are not creating their accounts themselves, an admin has done it for for them. Often a substantial fraction of users has only limited training for specific tasks, not full understanding of mediawiki special pages. Replacing forgotten passwords is an admin responsibility. While logging would be nice, it is not absolutely required.

> Overall, I don't think the remaining functionality of this extension should be
> put into core, and I'm not particularly enamoured with it as an extension
> either.  At most, I can fix the name collision by renaming the special page in
> the extension to ResetUserPassword or somesuch.  But I'd rather delete it
> altogether unless presented with a justifiable usecase.

If changing the special page name of the extension is the best possible solution, it is better than to break all managed mediawiki installations. There are doubtlessly many extensions outside of the WMF managed SVN repository, and respecting their special page names is not expected. I am not sure, however, why mw core must break a mediawiki.org SVN managed extension without a good reason. If there is a good reason that the core page must be the preoccupied "PasswordReset" instead of the (to my knowledge) available "ResetPassword" then please change the extension special page name.

In the longer term, merging third-party-password-reset-functionality into core, while adding a logging function would be welcome. But here I am only concerned with in-house installations being able to the soon-to-be-released 1.18.

(In reply to comment #15)
> (In reply to comment #12)
> The use case where this extension is needed is mediawiki installations with
> managed users. Typically users are not creating their accounts themselves, an
> admin has done it for for them. Often a substantial fraction of users has only
> limited training for specific tasks, not full understanding of mediawiki
> special pages. Replacing forgotten passwords is an admin responsibility. While
> logging would be nice, it is not absolutely required.

In no circumstances is administrators knowing other users' plaintext passwords a sensible security policy, even on a managed wiki (of which I run several).  I'd be happy to consider implementing either a SwitchUser functionality or a root password, both with proper logging.

> If changing the special page name of the extension is the best possible
> solution, it is better than to break all managed mediawiki installations. There
> are doubtlessly many extensions outside of the WMF managed SVN repository, and
> respecting their special page names is not expected. 

the WMF SVN extensions are not "managed"; no *guarantee* is made by the core developers that they will not break them (that guarrantee is only available for extensions used on the Wikimedia cluster).  We do *try* not to break them, but it is only a best effort.

> I am not sure, however,
> why mw core must break a mediawiki.org SVN managed extension without a good
> reason. If there is a good reason that the core page must be the preoccupied
> "PasswordReset" instead of the (to my knowledge) available "ResetPassword" then
> please change the extension special page name.

ResetPassword is not free because it has for many years been defined as an alias to ChangePassword (which used to be called Resetpass).

"I'd be happy to consider implementing either a SwitchUser functionality or a
root password, both with proper logging."

That would be great, provided this happens before the release of 1.18. Else:

The extension ResetPassword exists for many years and is used. It may not be the best possible solution, but it is the _only available_ solution. To my knowledge and to all participating in this bug discussion, mediawiki core provides no alternative. The present mediawiki core reset password requires an email, but mediawiki has never been built so that you cannot create a user without registering an email.

Please fix the ResetPassword extension, e.g. by renaming the special page, in a way that does not leave admins without a solution after upgrading to 1.18. Add your security warning about best practices if you like, but create a pragmatic solution for 1.18. Whatever the status of the ResetPassword special page previously was, 1.18 alpha presently is the first mediawiki version where you cannot reset the password of a user without an email.

(In reply to comment #17)
> That would be great, provided this happens before the release of 1.18. Else:

I'm certainly happy to develop a solution to this issue, provided that it's the right solution.

> The extension ResetPassword exists for many years and is used. It may not be
> the best possible solution, but it is the _only available_ solution. To my
> knowledge and to all participating in this bug discussion, mediawiki core
> provides no alternative. 

Can you walk us through the usecase for this functionality?  Not what you want the software to provide, but what you want users to be able to achieve?  What scenario begins with Joe Bloggs sitting down at his desk, and ends with James Admin using this extension to change Joe Bloggs' password to 'foobar'?

> The present mediawiki core reset password requires an
> email, but mediawiki has never been built so that you cannot create a user
> without registering an email.

Setting $wgEmailConfirmToEdit = true requires a valid email address to complete the account creation.  I appreciate that that's not a particularly obvious configuration to stumble upon, but the functionality is available (and has been since 1.11 - bug 11629).  
 
> Whatever the status of the ResetPassword special page
> previously was, 1.18 alpha presently is the first mediawiki version where you
> cannot reset the password of a user without an email.

This is, to my mind, the biggest problem.

> Can you walk us through the usecase for this functionality?  Not what you want
> the software to provide, but what you want users to be able to achieve?  What
> scenario begins with Joe Bloggs sitting down at his desk, and ends with James
> Admin using this extension to change Joe Bloggs' password to 'foobar'?

Correct. John has little general software knowledge and collaborates on a mediawiki with specific tasks he has learned to perform. He has no business email in the organisation, and the organisation never had a policy to change the mediawiki default setting of $wgEmailConfirmToEdit. John forgets his password and contacts his software admin by telephone (the admin is sitting in a different building/city/whatever). The admin creates a new one-time-password-token for John, telling him to perform a normal login, and informing him that the password can only be used once and will result in a password-selection screen, where John has to choose a self-selected new password. The admin action is logged.

This scenario would probably honor all admin best practices and could be implemented in core rather than an extension.

(Timing is the only problem in this.)

(In reply to comment #19)
> John forgets his
> password and contacts his software admin by telephone (the admin is sitting in
> a different building/city/whatever). The admin creates a new
> one-time-password-token for John, telling him to perform a normal login, and
> informing him that the password can only be used once and will result in a
> password-selection screen, where John has to choose a self-selected new
> password. The admin action is logged.
> 
> This scenario would probably honor all admin best practices and could be
> implemented in core rather than an extension.

Hehe, you just suggested exactly the workflow that I'd settled on for this!

(In reply to comment #16)
> In no circumstances is administrators knowing other users' plaintext passwords
> a sensible security policy, even on a managed wiki (of which I run several). 
> I'd be happy to consider implementing either a SwitchUser functionality or a
> root password, both with proper logging.

Plenty of organizations have standard passwords for all users. It keeps administration much, much simpler. Site security is important—to a point. Not every MediaWiki installation needs state of the art security and there's really nothing to stop people from creating MediaWiki accounts with the same, simple password.

On-wiki logging would be nice, but it's just as simple for someone to take the plaintext MySQL password from LocalSettings.php and do direct database manipulation. Or run eval.php or a maintenance script. Site admins can already do everything, it's simply a matter of making it slightly safer (on-wiki form versus command line hackery).

Let's be reasonable in the approach taken here and not pretend as though admins knowing passwords or being able to quietly reset them is anything new.

(In reply to comment #21)
> (In reply to comment #16)

> Let's be reasonable in the approach taken here and not pretend as though admins
> knowing passwords or being able to quietly reset them is anything new.

That *sysadmins* have full access to a wiki is certainly indisputable.  There's no reason why the users having access to this functionality need to be sysadmins, that's presumably the whole point of having on-wiki.  There's nothing stopping sysadmins using the changePassword maintenance script, now or in the future, which is deliberately written to provide precisely this functionality.

(In reply to comment #20)
> (In reply to comment #19)
> > John forgets his
> > password and contacts his software admin by telephone (the admin is sitting in
> > a different building/city/whatever). The admin creates a new
> > one-time-password-token for John, telling him to perform a normal login, and
> > informing him that the password can only be used once and will result in a
> > password-selection screen, where John has to choose a self-selected new
> > password. The admin action is logged.
> > 
> > This scenario would probably honor all admin best practices and could be
> > implemented in core rather than an extension.
> 
> Hehe, you just suggested exactly the workflow that I'd settled on for this!

Fixed with (roughly) this method in r98029.

Excellent, thanks!

On second thought, I am actually happy enough with the lack of logging. Forgetting your password and requesting a new one by email is not logged either, and logging publicly exposes forgetfulness. The method employed now prevents admins from learning user passwords: I think this is good practice enough.

I suggest to drop "// @todo: Logging".

(In reply to comment #22)
> (In reply to comment #21)
>> (In reply to comment #16)
> 
>> Let's be reasonable in the approach taken here and not pretend as though admins
>> knowing passwords or being able to quietly reset them is anything new.
> 
> That *sysadmins* have full access to a wiki is certainly indisputable.  There's
> no reason why the users having access to this functionality need to be
> sysadmins, that's presumably the whole point of having on-wiki.  There's
> nothing stopping sysadmins using the changePassword maintenance script, now or
> in the future, which is deliberately written to provide precisely this
> functionality.

Yes, my point is that a false dichotomy should be avoided. There isn't a binary choice between sysadmin-only and on-wiki with full logging and revertability. There never has been.

Historically there was an on-wiki sysadmin/developer user group (which continues on today in global groups). Simply because something can be done via a maintenance script doesn't mean that it should be necessary. Especially something as basic as password resetting, which nearly every other application in the world simply allows admins to do without any kind of logging.

While it may not be appropriate for Wikipedia to have this type of functionality, as its setup is far more complex (among other reasons), I'd venture to say that for most MediaWiki installations, where the sysadmin is the on-wiki bureaucrat/admin, it makes perfect sense.

Anyway, most of this is tangential (or completely off-topic). Thanks for your commit. :-)

(In reply to comment #24)
> Excellent, thanks!
> 
> On second thought, I am actually happy enough with the lack of logging.
> Forgetting your password and requesting a new one by email is not logged
> either, and logging publicly exposes forgetfulness. The method employed now
> prevents admins from learning user passwords: I think this is good practice
> enough.
> 
> I suggest to drop "// @todo: Logging".

(In reply to comment #25)

> Historically there was an on-wiki sysadmin/developer user group (which
> continues on today in global groups). Simply because something can be done via
> a maintenance script doesn't mean that it should be necessary. Especially
> something as basic as password resetting, which nearly every other application
> in the world simply allows admins to do without any kind of logging.

What needs to be logged is not the fact that a password reset was done (which as Gregor says is not logged in general), but the fact that the admin user has made an action which alters *another person's* account.  There is still nothing to stop abuse of this system to hijack accounts, the resetter can still log into the account with the temporary password before the owner does and change the password to their own.  It's against eventualities like *that* that it would benefit from logging.
 
> Anyway, most of this is tangential (or completely off-topic). Thanks for your
> commit. :-)

You're welcome :)