robchur wrote:

It might be wise to implement this in hooks and then have an extension available
(which we could put live on Wikimedia sites).

neil wrote:

That's an excellent idea. That way, there's minimal impact on MediaWiki, and the
greatest possible choice for end users. Any hook should not only provide the
username as well as the password to be checked, because some people will use
their username as the basis for all or part of their password.

ayg wrote:

*** Bug 9507 has been marked as a duplicate of this bug. ***

ayg wrote:

Particular suggestion (from bug 9507): ban passwords that are the same as the user's login.

Have implemented the password-same-name check in r21640. More general changes
may still remain to do... There is a hook in User::isValidPassword(), but note
that it doesn't currently pass other user information (name, email etc) which
might be desired by a strength checker.

ayg wrote:

*** Bug 9834 has been marked as a duplicate of this bug. ***

Extension:PasswordStrength committed in 36573.

^demon said

rd232 wrote:

Extension:PasswordStrength does not appear to exist. Reopened per en.wp discussion at https://secure.wikimedia.org/wikipedia/en/wiki/Wikipedia:Village_pump_%28proposals%29/Account_security#Improve_password_strength

bugs wrote:

It looks like PasswordStrength was deleted in r47762 per bug 17604. [[mw:Extension:SecurePasswords]] looks like a newer extension that accomplishes many of the same things.

rd232 wrote:

OK - I see now in its description "as well as a password strength checker", but there is zero documentation of this that I can find.

tomashnyk wrote:

If this is implemented, it should be make sure the requirements for the password are shown when opening a new account (there is nothing more frustrating then typing a 4-character password and being told it must be longer, then typing in 6-characer password and being told the same, finally typing an 8-character long password and being told it must have at least one number and so on). I think it should be shown when loging in as well - often people have different password strengths and do nto remember which one is used on a given site.

(In reply to comment #12)

If this is implemented, it should be make sure the requirements for the
password are shown when opening a new account (there is nothing more
frustrating then typing a 4-character password and being told it must be
longer, then typing in 6-characer password and being told the same, finally
typing an 8-character long password and being told it must have at least one
number and so on). I think it should be shown when loging in as well - often
people have different password strengths and do nto remember which one is used
on a given site.

Agreed

Will adding a test for:
*Password too short! ( < 8)
*Password too long! ( > 20 )
*Password must include at least one number! ( !preg_match("#[0-9]+#", $pwd )
*Password must include at least one letter! ( !preg_match("#[a-z]+#", $pwd )
*Password must include at least one CAPS! ( !preg_match("#[A-Z]+#", $pwd )
*Password must include at least one symbol ( !preg_match("#\W+#", $pwd )

suffice ?

Due to community feedback, and consensus, I think only
*Password too short! ( < 8) is required

(In reply to Tony Thomas from comment #15)

Due to community feedback, and consensus

Links welcome, for transparency.

Links welcome, for transparency.
Andre, that was from #wikimedia-dev, I can attach the chat logs, if necessary.

The includes/DefaultSettings.php sets
$wgMinimalPasswordLength = 1;

This can be edited to a minimum level, say 8. And the minimum requirement message needs to come up near to the Password column.

Change 120025 had a related patch set uploaded by 01tonythomas:
Minimum password length for new account set to 8

https://gerrit.wikimedia.org/r/120025

Change 120025 abandoned by 01tonythomas:
Minimum password length for new account set to 8

https://gerrit.wikimedia.org/r/120025

I appreciate when websites show me an evaluation of the password I just entered.

In T5348#76515, @brion wrote:

There is a hook in User::isValidPassword(), but note that it doesn't currently pass other user information (name, email etc) which might be desired by a strength checker.

AuthManager (T91699) will allow any class implementing the AuthorizationProvider interface to subscribe to account creation events, receive the full authentication data, and veto the event. It will also provide an API to learn whether a set of authentication data is acceptable, without actually trying to create the account.

Let's try to avoid this scenario ? :)

Password policies have been implemented since https://gerrit.wikimedia.org/r/#/c/206156/, and can vary by group. The User object is passed to the policy checking function.

We currently implement checks for,

• Minimum password length
• Maximum password length
• Cannot match username
• Cannot be included in a list of popular passwords (the list currently has the 25k most popular passwords from the rockyou breach)

I think the combination of those covers the intent of this bug, and we can close this? Or is there a remaining check that should be run?

Or if this bug is about applying a specific strong policy to all user accounts, then that would need an RFC.

I think this bug can probably be closed since the technical requirements have been fulfilled. However, I still think we should actually apply a specific strong policy to accounts.

Some related tasks: T46788, T18435, T32574, T19544