Last modified: 2009-06-09 20:03:50 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 17604 - Delete Extension:Passwordstr
Delete Extension:Passwordstr
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal major with 1 vote (vote)
: ---
Assigned To: Chad H.
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-21 21:51 UTC by Purodha Blissenbach
Modified: 2009-06-09 20:03 UTC (History)
6 users (show)

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


Attachments

Description Purodha Blissenbach 2009-02-21 21:51:00 UTC
The Extension:Passwordstr purposely weakens user password
strengths by excluding many possible passwords from the
choices, users can make. By its regexp rules, many of which
can easily be determined automatically, brute force password
cracking automats can spare some tests and thus find passwords
faster.

We should recommend not using this kind of pseudo-wannabe-security.
Better delete the extension altogether.
Comment 1 Niklas Laxström 2009-02-23 10:11:49 UTC
Nobody is forced to use it.
Comment 2 Chad H. 2009-02-23 17:50:09 UTC
I don't see how this reduces password security. Knowing how many digits must be in a password doesn't tell you how many are in one, nor does it tell you how many the average person uses. Same for upper/lowercased numbers. Not to mention: a regex block just blocks a certain format, it doesn't tell you what the password *should* be. 

Suggestions on how to improve it are welcome, but a blanket "its bad and take it away" isn't helpful. A very good use case would be internal wikis (of which there are many). A company might want their users to use strong passwords, but in reality the chances of someone trying to brute force MediaWiki passwords on an internal network is low.

(Switching to extensions because this isn't in core)
Comment 3 Niklas Laxström 2009-02-23 18:05:21 UTC
Unrelated to this bug, but the problem I see in this extension is that it can be used to force to have ascii characters in passwords, which might not be nice for languages using other scripts.
Comment 4 Purodha Blissenbach 2009-02-24 19:42:37 UTC
@demon: I won't explain why reducing the number of possible choices reduces password security. Read basic texts on the subject matter.

The only potentially productive thing towards more security that this extension could do was enforcing a minimum password length.

Forcing specific sets of symbls into passwords (digits, ASCII, interpunctuation, lowercase, uppercase, etc.) reduces passwort security in general. If this extension is not deleted, the we MUST clearly caution potential users not to use such counterproductive kinds of rules, unless they really WANT to weaken statistic security.
Comment 5 Chad H. 2009-02-24 19:52:51 UTC
Fair enough. I'll nuke it this afternoon.
Comment 6 Chad H. 2009-02-24 20:19:04 UTC
Gone as of r47762.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-24 20:33:01 UTC
(In reply to comment #4)
> @demon: I won't explain why reducing the number of possible choices reduces
> password security. Read basic texts on the subject matter.

It doesn't materially reduce the number of possible choices.  The number of possible choices in any event is roughly 2^x, where x is the max POST size in bits.  Typically x will be on the order of at least 10,000,000, and even banning all Unicode characters will not reduce this a whole lot.

I think this kind of extension is really annoying, and a much better implementation would be to rely more on dictionaries and length.  carnivorousstegasauroid is a lot more secure than Password1234, but the former would probably be banned by many simplistic password strength checkers when the latter would not.  But it prevents people from using passwords like "password" and so is almost certainly an increase in security -- I think the reason for deletion is bogus.

If the extension encourages banning non-ASCII characters, this should be fixed.  It can be done without deleting the whole extension.
Comment 8 Platonides 2009-02-24 21:35:59 UTC
(In reply to comment #3)
> Unrelated to this bug, but the problem I see in this extension is that it can
> be used to force to have ascii characters in passwords, which might not be nice
> for languages using other scripts.

The solution would be to replace /[0-9]/, /[A-Z]/ and  /[a-z]/ regex with \p{N}, \p{Ll} and \p{N}


(In reply to comment #7)
> I think this kind of extension is really annoying, and a much better
> implementation would be to rely more on dictionaries and length. 
> carnivorousstegasauroid is a lot more secure than Password1234, but the former
> would probably be banned by many simplistic password strength checkers when the
> latter would not.

Completely agree.

Perhaps instead of measuring that it contains many characters we should measure the number of possibilities on that subset
So the first one would have 23*26 = 588 points of password strength (23 lower case letters) and the second one 
12*(2*26+10) = 744 password strength points (12 uppercase, lowercase and numers).

That could them refined. The second one could instead be considered as 8 letters followed by 4 numbers: 8*2*26 + 4*10 = 456

The difficulties arise in determining how large is the "letters" block for non-western languages. But even if only detecting 
weak passwords on latin1, it could prove useful.

Another option would be using that system as a javascript password strengh measurer.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-24 21:45:30 UTC
(In reply to comment #8)
> Completely agree.
> 
> Perhaps instead of measuring that it contains many characters we should measure
> the number of possibilities on that subset
> So the first one would have 23*26 = 588 points of password strength (23 lower
> case letters) and the second one 
> 12*(2*26+10) = 744 password strength points (12 uppercase, lowercase and
> numers).
> 
> That could them refined. The second one could instead be considered as 8
> letters followed by 4 numbers: 8*2*26 + 4*10 = 456

One way I've seen it done is to say something like "Minimum length 12 characters.  -1 if it contains [a-z], -1 if it contains [A-Z], -1 if it contains [0-9], -1 if it contains other printable ASCII, -2 if it contains non-ASCII", with all the minuses stacking.  Then you could use a six-character password, as long as it was something like aAa1!א.  This particular heuristic still discriminates against non-English languages (Chinese people need to have entire sentences as passwords?!), but it could be refined.
Comment 10 Siebrand Mazeland 2009-04-16 23:45:53 UTC
So what is the use of having this issue reopened? It is now a feature request to have a password strength extension, or just some discussion? Please deal with it appropriately.
Comment 11 Chad H. 2009-06-09 19:19:50 UTC
No reason to keep it open. If someone else wants to implement such a system, they're more than welcome. PasswordStrength has been deleted and I'm not planning to resurrect it.

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


Navigation
Links