[MediaWiki-CodeReview] [MediaWiki r101330]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101330. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101330 Commit summary: fixed obvious misprint ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101329]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r101329. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101329#c25172 Commit summary: Fixing and improvement code of CheckUser API module Comment: I wouldn't call using extract() as an improvement. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101320]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101320. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101320 Commit summary: Add namespace gender aliases for 'stq' http://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion%3ARaymond&action=historysubmit&diff=95232734&oldid=95208259 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101317]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101317. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101317 Commit summary: De-register alias file per delition r101313 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r92109]: New comment added
User "MZMcBride" posted a comment on MediaWiki.r92109. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92109#c25171 Commit summary: (bug 29558) Add config var to disable update.php. Did this by checking $wgMiserMode and bailing unless --iknowwhatimdoing Comment: I filed bug 32072 and bug 32073 as a result of this revision. I think this revision should be marked "fixme". ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89405]: New comment added, and revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r89405. Old Status: ok New Status: fixme User "Aaron Schulz" also posted a comment on MediaWiki.r89405. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89405#c25170 Commit summary: Deprecated wfGetAgent(), use $wgRequest->getHeader( 'User-Agent' ) instead Comment: Actually, this doesn't work for API edit (causing bug 32027). This is yet another bug caused by the API using FauxRequest and overriding $wgRequest... I see $wgRequest->getHeader( 'X-Forwarded-For' ) in the /trunk code, which will suffer similarly. FauxRequest lacks getIP() for the moment, so it would at least fatal if anyone tried to update CU to use that. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for October 24, 2011 - October 31, 2011 Status changes this week Bugs NEW : 314 Bugs ASSIGNED : 11 Bugs REOPENED : 36 Bugs RESOLVED : 114 Total bugs still open: 6491 Resolutions for the week: Bugs marked FIXED : 81 Bugs marked REMIND : 0 Bugs marked INVALID: 7 Bugs marked DUPLICATE : 11 Bugs marked WONTFIX: 8 Bugs marked WORKSFORME : 8 Bugs marked LATER : 2 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component android 11 generic 11 Javascript 6 iphone 5 Internationalization4 New Bugs Per Product MediaWiki 46 Wikimedia 15 MediaWiki extensions22 Wikimedia Mobile27 CiviCRM 1 Top 5 Bug Resolvers mah [AT] everybody.org 22 sam [AT] reedyboy.net 13 roan.kattouw [AT] gmail.com 10 aschulz4587 [AT] gmail.com 6 herman.wong [AT] nitobi.com 5 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On Sun, 30 Oct 2011 10:21:42 -0700, Svip wrote: > On 26 October 2011 13:55, William Allen Simpson > wrote: > >> Many of these accounts have expired email, so I don't see any notices. >> Recently, one that has a current email sent me a notice that reads in >> relevant part: >> >> # Temporary password: YH2MnDD >> # >> # This temporary password will expire in 7 days. >> # You should log in and choose a new password now. If someone else made >> this >> # request, or if you have remembered your original password, and you no >> longer >> # wish to change it, you may ignore this message and continue using >> your old >> # password. >> # >> I use fairly long passwords with special characters (a 96 character set >> including space). This replacement password is much more easily >> guessed. >> The account could have been stolen within minutes or hours. >> >> https://secure.wikimedia.org/wikipedia/en/wiki/Password_strength >> >> (Merely 7 case insensitive alphanumeric characters is equivalent to only >> 40-bits of strength.) >> >> Please update the password generator to use at least 17 characters, with >> at least some punctuation! (Users reading the text might have trouble >> noticing blanks, so don't use the space character.) > > You do not seem to understand how they get access to your password > these days. Far fewer people try to get through the front door. Most > systems have methods against brute-forcing (e.g. waiting for 5 seconds > on every third wrong guess, etc.). So brute-forcing is not desirable > against the system you are trying to hack (unless you wish to deny it > service). > > The most likely scenario is an attempt to obtain either the database > through SQL injections (probably tricky on a MediaWiki set up) or > through your cookie. Most systems use a system where the hashed > salted (I hope) password is saved in the cookie. Somehow getting your > cookie will allow them to bruteforce the hashed sum. Although, > depending on your system this can take from a few hours to a couple of > years. > > Few systems are going to walk up to the front door and try to knock > itself in. Your system will discover the behaviour if it is clever > enough. No good system EVER stores the user's password in a cookie, no matter how much it's hashed, salted, or fried... There is no good rationale for it (besides the exception like say phpMyAdmin where the password is not being used for auth but is actually a piece of data passed on to another system). A good system will only use either a session token or another type of randomly generated token like the user_token we use for 'remember me' logins. Session tokens aside since those expire and are php generated iirc. Our setToken code that creates a user_token is an md5 of the wiki's secret key, an mt_rand from 0-2147483647, wiki id, and the user's id. Now since what matters in a general brute force here is the number of possible guesses, the relevant number is how many possible keys can md5 output. Now doing this the lazy way md5() outputs a 32 char hexadecimal string. So that's (16^32) = 3.4 x 10^38 possible keys to brute force. Admittedly you have as long as it takes for the user to decide they feel like changing their password, and there is no rate limiting for basic web requests, but the search space of md5 output looks to be so large I can't really calculate how many centuries it would take to search. So given that md5 is so large (and if you have a problem with that, then convince domas it's worth a schema update to switch to a larger hash algorithm) a more productive attack attempt would be to instead brute force based on known information. If an attacker is able to get a wiki to expose their secret key, know the wiki id used when the user last had a password change, and get the user's id. Then they only have 2147483647 possible tokens they need to brute force which would probably take just a few days to brute force. That said a wiki's secret is... well, supposed to stay secret. And it's a very long randomized string so even if you tried to build a rainbow table of every possible secret key + mt_rand result with your own wiki id and user id using a local machine where you can hardware accelerate things and say generate 100 trillion of these entries a second and compare that with the user_token you are served personally. I don't believe even then you could brute force a wiki's secret key in any reasonable amount of time. Even though I say that, the worst thing would probably be a small wiki being loose with their secret key and not bothering to randomize it. Given that, it would probably be a good idea to try and mix in some sort of crypto-random source into the data to be hashed if we have any available. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org
Re: [Wikitech-l] Search completion
Yes, it's clearly the wrong way, but we don't have much infrastructure
to do it otherwise at the moment. Indexing template-expanded articles
would help, I'm sure there's a bug report for that somewhere..
r.
On 10/30/2011 11:06 PM, Lars Aronsson wrote:
> On 10/30/2011 10:41 PM, Robert Stojnic wrote:
>> It is derived based on link statistics, however, the links needs to be
>> in the article, and not generated by wikitext magic.
> I see. Do you analyze the static XML dump, to get the statistics?
> I think this is the wrong way. Should I file a bugzilla report that
> this should rather be based on the "what links here" table?
>
> Wiktionary entries for inflected forms link back to the main entry
> using templates, of course. One example is {{plural of|goose}}.
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101326]: Revision status changed
User "Siebrand" changed the status of MediaWiki.r101326. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101326 Commit summary: revert r101325 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101325]: Revision status changed
User "Siebrand" changed the status of MediaWiki.r101325. Old Status: new New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101325 Commit summary: i18n fix ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] #parser parser function - does this make any sense?
On 30/10/11 16:47, Happy Melon wrote:
>> I think that would make more sense as a tag extension (parse doesn't
>> look like a good name, what about ?).
>>
>> @Happy Melon: I think he wants a funtion which shows both parsed
>> wikitext and the original source.
>>
>>
> He intends to *build* such a structure, certainly; but I read the OP as
> saying he wanted to implement it via a template like {{demonstrate
> template}} [1] but with (just) the backend handled by a new parser
> function. I agree that you'd be better off/would avoid many of the
> problems given above by having a tag extension
> {{foo|bar|baz=quok}} that spat out its contents as a
> parameter to a customisable system message that read something like
> ""$1 produces: $1"". If I remember the parse
> order of tag extensions verses parser function extensions right, that
> should work pretty much straight out of the box??
>
> --HM
A tag hook spits out html, so he would output the content as literal,
then recurse and output it again parsed.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Search completion
On 10/30/2011 10:41 PM, Robert Stojnic wrote:
> It is derived based on link statistics, however, the links needs to be
> in the article, and not generated by wikitext magic.
I see. Do you analyze the static XML dump, to get the statistics?
I think this is the wrong way. Should I file a bugzilla report that
this should rather be based on the "what links here" table?
Wiktionary entries for inflected forms link back to the main entry
using templates, of course. One example is {{plural of|goose}}.
--
Lars Aronsson (l...@aronsson.se)
Aronsson Datateknik - http://aronsson.se
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101324]: New comment added
User "Siebrand" posted a comment on MediaWiki.r101324.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101324#c25169
Commit summary:
follow up to r99941, took care of Neils comments
Comment:
{{messagedocumentation}}
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101323]: Revision status changed
User "Pgehres (WMF)" changed the status of MediaWiki.r101323. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101323 Commit summary: followup from r101321 reset setHeaders() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101321]: Revision status changed
User "Pgehres (WMF)" changed the status of MediaWiki.r101321. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101321 Commit summary: adding caching for fundraiser landing page extension with default 5 minutes ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Search completion
It is derived based on link statistics, however, the links needs to be in the article, and not generated by wikitext magic. r. On 10/30/2011 09:19 PM, Lars Aronsson wrote: > In the search box, I get suggestions on the fly as I type, and I'm > often impressed by the good suggestions. However, right now at Wiktionary > I get suggestions that aren't the best ones for the given prefix. > > For example, at en.wiktionary.org if I type "lagru" it doesn't > suggest"lagrum", but instead a bunch of inflected and derived > forms: > lagrumshänvisning > lagrums > lagrumshänvisnings > lagrummets > lagrummen > lagrummet > lagrumshänvisningars > lagrumshänvisningar > lagrumshänvisningarnas > lagrumshänvisningarna > > Since these are Swedish entries in the English Wiktionary, > none of these pages get much traffic. Are the completion > suggestions based on traffic stats? In this case, link > count might be a better predictor for best suggestion, > since all derived forms link back to the basic form. > > Not much traffic: 5 page views in 30 days, > http://stats.grok.se/en.d/latest/lagrum > > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] declining Google Code-In
Hoi, At translatewiki.net we are quite happy to recognise Lewis as one of our own.. He is one of our technical guys. Thanks, GerardM On 30 October 2011 09:28, Lewis Cawte wrote: > On 29/10/2011 02:38, Sumana Harihareswara wrote: > > (What follows is MediaWiki community stuff, not technical discussion, > > offered in the interests of transparency and collaborative planning.) > > > > TL;DR version: I don't think we can do Google Code-In well, so I don't > > think we should apply to participate this year. > > > > Since MediaWiki has participated in the Google Summer of Code mentorship > > program, we have also received an offer to apply to participate in > > Google Code-In, which runs Nov. 21 2011-Jan. 16 2011. > > > > "Google Code-in is a contest for pre-university students (e.g., high > > school and secondary school students) with the aim of encouraging young > > people to participate in open source. We work with open source > > organizations, each of whom will provide a list of tasks to be completed > > by student contestants. Tasks can be anything a project needs help with, > > from bug fixes to writing documentation to user experience research." > > > > > http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/faq > > > > https://code.google.com/p/google-code-in/wiki/GCIAdminMentorInformation > > > > I have now gotten more information about what it's like to participate > > in GCI, from organizations that have taken part in the past. And it > > sounds like we just do not have the community capacity to do GCI this > year. > > > > * I can't take the time to develop the task lists or wrangle others to > > do so by the deadlines (applying by 1 November, creating big task lists > > by 21 November), due to other commitments (another volunteer > > development/mentoring program, India hackathon 18-19 November, mentoring > > existing new contributors). And I do not believe anyone else in the > > MediaWiki community has the capacity to administer our participation > > between now and mid-January, either. Tell me if I'm wrong! > > > > * We'd need enough mentors on call to review the teenagers' assignments > > as soon as they're submitted, so they aren't stuck waiting around before > > they can grab a new task. This is for the whole two-month period, > > including any winter holidays. Right now I do not think we can > > satisfactorily guarantee that. We all have too much other work that > > takes priority. > > > > So: it's a cool idea, but I don't think we can do it well in the given > > time period, so I'm turning it down. (Unless you want to run it, and > > can guarantee some mentors' attention! In which case, tell me ASAP so > > we can get an application in by 1 November.) > > > > BUT: the number of participants we're getting in our Coding Challenge > > (thanks, Greg!) means that if we want to do something like this > > *ourselves* next year, on our timeline, we could probably get some > > pretty good participation rates -- especially if we partner with > > Wikimedia Foundation's Global Education Program. So let's come back to > > this idea, perhaps sometime in the spring. > > > This upsets me, but I totally understand the reasoning for it... > I was wondering when it'd next come around, and I was hoping > MediaWiki/WMF would be in it... > > I'd be interested to participate in something like it, providing of > course that the Brighton Hackathon attendees have a heart attack at my > newbieness (which could well happen of course)... > > -- Lewis Cawte > 1 of 2 Registered Teenagers attending Brighton Hackathon > > ___ > 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] Search completion
In the search box, I get suggestions on the fly as I type, and I'm often impressed by the good suggestions. However, right now at Wiktionary I get suggestions that aren't the best ones for the given prefix. For example, at en.wiktionary.org if I type "lagru" it doesn't suggest"lagrum", but instead a bunch of inflected and derived forms: lagrumshänvisning lagrums lagrumshänvisnings lagrummets lagrummen lagrummet lagrumshänvisningars lagrumshänvisningar lagrumshänvisningarnas lagrumshänvisningarna Since these are Swedish entries in the English Wiktionary, none of these pages get much traffic. Are the completion suggestions based on traffic stats? In this case, link count might be a better predictor for best suggestion, since all derived forms link back to the basic form. Not much traffic: 5 page views in 30 days, http://stats.grok.se/en.d/latest/lagrum -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101277]: New comment added
User "Catrope" posted a comment on MediaWiki.r101277. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101277#c25168 Commit summary: Added speechbubble icon to the Moodbar trigger Comment: + background: url(images/icon-speechbubble-blue.png); Please use @embed to trigger data URL embedding, like so: /* @embed */ background: url(...); ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] declining Google Code-In
On Sun, Oct 30, 2011 at 10:02 PM, Antoine Musso wrote: > We can do some pair-programming during the Brighton week-end if you want :) > I'll match that offer. If a couple of us take turns showing Lewis (and/or other people!) around, it won't feel too cumbersome for anyone. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] declining Google Code-In
On 30/10/11 09:28, Lewis Cawte wrote: > providing of > course that the Brighton Hackathon attendees have a heart attack at my > newbieness (which could well happen of course)... We all have been newbie at one time and since our community is so awesome, any newbie can become a hacker in a couple years :D For a teenager my recommendations are: 1) keep being curious -> that is how the brain learn stuff. 2) do ask questions! -> *specifically* if you feel it is a dumb question. 3) repeat 1) 2) ad vitam We can do some pair-programming during the Brighton week-end if you want :) -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101049]: New comment added
User "Aaron Schulz" posted a comment on MediaWiki.r101049. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101049#c25167 Commit summary: FU r100915: split out GlobalWithDBTest (tests which need the DB) Comment: Didn't know you could do that :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101049]: New comment added
User "Hashar" posted a comment on MediaWiki.r101049. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101049#c25166 Commit summary: FU r100915: split out GlobalWithDBTest (tests which need the DB) Comment: To me, the @group statement was only to be applied to methods :d ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100417]: Revision status changed
User "Siebrand" changed the status of MediaWiki.r100417. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100417 Commit summary: Fix for Bug 31840 Renamed font folders to script codes. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100418]: Revision status changed
User "Siebrand" changed the status of MediaWiki.r100418. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100418 Commit summary: Moved the gez and cdo fonts to other script based folders. Follow up r100417 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100688]: Revision status changed
User "Siebrand" changed the status of MediaWiki.r100688. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100688 Commit summary: Reset the fonts for the tags with lang attribute for which we loaded fonts. Show the reset option, even if there is no fonts to show, but page has tags with lang attr based font embedding. Mingle card #122 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99635]: Revision status changed
User "Siebrand" changed the status of MediaWiki.r99635. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99635 Commit summary: * Fixed bug 31630: Renaming page translation page creates multiple log entries ** Replaced the old racy system with $objectcache->decr() which in theory can be atomic ** Replaced $wgMemc with wfGetCache( CACHE_ANYTHING ); * Added target page as parameter to log moveok log entry * Fixed the parameter in edit summaries of individual page moves to refer to the base bage * Fixed a fatal in TranslateEditAddons.php when editing a translation which is in the process of being moved ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100366]: New comment added
User "Reedy" posted a comment on MediaWiki.r100366. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100366#c25165 Commit summary: Also bundle ConfirmEdit, Gadgets, Nuke, RenameUser and WikiEditor Comment: I didn't even know that page existed. It was done against the list of open bugs for stuff that should be in core/included in tar ball This can still be added to/removed from, it's not an issue ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Temporary password too short
The reality is that _most_ people use the same username and password everywhere. So an attacker compromises phpBB or Wordpress (or name your favorite vunerable software here) somewhere and just uses those same credentials at other sites. If the user, by chance, didn't use the same password for another site - they probably DID use it for their email. The attacker has the users email address compromised and can simply request a password reset. Or the attacker could simply use firesheep since SSL logins aren't forced (yet). Or. Or. Or. Can we please stop arguing about this now? We've established there is a hundred and one ways to break into someones account. Temp password length seems like a low hanging fruit, but really changing that makes no different (as we've established). Like find something else to argue about that would actually increase security, like attempting to break Ryan's shiny new HTTPS cluster. On Sun, Oct 30, 2011 at 10:47, Neil Harris wrote: > On 30/10/11 15:46, Thomas Dalton wrote: > > On 30 October 2011 15:38, Neil Harris wrote: > >> However, this is way, way, way lower risk than the current risk of > >> brute-forcing low-hanging-fruit user passwords: for every user with a > >> password generated by base64-encoding the output of /dev/random, there > >> will be _thousands_ with passwords like "secret99" and "trustno1". > > A password from /dev/random is extremely insecure. It is highly > > susceptible to the "find where they wrote it down because it's far too > > difficult to remember" attack. > > > > Obligatory xkcd link: http://xkcd.com/936/ > > > > If you keep it in the password cache of your browser, on a > password-protected home directory on a laptop, that's probably secure > enough for most people -- with a good enough password, that roughly the > same level of security associated with an SSH key (long bit-pattern on > disk + physical possession of the object with the bit pattern on + > passphrase). [regarding passphrase strength -- obligatory XKCD link: > http://xkcd.com/538/ ] > > Again, we're concentrating too much on the moderately-secure part of the > problem -- long-enough passwords used by security-conscious users -- > and not paying enough attention to the weaker parts of the system such > as the vast number of users (probably including many admins) with weak > passwords, and the general failure to force a secure connection between > the user and the site for login pages and logged-on sessions. > > It's like having a thin cardboard box with a relatively weak wooden lid > -- upgrading the strength of the cardboard box is a more urgent task > than replacing the lid with a steel safe door. > > Once those are fixed, by all means let's then turn our attention to > things like temporary password lengths. > > -- N. > > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Jon [[User:ShakataGaNai]] / KJ6FNQ http://snowulf.com/ http://ipv6wiki.net/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On 30/10/11 15:46, Thomas Dalton wrote: > On 30 October 2011 15:38, Neil Harris wrote: >> However, this is way, way, way lower risk than the current risk of >> brute-forcing low-hanging-fruit user passwords: for every user with a >> password generated by base64-encoding the output of /dev/random, there >> will be _thousands_ with passwords like "secret99" and "trustno1". > A password from /dev/random is extremely insecure. It is highly > susceptible to the "find where they wrote it down because it's far too > difficult to remember" attack. > > Obligatory xkcd link: http://xkcd.com/936/ > If you keep it in the password cache of your browser, on a password-protected home directory on a laptop, that's probably secure enough for most people -- with a good enough password, that roughly the same level of security associated with an SSH key (long bit-pattern on disk + physical possession of the object with the bit pattern on + passphrase). [regarding passphrase strength -- obligatory XKCD link: http://xkcd.com/538/ ] Again, we're concentrating too much on the moderately-secure part of the problem -- long-enough passwords used by security-conscious users -- and not paying enough attention to the weaker parts of the system such as the vast number of users (probably including many admins) with weak passwords, and the general failure to force a secure connection between the user and the site for login pages and logged-on sessions. It's like having a thin cardboard box with a relatively weak wooden lid -- upgrading the strength of the cardboard box is a more urgent task than replacing the lid with a steel safe door. Once those are fixed, by all means let's then turn our attention to things like temporary password lengths. -- N. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On 26 October 2011 13:55, William Allen Simpson wrote: > Many of these accounts have expired email, so I don't see any notices. > Recently, one that has a current email sent me a notice that reads in > relevant part: > > # Temporary password: YH2MnDD > # > # This temporary password will expire in 7 days. > # You should log in and choose a new password now. If someone else made this > # request, or if you have remembered your original password, and you no longer > # wish to change it, you may ignore this message and continue using your old > # password. > # > I use fairly long passwords with special characters (a 96 character set > including space). This replacement password is much more easily guessed. > The account could have been stolen within minutes or hours. > > https://secure.wikimedia.org/wikipedia/en/wiki/Password_strength > > (Merely 7 case insensitive alphanumeric characters is equivalent to only > 40-bits of strength.) > > Please update the password generator to use at least 17 characters, with > at least some punctuation! (Users reading the text might have trouble > noticing blanks, so don't use the space character.) You do not seem to understand how they get access to your password these days. Far fewer people try to get through the front door. Most systems have methods against brute-forcing (e.g. waiting for 5 seconds on every third wrong guess, etc.). So brute-forcing is not desirable against the system you are trying to hack (unless you wish to deny it service). The most likely scenario is an attempt to obtain either the database through SQL injections (probably tricky on a MediaWiki set up) or through your cookie. Most systems use a system where the hashed salted (I hope) password is saved in the cookie. Somehow getting your cookie will allow them to bruteforce the hashed sum. Although, depending on your system this can take from a few hours to a couple of years. Few systems are going to walk up to the front door and try to knock itself in. Your system will discover the behaviour if it is clever enough. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101305]: New comment added
User "Catrope" posted a comment on MediaWiki.r101305. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101305#c25164 Commit summary: [RL2] Use Strangs instead of booleans for GadgetRepo::getAllGadgets_internal * Follow-up r100884 Comment: Why? It's a private function, not meant to be called (and ''impossible'' to be called) by anything else than the four wrapper functions. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101304]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101304. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101304 Commit summary: bugfix (missing comma) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101303]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101303. Old Status: deferred New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101303 Commit summary: allow "e-mail" and "email"; use the former as main label in De ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100855]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r100855. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100855 Commit summary: [RL2] Make the checkbox with the empty label on the shared preferences tab go away ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Temporary password too short
On 30 October 2011 15:46, Thomas Dalton wrote: > On 30 October 2011 15:38, Neil Harris wrote: > > > However, this is way, way, way lower risk than the current risk of > > brute-forcing low-hanging-fruit user passwords... > > A password from /dev/random is extremely insecure. > I don't believe these two statements are in any way mutually exclusive. There are degrees of "extremely insecure" in which "password1" ranks significantly higher than "the password I keep on the post-it in my desk drawer". One is very weak in the face of anyone connected to the internet, one is very weak in the face of anyone who has access to your office. Significantly more people have access to the internet than have access to your office/home/phone/filesystem. Neither threat is negligible, both are worth taking sensible measures to counter. But the point where the conversation loses all sense of perspective is when it loses all level of utility. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On 30 October 2011 15:38, Neil Harris wrote: > However, this is way, way, way lower risk than the current risk of > brute-forcing low-hanging-fruit user passwords: for every user with a > password generated by base64-encoding the output of /dev/random, there > will be _thousands_ with passwords like "secret99" and "trustno1". A password from /dev/random is extremely insecure. It is highly susceptible to the "find where they wrote it down because it's far too difficult to remember" attack. Obligatory xkcd link: http://xkcd.com/936/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] #parser parser function - does this make any sense?
On 29 October 2011 15:08, Platonides wrote:
> Daniel Werner wrote:
> > I am thinking about creating a very simple parser function #parse doing
> > nothing but returning parameter 1 with an "'noparse' => false" option.
> > Is there anything like this (or what could be abused for this) already
> > or is there any reason why this might be a bad idea?
> >
> > The reason I want to have something like this is, I want to create a
> > template (for template and parser function black-box tests) accepting
> > something like {{((}}#somefunction:a{{!}}b{{!}}c{{))}} as parameter
> > value, showing {{#somefunction|a|b|c}} as output and at the same time
> > calling {{#parse: {{((}}#somefunction:a{{!}}b{{!}}c{{))}} }} so that
> > besides the definition also the result can be shown by the template
> output.
> >
> > regards,
> > Daniel
>
> I think that would make more sense as a tag extension (parse doesn't
> look like a good name, what about ?).
>
> @Happy Melon: I think he wants a funtion which shows both parsed
> wikitext and the original source.
>
>
He intends to *build* such a structure, certainly; but I read the OP as
saying he wanted to implement it via a template like {{demonstrate
template}} [1] but with (just) the backend handled by a new parser
function. I agree that you'd be better off/would avoid many of the
problems given above by having a tag extension
{{foo|bar|baz=quok}} that spat out its contents as a
parameter to a customisable system message that read something like
""$1 produces: $1"". If I remember the parse
order of tag extensions verses parser function extensions right, that
should work pretty much straight out of the box??
--HM
[1] https://en.wikipedia.org/wiki/Template:Demonstrate_template
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101049]: New comment added
User "Platonides" posted a comment on MediaWiki.r101049. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101049#c25163 Commit summary: FU r100915: split out GlobalWithDBTest (tests which need the DB) Comment: Yes, that's how we have been using it since the beginning (what surprised me was that it seems to also be possible to apply it toi just one method). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101049]: New comment added
User "Hashar" posted a comment on MediaWiki.r101049. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101049#c25162 Commit summary: FU r100915: split out GlobalWithDBTest (tests which need the DB) Comment: Can we really apply the " @group Database" statement to a class? I am wondering if PHPUnit really support that. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Temporary password too short
On 30/10/11 11:28, William Allen Simpson wrote: > I'm going to pick on Neil a little, because I know he can take it, Yes, I can ;-) > but it applies to just about everybody else in this thread. > > For shame. My main point here is that (given some simple assumptions about how the site is administered) this is largely a theoretical problem, not a practical one, and there are far bigger problems that need fixing more urgently. This is not to say that a few more characters in the password, or a long term move to a more secure mechanism using much longer tokens, wouldn't be a good idea, but I don't think it's nearly as big a deal as you currently think, and we have more serious problems than this (see below) which need fixing first. [snip] > I really wish folks would at least read a Wikipedia article before > making such calculations. :-( > > No, you've listed the number of combinations, not the entropy. > > No, 40-bits of strength means 2**20 attempts on average. Same order of > magnitude as WEP. You remember WEP, the security designed to be > easily crackable? > > https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy No, you're thinking of a birthday attack, which does indeed takes ~ sqrt(n) guesses on average. A simple brute-force guessing attack, which this would be, takes n/2 guesses on average. In this case, 62^7 ~= 2^41, so you're looking at roughly 2^40 guesses to hit a collision, not 2^20. A bit of rate-limiting on the password recovery mechanism should be enough to limit this to a reasonable level of security: even with the current 7-character temporary passwords, if the mechanism has a site-wide limit to (say) one forced password reset attempt per second, one account will end up being successfully brute-forced roughly every 30,000 years. Of course, this would mean that the mechanism could easily be DDoS'd, but that's really no big deal either -- the password reset mechanism is hardly core infrastructure, and, could trivially be tweaked to be more secure -- and yes, adding a few more characters to the password wouldn't hurt. However, this is way, way, way lower risk than the current risk of brute-forcing low-hanging-fruit user passwords: for every user with a password generated by base64-encoding the output of /dev/random, there will be _thousands_ with passwords like "secret99" and "trustno1". -- Neil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On Sun, 30 Oct 2011 05:34:02 -0700, Thomas Dalton wrote: > On Oct 30, 2011 11:29 AM, "William Allen Simpson" < > william.allen.simp...@gmail.com> wrote: >> On 10/26/11 9:13 AM, Neil Harris wrote: >> > Assuming the seven-character password given, "YH2MnDD", uses the > character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible > such passwords. >> > >> I really wish folks would at least read a Wikipedia article before >> making such calculations. :-( >> >> No, you've listed the number of combinations, not the entropy. >> >> No, 40-bits of strength means 2**20 attempts on average. Same order of >> magnitude as WEP. You remember WEP, the security designed to be >> easily crackable? >> >> https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy >> >>In 2005, a group from the U.S. Federal Bureau of Investigation gave a >>demonstration where they cracked a WEP-protected network in 3 minutes >>using publicly available tools. >> >> Or, maybe, perhaps, you might trust that a well-known long-time security >> professional is telling you the generated password is too weak. ;-) > > If you are going to be so insulting, please at least try and be right... > You could start by reading the articles you are telling other people to > read. > > For a random sequence of characters, the entropy is just the base-2 log > of > the number of combinations, so there is nothing wrong with just > calculating > the number of combinations. Converting to entropy just makes it easier to > compare two passwords drawn from different character sets. > > WEP is flawed because it encrypts different parts of the message using > related keys, not because it is susceptible to a brute force attack on > the > password. It is completely irrelevant to our discussion. > > To get the average number of attempts, you half the number of > combination, > you don't square root it. With 40 bits, the average is 2^39 attempts, not > 2^20. And to top it off WEP is a local attack, one where you can brute force at a much higher rate than you can over the latent Internet hitting servers as fast as they can handle your requests. I do take back my estimate of it taking 1.14 centuries at 1000 guesses/second to brute force the entire password space. That was calculated on the basis of normal passwords which are length-variant as well, but the one we generate is fixed-length so that doesn't apply. Looking at our code we generate a fixed-length random password: - length 7 or the minimum password length, whichever is larger (minimum password default seams to be 1 so it's usually 7) - one character is always a digit, which character is a digit is random - All other characters are [a-zA-Z] A digit has 10 possibilities, the alphabet has 26 characters which combined with an upper-lower set is (26*2) = 52 possibilities. So for one digit placement (ie: #XX) the number of possible passwords is (10 * 52^6) (ie: [10, 52, 52, 52, 52, 52, 52]), for all 7 digit placements that is multiplied by 7. (10 * 52^6) * 7 = 1383942676480 So there are 1383942676480 (~1.38 x 10^12) possible passwords to generate. Going back to the estimate of a theoretical brute force attack able to guess 1000 passwords/second without any rate limiting, that will take 8.95 years to go through the entire password space. If I understand Thomas Dalton's note about halving the number of combinations then that would be an average of 4.5 years. Given that we expire a temporary password within 7 days after generating it at 1000 passwords/second an attacker will be able to go through (7 * 24 * 60 * 60 * 1000) = 60480 potential passwords, which when divided by the number of possible passwords is ((7 * 24 * 60 * 60 * 1000) / (10 * 52^6)) = 0.3% of the possible passwords. And of course, we rate limit password guesses when a cache is available. Though making that a 'we always rate limit password guesses' would be a good idea. Since the strength of that is already good enough I'd still opt to instead work on the less simple task of replacing our randomized 'passwords' with a generated token embedded in a link. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101301]: Revision status changed
User "MaxSem" changed the status of MediaWiki.r101301. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101301 Commit summary: Hmph, yet another bug caused by not having @since ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Temporary password too short
On Sun, Oct 30, 2011 at 2:20 PM, Antoine Musso wrote: > On 30/10/11 12:28, William Allen Simpson wrote: > >> > It might perhaps be worth adding one more character, > > Really, how*hard* is it to generate a longer string? > > Have a look at the method User::randomPassword() in the file > includes/User.php : > > Password is at least 7 characters long and can be made longer with the > global $wgMinimalPasswordLength (which will require longer password for > everyone). > > So we could just change that 7 to 10 and we will get longer temporary > passwords. > We could, but why would we? As has been shown by me and others in this thread, any brute force attempt that has a reasonable chance to crack the current passwords would already include an amount of traffic to the Wikimedia servers amounting ot a Denial of Service attack. -- André Engels, andreeng...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On 30/10/11 12:28, William Allen Simpson wrote: >> > It might perhaps be worth adding one more character, > Really, how*hard* is it to generate a longer string? Have a look at the method User::randomPassword() in the file includes/User.php : Password is at least 7 characters long and can be made longer with the global $wgMinimalPasswordLength (which will require longer password for everyone). So we could just change that 7 to 10 and we will get longer temporary passwords. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On Oct 30, 2011 11:29 AM, "William Allen Simpson" < william.allen.simp...@gmail.com> wrote: > On 10/26/11 9:13 AM, Neil Harris wrote: > > Assuming the seven-character password given, "YH2MnDD", uses the character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords. > > > I really wish folks would at least read a Wikipedia article before > making such calculations. :-( > > No, you've listed the number of combinations, not the entropy. > > No, 40-bits of strength means 2**20 attempts on average. Same order of > magnitude as WEP. You remember WEP, the security designed to be > easily crackable? > > https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy > >In 2005, a group from the U.S. Federal Bureau of Investigation gave a >demonstration where they cracked a WEP-protected network in 3 minutes >using publicly available tools. > > Or, maybe, perhaps, you might trust that a well-known long-time security > professional is telling you the generated password is too weak. ;-) If you are going to be so insulting, please at least try and be right... You could start by reading the articles you are telling other people to read. For a random sequence of characters, the entropy is just the base-2 log of the number of combinations, so there is nothing wrong with just calculating the number of combinations. Converting to entropy just makes it easier to compare two passwords drawn from different character sets. WEP is flawed because it encrypts different parts of the message using related keys, not because it is susceptible to a brute force attack on the password. It is completely irrelevant to our discussion. To get the average number of attempts, you half the number of combination, you don't square root it. With 40 bits, the average is 2^39 attempts, not 2^20. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
I'm going to pick on Neil a little, because I know he can take it, but it applies to just about everybody else in this thread. For shame. On 10/26/11 9:13 AM, Neil Harris wrote: > On 26/10/11 13:03, Steve Summit wrote: >> William Allen Simpson wrote: >>> This replacement password is much more easily guessed. >>> The account could have been stolen within minutes or hours. >> Is this true? (Yes, I know that a fast machine can try zillions >> of passwords per hour in theory, but for a reasonably designed >> system, certainly not in practice.) >> >>> Please update the password generator to use at least 17 characters, >> That seems like far too many. >> > > In practice, that password is probably much stronger than most users' > real passwords. > Please don't conflate user choices with our choices. Since the password is generated on demand, the adversary *knows* something was generated and sent. That's quite different than attacking a random user. It is our choice to send a weak password in email -- a bad choice. > It might perhaps be worth adding one more character, Really, how *hard* is it to generate a longer string? >, but the simplest > way to increase security on this would be to just put a limit on the > number of reactivation attempts for that particular password. > Why would this be simpler? Seems like a lot more code to me. > Assuming the seven-character password given, "YH2MnDD", uses the character > set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords. > I really wish folks would at least read a Wikipedia article before making such calculations. :-( No, you've listed the number of combinations, not the entropy. No, 40-bits of strength means 2**20 attempts on average. Same order of magnitude as WEP. You remember WEP, the security designed to be easily crackable? https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they cracked a WEP-protected network in 3 minutes using publicly available tools. Or, maybe, perhaps, you might trust that a well-known long-time security professional is telling you the generated password is too weak. ;-) > Automatically expiring that temporary password after say, 10 failed > reactivation attempts, would reduce the probability of successfully guessing > that particular password to around 3 x 10^-12 -- probably safe enough for > wiki purposes. > No, that's not correct math. Worse, that would generate a denial of service attack all on its own. All the adversary has to do is send periodic attempts to lock somebody out of their own account. Moreover, what problem does that solve? > Based on this, I don't think it's likely to be nearly as much of a problem as > brute-force attacks on ordinary login passwords that go for the "low-hanging > fruit" of users with passwords like "1234" or "password1". > This is the lowest *possible* hanging fruit. We're generating it! > Even these can be substantially mitigated by a mixture of per-account and > per-client-IP-address throttling, and CAPTCHAs. > While it would be nice to have better user password checking, and require all login sessions to be over HTTPS, and not use cookies to identify sessions, and many other desirable improvements -- this is the simplest and easiest thing I can imagine! > If there's one measure I'd like to see that isn't (as far as I know) yet > implemented, it would be to require admins and other privileged users to set > strong passwords, perhaps initially by Javascript-based warnings, and later > by locking out those accounts completely, after a warning period of perhaps > one year. > Now, that seems much too long a time. I'd make it a prerequisite for being an administrator at all! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r100366]: New comment added
User "MaxSem" posted a comment on MediaWiki.r100366. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100366#c25161 Commit summary: Also bundle ConfirmEdit, Gadgets, Nuke, RenameUser and WikiEditor Comment: /me seriously wonders why not Vector. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101293]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r101293. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101293#c25160 Commit summary: rc_cur_time is obsolete; added comment Comment: More exactly, it's value is always the same as rc_timestamp and is never read? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101287]: New comment added, and revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101287.
Old Status: deferred
New Status: fixme
User "Nikerabbit" also posted a comment on MediaWiki.r101287.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101287#c25159
Commit summary:
fixed " "/"_" encoding in fragment extraction;
improved display of page values on Property: pages
Comment:
{0} is deprecated syntax for indexing strings, should use [0].
+ if ( $this->m_fragment && $this->m_fragment{0} != '_' ) {
Is "000" not a valid fragment?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] wikipedia lacks a "share' button
On Sun, 30 Oct 2011 01:12:51 -0700, Marco Schuster wrote: > On Sat, Oct 29, 2011 at 4:22 PM, Daniel Friesen > wrote: >> - It doesn't scale very well. If you do try to add more vendors and >> users >> do enable most of them, you still end up loading from each enabled >> vendor >> slowing things down. > With the exception of the FB Like/Recommend button, everything (even > the FB share link) is just an image paired with a HTML link. Maybe > other sites allow embedding their logos, so the only image which needs > to be loaded externally is the FB one. No, both the Twitter and Google +1 share features in that socialshareprivacy are also embeds, not simple images paired with links. In fact while FB has a static share and Twitter has it's static share and intents, being the newest +1 hasn't implemented a static share feature yet. Likely somewhat related to the separation of +1 and G+ which unlike with the others +1ing something doesn't mean you're using G+. >> - Frankly the UI is pretty bad. > That's the price you have to pay for total privacy, unfortunately. No, there are other potential possibilities that don't include a bad ui. >> - Once you enable a vendor we drop right back to a 3rd party script >> being >> injected into the page such that it can do malicious things. >> >> Btw, if you're a 3rd party with a script in a page you can go pretty far >> abusing XHR and history.pushState to make it look to a user like they're >> browsing the website normally when in reality they're on the same page >> with the script still running. Oh, and that includes making it look like >> you're safely visiting the login page when in reality you didn't change >> pages and the script is still running ready to catch passwords. > Do you have any links with further info on this? > > Marco I don't know of any specific links you can look at, I realized it myself after looking at pushState. It's probably known elsewhere but I figured it out independently so I don't know of any more detailed articles or posts on it off my head. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101285]: New comment added, and revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101285. Old Status: deferred New Status: fixme User "Nikerabbit" also posted a comment on MediaWiki.r101285. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101285#c25158 Commit summary: Simplified subobject management by using property "_SOBJ" (Has subobject) to associate the data. Comment: '_qty' => 'Määrä', // name of the number type with units of measurement + '_qty' => 'Quantity', // name of the number type with units of measurement //TODO: translate That looks wrong :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101282]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101282. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101282 Commit summary: use appropriate display methods for wiki page values ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101280]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r101280. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101280#c25157 Commit summary: Overhauled formatting of wiki page data value. Main changes: * Full support for fragment display (needed for new subobjects) * Changed behaviour of short and long displaying methods to match their names * Improved "Image:" display Comment: Is "impage" a typo? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] declining Google Code-In
On 29/10/2011 02:38, Sumana Harihareswara wrote: > (What follows is MediaWiki community stuff, not technical discussion, > offered in the interests of transparency and collaborative planning.) > > TL;DR version: I don't think we can do Google Code-In well, so I don't > think we should apply to participate this year. > > Since MediaWiki has participated in the Google Summer of Code mentorship > program, we have also received an offer to apply to participate in > Google Code-In, which runs Nov. 21 2011-Jan. 16 2011. > > "Google Code-in is a contest for pre-university students (e.g., high > school and secondary school students) with the aim of encouraging young > people to participate in open source. We work with open source > organizations, each of whom will provide a list of tasks to be completed > by student contestants. Tasks can be anything a project needs help with, > from bug fixes to writing documentation to user experience research." > > http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/faq > > https://code.google.com/p/google-code-in/wiki/GCIAdminMentorInformation > > I have now gotten more information about what it's like to participate > in GCI, from organizations that have taken part in the past. And it > sounds like we just do not have the community capacity to do GCI this year. > > * I can't take the time to develop the task lists or wrangle others to > do so by the deadlines (applying by 1 November, creating big task lists > by 21 November), due to other commitments (another volunteer > development/mentoring program, India hackathon 18-19 November, mentoring > existing new contributors). And I do not believe anyone else in the > MediaWiki community has the capacity to administer our participation > between now and mid-January, either. Tell me if I'm wrong! > > * We'd need enough mentors on call to review the teenagers' assignments > as soon as they're submitted, so they aren't stuck waiting around before > they can grab a new task. This is for the whole two-month period, > including any winter holidays. Right now I do not think we can > satisfactorily guarantee that. We all have too much other work that > takes priority. > > So: it's a cool idea, but I don't think we can do it well in the given > time period, so I'm turning it down. (Unless you want to run it, and > can guarantee some mentors' attention! In which case, tell me ASAP so > we can get an application in by 1 November.) > > BUT: the number of participants we're getting in our Coding Challenge > (thanks, Greg!) means that if we want to do something like this > *ourselves* next year, on our timeline, we could probably get some > pretty good participation rates -- especially if we partner with > Wikimedia Foundation's Global Education Program. So let's come back to > this idea, perhaps sometime in the spring. > This upsets me, but I totally understand the reasoning for it... I was wondering when it'd next come around, and I was hoping MediaWiki/WMF would be in it... I'd be interested to participate in something like it, providing of course that the Brighton Hackathon attendees have a heart attack at my newbieness (which could well happen of course)... -- Lewis Cawte 1 of 2 Registered Teenagers attending Brighton Hackathon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r101271]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101271. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101271 Commit summary: distinguish generated (internal) subobject names by an initial _ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r101272]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r101272. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101272 Commit summary: removed some deprecated functions ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r100366]: New comment added
User "Peachey88" posted a comment on MediaWiki.r100366. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100366#c25156 Commit summary: Also bundle ConfirmEdit, Gadgets, Nuke, RenameUser and WikiEditor Comment: Was/Where are the discussions about ConfirmEdit, Gadgets and Nuke?, Those all had little or no votes on the page that was setup to discussion this [[Possible_tarballs]]. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97821]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r97821. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97821#c25155 Commit summary: Parser test for bug 31098, disabled of course Comment: Ok. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] wikipedia lacks a "share' button
On Sat, Oct 29, 2011 at 4:22 PM, Daniel Friesen wrote: > - It doesn't scale very well. If you do try to add more vendors and users > do enable most of them, you still end up loading from each enabled vendor > slowing things down. With the exception of the FB Like/Recommend button, everything (even the FB share link) is just an image paired with a HTML link. Maybe other sites allow embedding their logos, so the only image which needs to be loaded externally is the FB one. > - Frankly the UI is pretty bad. That's the price you have to pay for total privacy, unfortunately. > - Once you enable a vendor we drop right back to a 3rd party script being > injected into the page such that it can do malicious things. > > Btw, if you're a 3rd party with a script in a page you can go pretty far > abusing XHR and history.pushState to make it look to a user like they're > browsing the website normally when in reality they're on the same page > with the script still running. Oh, and that includes making it look like > you're safely visiting the login page when in reality you didn't change > pages and the script is still running ready to catch passwords. Do you have any links with further info on this? Marco ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
