titoxd.wikimedia wrote:

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.

Created attachment 5308
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.

Attached:

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.

ayg wrote:

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).

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)

happy.melon.wiki wrote:

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.

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.