Last modified: 2011-04-24 22:50:32 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.
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 [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.
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.
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)
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.
