Last modified: 2011-04-24 22:50:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8460 - Security question for password reminder emails
Security question for password reminder emails
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: 9816
  Show dependency treegraph
Reported: 2007-01-02 12:09 UTC by Todd Lucas
Modified: 2011-04-24 22:50 UTC (History)
4 users (show)

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

Proposed course of action (diff) - Still needs changes to User preferences and possibly user signup. (7.71 KB, patch)
2008-09-09 03:06 UTC, Tyler Romeo

Description Todd Lucas 2007-01-02 12:09:46 UTC
I am getting several new passwords generated per week lately. One of the reasons
this is happening is that it is too easy for someone to wantonly click on the
link to send a new password (from the login page). It forces me to login to
change my password so that these secondary passwords are not available to
would-be crackers.

If a so-called security question were put in place (e.g., "what is your mother's
maiden name?", or "what is your favorite pet's name?"), this would virtually
eliminate spurious password changes.

My only alternative now is to remove my email, but that precludes administrative
emails and it precludes me being able to authenticate that I am the owner of my
account. I discussed this at the Village Pump and they suggested that I post
this as a wish-list feature. Thanks.
Comment 1 Titoxd 2007-05-15 08:24:58 UTC
This could be done by adding a "user_question"/"user_answer" tinyblob field pair
to the user table. If a user has emailconfirmed privileges, he or she can fill
out a "secret question" field in [[Special:Preferences]], which would change the
behavior of the "request by email" button.

If the user has filled out a value in the user_question field, then the email
confirmation function would show the secret question and ask for a secret
answer. If the answer is correct (perhaps case insensitive, I haven't thought of
this), then the user is sent an email. If it is not, then the user is shown the
form again to resend it. If the user later decides he doesn't want this
protection, he can blank the question/answer fields and the sendemail function
would go back to its current behavior.

This sort of thing would go hand in hand with the "nasty reaction" bugs, such as
bug 9838, and bug 9836. 
Comment 2 Tyler Romeo 2008-09-09 03:06:14 UTC
Created attachment 5308 [details]
Proposed course of action (diff) - Still needs changes to User preferences and possibly user signup.

Includes alterations to LoginForm, User, and new UserPasswordEmailTemplate classes. One thing I was unsure about was whether or not the answer to the secret question should be encrypted in the database. I used a simply md5 for now, but I would like some feedback as to what to do concerning this topic.

This patch still needs to include alterations to the PreferencesForm class, etc.
Comment 3 Platonides 2009-02-13 12:39:03 UTC
Security questions add yet another thing users need to fill and remember.
There're captchas and throttles in place now, so this shouldn't be a big problem.

Also, you shouldn't need to login to disable those secondary passwords. The second 
request disable the first provided secondary password. So there can be only two valid 
passwords at a given time, with the secondary expiring after $wgNewPasswordExpiry 
(by default, a week).

Those would-be crackers have a hard time to guess the generated passwords.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-13 14:14:51 UTC
Why is this FIXED?  Was a patch committed?

If users are abusing the password reminder feature, I would suggest you a) ask sysops to block those IP addresses from e-mailing (that's possible, right?), or b) configure your e-mail client to archive/ignore password reminder e-mails (then you can reconfigure it when you actually want to receive one).
Comment 5 Platonides 2011-04-24 21:57:27 UTC
It was marked as fixed because after 2007 we added features which are much better than the proposed "security question" solution.
Happy Melon, can you provide you reasoning for still needing a security question?
(this should probably be cloned to a new bug, though)
Comment 6 Happy-melon 2011-04-24 22:25:36 UTC
It shouldn't be FIXED since the exact feature requested was implemented, which it wasn't.  If the other features are adequate for addressing the source of the bug, then this specific feature can happily be WONTFIXed; IMO it probably should anyway, for the reason you give in comment 3: that it's awkward and an undesirable extra bit of information.
Comment 7 MZMcBride 2011-04-24 22:50:32 UTC
Marking this as "wontfix". This feature comes with more cost than benefit.

A "wontfix" in this case isn't to say that this feature couldn't be implemented in an extension, but I don't see any reason to put this type of thing in core. The initial problem seems to be adequately addressed by other features (as noted), so there's no real reason to keep this bug open.

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