Last modified: 2011-05-15 10:05:13 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 T22473, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20473 - Setting to disable password reset by email
Setting to disable password reset by email
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Email (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-02 12:49 UTC by Luciana Moreira
Modified: 2011-05-15 10:05 UTC (History)
4 users (show)

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


Attachments

Description Luciana Moreira 2009-09-02 12:49:04 UTC
We would like to disable the email password reminder due to security reasons. Nevertheless the other e-mail notifications are very interesting and we would like to keep them all.

Basically we would like to have the following function split into the different function parameters it enables
* $wgEnableEmail - Set to true to enable the e-mail basic features: Password reminders, etc.

Or simply have parameters to individually disable them. Apparently it is possible to do this for some of the functions but not for the password reminder:
* $wgEmailAuthentication - Whether Email authentication (confirmation) is needed for that wiki for using any Email function (except password reminder which works independently from this setting)
* $wgEnableUserEmail - Set to true to enable user-to-user e-mail.

I only found one related issue discussed in the following link but no solution for disabling password reminder e-mails:
http://www.mediawiki.org/wiki/Extension_talk:Password_Reset

Thank you and best regards,
Luciana Moreira
Comment 1 Ralf Hauser 2009-09-02 13:02:04 UTC
Suggestions

1) "rename the button" from "E-mail password" to "E-mail new random password" or alike to prevent users from thinking that the password sent is their real one...
2) this change mechanism lets anybody hijack an account if they can intercept plaintext eMail, so
   a) suggest to contact administrator *adminName*
   b) allow to upload gpg-pub-key/x509 certificate before you forgot your password and have the temp password sent with that encrypted key
Comment 2 Platonides 2009-09-02 14:35:53 UTC
1) is a good idea. 2b) is quite cool, although if the user had a certificate, you could directly allow login into the account using that certificate.
I'm not sure what do you mean with 2a.

Luciana, you can change MediaWiki:passwordremindertext removing $3 (the new password) from the message. They could still receive a "password email" saying "A new password fpr $2 has been requested from ip $1, but password reminders are disabled for this wiki".
You should also change messages like MediaWiki:passwordsent accordingly, to not say you have sent a password you haven't in fact sent.
Comment 3 Ralf Hauser 2009-09-02 14:56:59 UTC
with 2a) I mean that one could perhaps provide a phone number/eMail address of the super-user who may assist you in chaning your password if you forgot.

Sure, this is not scalable, but wiki's are often used in smaller settings where this is feasible and a lot securer than sending a temp pw
Comment 4 Luciana Moreira 2009-09-02 15:07:37 UTC
Platonides, thank you very much for your reply. I already corrected the texts in our server.

Nevertheless, I noticed that these pages are editable by anyone that has an account that is able to edit pages (in our case sysop).

For sure this is a great security improvement as only a smaller group of users can change our configuration. But ideally this page would only be editable by Bureaucrats just like the Special:Userrights

I know that per page access restriction is not the idea behind wikis, but is it possible to restrict the access to this page nonetheless?
Comment 5 Ralf Hauser 2009-09-02 15:14:36 UTC
re comment 4: ... and at least history cannot as easily be altered on who edited that page - thus at least one could find out whose account was broken in first ;)

BTW is there a log in which one could see
3) which logins used the temp password to login when? 
4) from which remote-ip/user-agent that temp password request was issued 
... just some forensics ...
Comment 6 Platonides 2009-09-02 15:54:22 UTC
> Nevertheless, I noticed that these pages are editable by anyone that has an
> account that is able to edit pages (in our case sysop).

No. Pages in the MediaWiki namespace are protected, so only users with the 
editinterface right can edit it. sysop has that right by default, that's why 
you were able to edit it.

> For sure this is a great security improvement as only a smaller group of users
> can change our configuration. But ideally this page would only be editable by
> Bureaucrats just like the Special:Userrights

Add to localsettings.php
$wgGroupPermissions['sysop']['editinterface']    = false;
$wgGroupPermissions['bureaucrat']['editinterface']    = true;
Comment 7 Luciana Moreira 2009-09-03 07:18:29 UTC
Hi Platonides,

Once again thank you for your reply. I have configured our wiki accordingly and it is working as expected :)

My suggestion is to maybe put some pointers to this solution in the wiki manual where I first looked for the configuration: [http://www.mediawiki.org/wiki/Manual:Configuration_settings Manual:Configuration_settings] . This will probably prevent people from asking the same question to you in the future.

In addition I believe the ideas from Ralf would make nice enhancements.

Best regards,
Luciana

Comment 8 Brion Vibber 2009-09-14 16:42:08 UTC
Clarifying summary.
Comment 9 Andrew Garrett 2009-09-14 17:11:29 UTC
I've also been asked about the possibility of a per-user preference for users who think they can manage their own passwords.
Comment 10 Happy-melon 2011-04-20 15:28:52 UTC
Fixed in r86482.

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


Navigation
Links