[Wikitech-l] Language Engineering IRC Office Hour on February 12, 2014 (Wednesday) at 1700 UTC
[x-posted] Hello, The Wikimedia Language Engineering team will be hosting the monthly IRC office hour on February 12, 2014 (Wednesday) at 1700 UTC/ 0900 PDT on #wikimedia-office. This time we would be talking about the recent changes made to the Universal Language Selector (ULS) - the MediaWiki extension that provides unified language configuration[1] - and the impact on the Wikimedia wikis. We look forward to addressing any questions you may have about this. Please see below for the event details. Questions can also be sent to me before the event. See you all at the IRC office hour! Thanks Runa [1] https://www.mediawiki.org/wiki/Universal_Language_Selector Event Details: == # Date: February 12, 2014 # Time: 1700-1800 UTC, 0900-1000 PDT ( http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140212T1700) # IRC channel: #wikimedia-office on irc.freenode.net Agenda: == 1. Universal Language Selector (ULS) update and developments 2. Q A -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Password Hash
Am 05.02.2014 23:03, schrieb Brion Vibber:
Is the 72-byte truncation a general bcrypt problem or specific to
password_hash()? Any concerns or a non-issue? Note that some non-Latin
strings can only fit 24 chars in 72 bytes of UTF-8. Long enough for most
passwords, but some people like passphrases. :)
-- brion
http://security.stackexchange.com/a/39852 recommends to sha256 before
password_hash, but better ask Bruce Schneier:
Yes, BCrypt has an upper limit of 72 characters. It's a limitation by
the Blowfish cipher itself. One way to work around it is by using
SHA-256 first and then BCrypt the result. In your case it would be
something like
hashpw(sha256('pass'), salt)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Password Hash
Where we are at it: This en-wiki article [2] - https://en.wikipedia.org/wiki/Bcrypt currently lacks the important information of the password limitation. Should be added by someone who's an expert in that field. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
On Wed, Feb 5, 2014 at 8:00 PM, MZMcBride z...@mzmcbride.com wrote: Hi. Tyler Romeo wrote: On Wed, Feb 5, 2014 at 2:20 AM, MZMcBride z...@mzmcbride.com wrote: Ultimately, account security is a user's prerogative. [...] Banks and even e-mail providers have reason to implement stricter authentication requirements. This is conflicting logic. If it is the user's job to enforce their own account security, what reason would banks or email providers have to require long passwords? I'm not sure the logic is conflicting. I tried to separate individual thoughts into individual paragraphs. The common thread of my message was that I haven't yet seen enough evidence that the cost here is worth the benefit. The benefits to securing valueless accounts remains unclear, while the implementation cost is non-negligible. E-mail accounts are often used in identity verification processes and banks are banks. While you and I may disagree with their password policies, there's at least a reasonable explanation for implementing more stringent requirements in these two cases. Compare with MediaWiki user accounts. What's the argument here? Why is this worth any effort? I think there are a couple of reasons why we have a duty to enforce strong passwords. Let me try to convince you. 1) As I understand it, the reason we went from 0 to 1 character required is spammers were actively trying to find accounts with no password so they could edit with an autoconfirmed account. We rely on number of combinations of minimum passwords to be greater than number of tries before an IP must also solve captcha to login to mitigate some of this, but I think there are straightforward ways for a spammer to get accounts with our current setup. And I think increasing the minimum password length is one component. 2) We do have a duty to protect our user's accounts with a reasonable amount of effort/cost proportional to the weight we put on those identities. I think we would be in a very difficult spot if the foundation tried to take legal action against someone for the actions they took with their user account, and the user said, That wasn't me, my account probably got hacked. And it's not my fault, because I did the minimum you asked me. So I think we at least want to be roughly in line with industry standard, or have a calculated tradeoff against that, which is roughly 6-8 character passwords with no complexity requirements. I personally think the foundation and community _does_ put quite a lot of weight into user's identities (most disputes and voting processes that I've seen have some component that assume edits by an account were done by a single person), so I think we do have a responsibility to set the bar at a level appropriate to that, assuming that all users will do the minimum that we ask. Whether it's 4 or 6 characters for us I think is debatable, but I think 1 is not reasonable. I personally regularly use single-character passwords on test MediaWiki wikis (and other sites) because, as a user, it's my right to determine what value to place in a particular account. If one day MediaWiki wikis (or Wikimedia wikis, really) allow per-user e-mail (i.e., mzmcbr...@wikipedia.org) or if there comes a time when identity verification becomes part of the discussion (compare with Twitter's blue checkmark verified account practice), then it may make sense to require (l|str)onger passwords in those specific cases. Even today, if you want to make Jimmy or members of the Wikimedia Foundation staff have crazy-long passwords, that may be reasonable or prudent or what-have-you, but that doesn't mean MediaWiki core should go along. If somebody guesses a user's password and empties their bank account, the bank could care less, since it is the customer's fault for not making sure their password is long enough. I'm not sure this is true, but it's too off-topic to discuss here. A thread about global banking laws and practices, particularly with regard to liability and insurance and criminal activity, would certainly be interesting to read, though. :-) I'm sure a very heavy Wikipedia editor, who uses his/her account to make hundreds of edits a month but isn't necessarily an administrator or other higher-level user, sees their account as something more than a throwaway that can be replaced in an instant. I absolutely agree with you on this point. And I think we can encourage stronger passwords, even on the login form if you'd like. Rather than only using user groups, we could also use edit count or edit registration date or any number of other metrics. The catch, of course, is (a) finding developer consensus on a reasonable implementation of a password strength meter and (b) finding local community consensus to make changes on a per-variable basis. For example, MZMcBride, what if your password is wiki, and somebody compromises your account, and changes your password and email. You don't have a
[Wikitech-l] English Wikipedia Issues
Hey all, Not sure if anyone else noticed or not yet, but at least the English Wikipedia appears to be having some intermittent issues. Request: GET http://en.wikipedia.org/wiki/Super_Bowl_XXVII, from 10.64.32.105 via cp1052 cp1052 ([10.64.32.104]:3128), Varnish XID 4288339681 Forwarded for: 162.17.205.153, 208.80.154.76, 10.64.32.105 Error: 503, Service Unavailable at Thu, 06 Feb 2014 16:40:23 GMT (Missed the Super Bowl and attempting to figure out what all the big talk about it is about, apparently it was a slaughter?) Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] English Wikipedia Issues
On Thu, 2014-02-06 at 11:41 -0500, Derric Atzrott wrote: Not sure if anyone else noticed or not yet, but at least the English Wikipedia appears to be having some intermittent issues. This is being worked on currently on IRC in #wikimedia-operations currently, plus was reported to https://bugzilla.wikimedia.org/show_bug.cgi?id=60970 andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] English Wikipedia Issues
On Thu, Feb 6, 2014 at 8:41 AM, Derric Atzrott datzr...@alizeepathology.com wrote: Hey all, Not sure if anyone else noticed or not yet, but at least the English Wikipedia appears to be having some intermittent issues. Request: GET http://en.wikipedia.org/wiki/Super_Bowl_XXVII, from 10.64.32.105 via cp1052 cp1052 ([10.64.32.104]:3128), Varnish XID 4288339681 Forwarded for: 162.17.205.153, 208.80.154.76, 10.64.32.105 Error: 503, Service Unavailable at Thu, 06 Feb 2014 16:40:23 GMT Yes, something seems to be happening intermittently at the moment (coming back up as I speak?) All the right people are on IRC right now trying to diagnose. Definitely not down for everyone or everything. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] English Wikipedia Issues
On Feb 6, 2014 11:48 AM, Andre Klapper aklap...@wikimedia.org wrote: On Thu, 2014-02-06 at 11:41 -0500, Derric Atzrott wrote: Not sure if anyone else noticed or not yet, but at least the English Wikipedia appears to be having some intermittent issues. This is being worked on currently on IRC in #wikimedia-operations currently, plus was reported to https://bugzilla.wikimedia.org/show_bug.cgi?id=60970 A couple more links: * https://wikitech.wikimedia.org/wiki/SAL * http://gdash.wikimedia.org/dashboards/reqerror/ -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
On Thu, Feb 6, 2014 at 9:58 AM, Chris Steipp cste...@wikimedia.org wrote: 1) As I understand it, the reason we went from 0 to 1 character required is spammers were actively trying to find accounts with no password so they could edit with an autoconfirmed account. We rely on number of combinations of minimum passwords to be greater than number of tries before an IP must also solve captcha to login to mitigate some of this, but I think there are straightforward ways for a spammer to get accounts with our current setup. And I think increasing the minimum password length is one component. 2) We do have a duty to protect our user's accounts with a reasonable amount of effort/cost proportional to the weight we put on those identities. I think we would be in a very difficult spot if the foundation tried to take legal action against someone for the actions they took with their user account, and the user said, That wasn't me, my account probably got hacked. And it's not my fault, because I did the minimum you asked me. So I think we at least want to be roughly in line with industry standard, or have a calculated tradeoff against that, which is roughly 6-8 character passwords with no complexity requirements. I personally think the foundation and community _does_ put quite a lot of weight into user's identities (most disputes and voting processes that I've seen have some component that assume edits by an account were done by a single person), so I think we do have a responsibility to set the bar at a level appropriate to that, assuming that all users will do the minimum that we ask. Whether it's 4 or 6 characters for us I think is debatable, but I think 1 is not reasonable. 1) Merely increasing the length could increase required keystrokes without making it more secure. A couple comments from the meetinghttps://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-05#Full_log : brion ain't secure TimStarling password isn't secure either, and that's 8 It seems to me that a pretty secure approach would be to have the system give the user his 8-12 character password, rather than letting him pick a password. Then we can be assured that he's not doing stuff like p@ssword to meet the complexity requirements. 2) How plausible is this scenario you mention, involving legal action? Has/would the WMF ever take/taken legal action against someone for actions taken with their user account? Why would that happen, when any damage done by a non-checkuser can generally be reverted/deleted/etc.? What would be the remedy; trying to get money out of the person? It probably wouldn't amount to much. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] TitleValue
I agree that this mailing list is a reasonable place to discuss the interfaces. Notes from the Architecture Summit are now up at https://www.mediawiki.org/wiki/Architecture_Summit_2014/TitleValue# . At yesterday's RFC review we agreed that we'd like to hold another one next week (will figure out a good date/time with Nik, Daniel, and the architects) and discuss TitleValue, see if there's anything that needs moving forward. Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
brion ain't secure TimStarling password isn't secure either, and that's 8 It seems to me that a pretty secure approach would be to have the system give the user his 8-12 character password, rather than letting him pick a password. Then we can be assured that he's not doing stuff like p@ssword to meet the complexity requirements. Well if we are going to go down that road, requring public/private key pairs would also be more secure. However i doubt either would be acceptable to users. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
On Thu, Feb 6, 2014 at 3:26 PM, Brian Wolff bawo...@gmail.com wrote: Well if we are going to go down that road, requring public/private key pairs would also be more secure. However i doubt either would be acceptable to users. Actually, I think it might be better if we just have people come on down to the San Francisco office and show their government ID. Then we have Tim or Brion log them in personally. ;) *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
Well if we are going to go down that road, requring public/private key pairs would also be more secure. However i doubt either would be acceptable to users. Actually, I think it might be better if we just have people come on down to the San Francisco office and show their government ID. Then we have Tim or Brion log them in personally. ;) Actually to be honest, if I could login to Mediawiki with a public/private keypair I would actually really enjoy that. Certainly it shouldn't be the default, but in a very non-joking way, I would support an initiative to add that as an option. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: FW: effects on caching
Better late than never :) Relevant to today's outage. -Chad -- Forwarded message -- From: Schubotz, Moritz schub...@tu-berlin.de Date: Thu, Feb 6, 2014 at 2:04 PM Subject: FW: effects on caching To: innocentkil...@gmail.com innocentkil...@gmail.com FYI *From:* Schubotz, Moritz *Sent:* Mittwoch, 29. Januar 2014 14:33 *To:* wikitech-l@lists.wikimedia.org *Subject:* FW: effects on caching Hi, please be informed that recent changes in the Math extension and core might influence the stability of large MediaWiki instances due to a change in the cache key. Please contact me for further details. Best Physikerwelt *From:* Schubotz, Moritz *Sent:* Mittwoch, 29. Januar 2014 11:22 *To:* Antoine Musso *Subject:* effects on caching Hi hashar, I’d like to point out that the change that has been merged changes that caching behavior of MediaWiki for all pages that contain math. The expected behavior can be described as follows: “ By the way you can verfiy in the following way mediawiki/includes/parser/ParserCache.php ll 193 wfDebug( ParserOutput cache found for key $parserOutputKey. \n ); You see somehting like ParserOutput cache found for key wiki:pcache:idhash:1-0!0!*!*!*!*!*. for pages that contain math and ParserOutput cache found for key wiki:pcache:idhash:2-0!*!*!*!*!*!*. for pages that do not contain math checkout https://gerrit.wikimedia.org/r/#/c/108490/ page without math still has the same key ParserOutput cache found for key wiki:pcache:idhash:2-0!*!*!*!*!*!*. but the key for the page with math the debug output will read [Math] New cache key: *!*!*!*!*!*!math=0 ParserOutput cache found for key wiki:pcache:idhash:1-0!*!*!*!*!*!*!math=0. I think it's now save to merge since it won't affect pages that do not contain math and it won't have effects at all unless getMath is removed. “ Now getMath was removed before the change to the math extension has been merged. If the changes are deployed in the same order as they were merged it will create errors visible for the visitors. If they are merged in the correct order, all pages that contain math will be reRenderd on their first visit. (I think even by an anonymous user.) Since there is a high load I think that it means that all pages that contain math tags approx. 30 000 for the English Wikipedia will be rerenderd at the same time. I expect that this will influence the performance of the the wmf system in a negative way, but I cannot decide how negative that will be. Best Physikerwelt ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
On Thu, Feb 6, 2014 at 4:54 PM, Derric Atzrott datzr...@alizeepathology.com wrote: Actually to be honest, if I could login to Mediawiki with a public/private keypair I would actually really enjoy that. Certainly it shouldn't be the default, but in a very non-joking way, I would support an initiative to add that as an option. You mean kind of like this? https://www.mediawiki.org/wiki/Extension:SSLClientAuthentication *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Password Hash
On Wed, Feb 5, 2014 at 8:26 PM, C. Scott Ananian canan...@wikimedia.orgwrote:
Password hashing algorithms are not the same as general hash algorithms. I
would prefer we didn't use whirlpool; it is recommended by NESSIE and ISO
as a hash function, but as a password hash. CWE916 recommends bcrypt,
scrypt, and PBKDF2 specifically for password hashing.
To be clear, I have nothing against the Whirlpool hash algorithm itself:
it's got a long pedigree with a decent amount of cryptoanalysis. It's just
the extension to password hashing which is nonstandard. If you wanted to
use Whirlpool as a password hash, you should apply it as part of PBKDF2,
which is parameterizable. That would be a reasonable way to distinguish
the WMF hash to avoid general attacks without inventing new cryptography.
The default PRF for PBKDF2 is HMAC-SHA-1; you would be replacing this with
HMAC-Whirpool. This would be much preferable to using
str_repeat+Whirlpool.
--scott
Sorry for the misleading. Tim's algorithm was indeed in reference to
using str_repeat vs. the tight xor loop of pbkdf2. Here are the relevant
ways that each do work:
pbdkf2:
for ( $j = 1; $j $this-params['rounds']; ++$j ) {
$lastRound = hash_hmac( $this-params['algo'], $lastRound, $password, true
);
$roundTotal ^= $lastRound;
}
Tim's:
for ( $i = 0; $i $iter; $i++ ) {
$h = hash( 'whirlpool', str_repeat( $h . $this-args[0], 100 ), true );
$h = substr( $h, 7, 32 );
}
If you look at whirlpool's compression function for the long messages, and
see that pbdkf2 as pretty much a Davies-Meyer compression function, they
have very similar properties. Except where they're subtly different, of
course ;).
The first subtle difference that I like about pbkdf2 is that the password
is mixed in at each round throughout, whereas Tim only mixes it in directly
in the first iteration (which is roughly the same as 3 rounds of pbkdf2 for
an 8 character password and 8 byte salt, since whirlpool is operating on
512-bit blocks). This could make pbkdf2 weaker if a key recovery attack
suddenly showed up in the hmac function, although that seems very unlikely
for hmac-sha256.
Additionally, since Tim's assigns the output to $h instead of xoring into
the previous round, that would be the same as pbkdf2 doing an assignment
every 14 rounds, which would feel a little weaker to me. Tim's could be
updated to keep the last block and do an xor instead, and they would be
more similar.
For someone doing a custom crypto scheme, I think Tim does better than
most, but overall it seems like most people prefer complying with a well
recommended standard than being unique.
So far no one has said they dislike pbkdf2, while bcrypt would require an
extra hash in serial to make sure long passwords can be handled, and would
require the php version bump. Anyone have strong opinions against pbkdf2?
On Wed, Feb 5, 2014 at 10:00 PM, Marc A. Pelletier m...@uberbox.org
wrote:
On 02/05/2014 09:34 PM, Tim Starling wrote:
Maybe Chris's phrasing misled you: I didn't invent the Whirlpool
algorithm
And so it did; something a quick google would have revealed. In my
defense, The Whirlpool algorithm by Tim was pretty convincing
attribution. :-)
I'd need to read up on that algorithm a bit before I have an opinion on
whether length-extension attacks are not an issue with it (which is
often particularly nasty when the message repeats or is cyclical). Most
hashes fare better by prepending a nonce as salt than they do by padding
or repeating.
-- Marc
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] The Zürich Hackathon and you
Hi, the registration to the Zürich Hackathon will open very soon. https://www.mediawiki.org/wiki/Zurich_Hackathon_2014 Wikimedia CH is doing a great work putting in place the foundations of the event. There are two areas where they need help from the tech community: * defining the schedule * processing travel sponsorship requests We should have 3-5 experienced contributors in each of these areas, overlaps allowed. In the first case they would drive the definition of the schedule, with whatever community process they want to put in place. In the second place they would need to go case by case and decide privately as a team whether candidate X gets sponsorship or not. Who wants to get involved in the program? I'm happy to help with the sponsorship requests. Please document in the wiki page. I will be on offline holidays on Feb 8-17, but you can ask any questions about the event to Manuel, CCed. Thank you! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: FW: effects on caching
Chad wrote: *From:* Schubotz, Moritz *Sent:* Mittwoch, 29. Januar 2014 14:33 *To:* wikitech-l@lists.wikimedia.org *Subject:* FW: effects on caching Looking at http://lists.wikimedia.org/pipermail/wikitech-l/2014-January/ I guess this message never made it through. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
Chris Steipp wrote: 1) As I understand it, the reason we went from 0 to 1 character required is spammers were actively trying to find accounts with no password so they could edit with an autoconfirmed account. Err, citation needed. :-) I'd forgotten that I'd filed https://bugzilla.wikimedia.org/18222 (related to MediaWiki core rather than Wikimedia). I thought the change from 0 to 1 for this variable generally was due to integration issues with other authentication systems, but I have no idea why I think this. I looked at an older version of Wikimedia's InitialiseSettings.php and found only the accompanying code comment enforce prohibition of blank passwords (the $wgMinimalPasswordLength variable was presumably subsequently removed when someone noticed that its value matched the software default value). I didn't see any relevant entries in the Wikimedia server admin log in my brief search. Arguing to increase minimal password length as an anti-spam measure is reasonable provided that there's an actual (i.e., demonstrable) issue that needs to be addressed and that there's good reason to believe that this particular measure will mitigate that issue. However, if there isn't evidence to suggest that this is an effective anti-spam approach, a needless increase in the default value of this variable has the taste of security theater. 2) We do have a duty to protect our user's accounts with a reasonable amount of effort/cost proportional to the weight we put on those identities. I think we would be in a very difficult spot if the foundation tried to take legal action against someone for the actions they took with their user account, and the user said, That wasn't me, my account probably got hacked. And it's not my fault, because I did the minimum you asked me. With respect, I think this is an unfair argument to make. It strikes me as a rough appeal to authority (legal consequences) without any kind of reference or substantiation. If you think that the setting of $wgMinimalPasswordLength in MediaWiki core or on Wikimedia wikis is a legal issue, you should consult with the Wikimedia Foundation legal team. I don't think it's fair to use legal theories and speculation as a basis for changing software settings. The fact that most users can edit while logged out (anonymously) also seems to poke large holes in this idea. Whether it's 4 or 6 characters for us I think is debatable, but I think 1 is not reasonable. Minimal password length has been configurable since January 2005 (cf. https://www.mediawiki.org/wiki/Special:Code/MediaWiki/48968) and no Wikimedia wiki community has asked for it to be increased in all these years, as far as I'm aware (I looked around Bugzilla). I think most users feel that account maintenance is a personal responsibility issue. As discussed at https://bugzilla.wikimedia.org/25925 it's a matter of convenience versus security. If you want to set the value of $wgMinimalPasswordLength higher for officewiki or other private Wikimedia wikis, that's obviously (at least partially) your prerogative. But for MediaWiki core and for standard Wikimedia wikis, I'd like there to be a decent rationale before we consider inconveniencing users. MZMcBride P.S. I also casually wonder whether there's a reasonable argument to be made here that requiring longer passwords will hurt editor retention more than it helps, but this thought is still largely unformed and unfocused. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
