Last modified: 2014-08-14 07:35:51 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 44788 - Allow different password requirements by group
Allow different password requirements by group
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
SecurePasswords (Other open bugs)
master
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 9816
  Show dependency treegraph
 
Reported: 2013-02-08 07:41 UTC by Matthew Flaschen
Modified: 2014-08-14 07:35 UTC (History)
13 users (show)

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


Attachments

Description Matthew Flaschen 2013-02-08 07:41:12 UTC
I am suggesting this primarily for Extension:SecurePasswords (which is not listed as a component).  However, it could conceivably be implemented in core (at least the length part), or another extension.

Allow setting different requirements for different user groups (admin/sysop, buearuacrat, steward, etc.).  This allows making the requirements for users with elevated rights more stringent than for just editors.

This was discussed in the now-closed bug 16435.
Comment 1 Dario Taraborelli 2013-02-08 18:06:28 UTC
So when being granted specific privs/group membership, users will be required to change their password to match the required strength level before they can effectively use any of their new privileges?
Comment 2 MZMcBride 2013-02-08 18:21:57 UTC
(In reply to comment #1)
> So when being granted specific privs/group membership, users will be required
> to change their password to match the required strength level before they can
> effectively use any of their new privileges?

I imagine the password requirement(s) would be effective on the next log in, not prior to the new privileges being effective.
Comment 3 Matthew Flaschen 2013-02-08 18:51:14 UTC
Yeah, I think MZM's suggestion is simpler (less code to hook in everywhere).

Either:

1. Make them change it immediately after login before doing anything.
2. Block login entirely if it's a bad password, which would effectively require the password change before the group change (which the community/bureaucrat would need to clearly communicate).  If they didn't handle this ahead of time, it would require a reset.
Comment 4 Tyler Romeo 2013-02-11 22:17:29 UTC
I'm hesitant about putting such a feature into Extension:SecurePasswords, primarily because I would never in my life advocate the deployment of this extension onto WMF wikis.

Sure the idea of better password requirements is nice, but look at the rest of the extension. It uses what is quite possibly (no offense to the author) the most unnecessarily complicated password hashing scheme I have ever seen. And I'll explain why step-by-step:

* Using a different hash based on the user ID - all this does is require an attacker to change hashes for each user. It has the same security implication as a salt. In any realistic offline attack, changing hash algorithms would be trivial, especially since the algorithm to calculate which hash to use is public and uses non-secret information.
* Using three different password secret keys - if the attacker gains access to the wiki configuration, they'll have access to all three keys. More keys does not make things better.
* Compressing the password hash - The hash is mostly random, so this would have no effect at the expense of reducing performance and requiring a new PHP extension dependency.
* Using mcrypt to encrypt the password hash - A better solution would be to just HMAC the password hash with the secret keys....but it already does that. Encrypted or unencrypted, an attacker needs access to the secret keys to even begin brute forcing a hash, so encrypting it with a third key that the attacker already has access to is useless.

And the most important lesson out of all of this is that it completely replaces the current password hashing method without any method for replacing it should a better hashing scheme come along (and it already has).

I would either make a new extension specifically for password strength or wait for Daniel's password hashing API to be merged and then for this extension to be changed to use that API.
Comment 5 Daniel Friesen 2013-02-11 22:42:49 UTC
(In reply to comment #4)
> I would either make a new extension specifically for password strength or
> wait
> for Daniel's password hashing API to be merged and then for this extension to
> be changed to use that API.

The new password system has nothing to do with the front end of passwords (except for adding a new error message to distinguish "The password you entered is invalid" from "The hash attached to this user is corrupt.

Changing the way password strength requirements work can be done without waiting for the password hashing system. The conditionals don't belong inside the classes handling storage format. There should be no conflicts implementing password restrictions in the proper places.
Comment 6 Tyler Romeo 2013-02-11 22:54:49 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I would either make a new extension specifically for password strength or
> > wait
> > for Daniel's password hashing API to be merged and then for this extension to
> > be changed to use that API.
> 
> The new password system has nothing to do with the front end of passwords
> (except for adding a new error message to distinguish "The password you
> entered
> is invalid" from "The hash attached to this user is corrupt.
> 
> Changing the way password strength requirements work can be done without
> waiting for the password hashing system. The conditionals don't belong inside
> the classes handling storage format. There should be no conflicts
> implementing
> password restrictions in the proper places.

I agree completely. That's why I was saying not to use this extension, because it mixes both front end and back end, and if deployed, would make using the new back end system impossible since it returns false on a hook.

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


Navigation
Links