Architecture meetings/Security guidelines discussion 2014-06-13

1500 UTC Friday 13 June at.

Text to review
Security for developers/Architecture

Meeting summary

 * LINK: https://www.mediawiki.org/wiki/Security_for_developers/Architecture (sumanah, 15:02:23)
 * ACTION: csteipp "IP address or UserAgent of editors" should be rephrased. (sumanah, 15:04:27)
 * ACTION: : Update "stuff we're trying to protect" to be more clear about the threat model (csteipp, 15:11:22)
 * ACTION: threat models should call out private wikis-- where confidentiality is more important than integrity, vs. public wikis. (csteipp, 15:19:18)
 * IDEA: Sam Smith suggests: i think including security requirements (gathered during the assessment phase) should be part of the [Trello/Mingle/Phabricator/Bugzilla] ticket (sumanah, 15:31:16)
 * ACTION: "For a long time, MediaWiki" needs to be more specific (superm401, 15:36:40)
 * ACTION: Section about conflict between security and other requirements, and thoughts on where to address those in the process (csteipp, 15:37:30)
 * IDEA: bring up 'whenever a new card/ticket/thing is created with a user story and a requirements section simply add a distinct "Security requirements" section to it; as a team you'd have to commit to giving the security requirements the same weight as the other requirements' on https://lists.wikimedia.org/mailman/listinfo/teampractices ? (sumanah, 15:41:14)
 * IDEA: It'd be nice if Phabricator has some sort of security planning widget. I wonder if such an app exists. (sumanah, 15:41:58)
 * ACTION: csteipp add https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm as a bad example of "Secure (fail-safe) defaults" - the new Match CAPTCHA was used as a default (per mutante) (sumanah, 15:51:28)
 * sumanah: I think at the architecture level, we need to stress integration with anti-spam. But the exact methods there are going to be very narrow, and probably not applicable to 99% of developers. (sumanah, 15:52:14)
 * "Minimize the attack surface" - we've always been pretty stingy on allowed file types, partly for security. (sumanah, 15:53:55)
 * LINK: http://www.cs.virginia.edu/~evans/cs551/saltzer/ (sumanah, 15:56:57)
 * closely related principle: in API design, the _easiest_, _most normal_ thing to do should also be the secure thing. Sometimes you need to allow people to do something unusual that is less secure, but then they should have to jump through extra hoops to demonstrate (to themselves and to future readers of the code) that they have thought about it and understand the implications. (sumanah, 15:59:11)
 * LINK: http://pyvideo.org/video/2647/designing-poetic-apis - the bit about building shoulders for the road is applicable here! http://www.slideshare.net/ErikRose/poetic-apis is the slides (sumanah, 15:59:35)
 * LINK: http://thecodelesscode.com/case/148 <-- nominally about caching, but just substitute security and it's the same principle (zwol, 16:05:08)
 * LINK: http://thecodelesscode.com/case/138 <-- why is computer so hard anyway? (zwol, 16:05:30)
 * LINK: http://thecodelesscode.com/case/140 <-- "Code as if everyone is the thief." (zwol, 16:05:43)

Action items

 * csteipp "IP address or UserAgent of editors" should be rephrased.
 * Update "stuff we're trying to protect" to be more clear about the threat model
 * threat models should call out private wikis-- where confidentiality is more important than integrity, vs. public wikis.
 * "For a long time, MediaWiki" needs to be more specific
 * Section about conflict between security and other requirements, and thoughts on where to address those in the process
 * csteipp add https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm as a bad example of "Secure (fail-safe) defaults" - the new Match CAPTCHA was used as a default (per mutante)

Action items, by person

 * csteipp
 * csteipp "IP address or UserAgent of editors" should be rephrased.
 * csteipp add https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm as a bad example of "Secure (fail-safe) defaults" - the new Match CAPTCHA was used as a default (per mutante)
 * **UNASSIGNED** (but probably Chris Steipp)
 * Update "stuff we're trying to protect" to be more clear about the threat model
 * threat models should call out private wikis-- where confidentiality is more important than integrity, vs. public wikis.
 * "For a long time, MediaWiki" needs to be more specific
 * Section about conflict between security and other requirements, and thoughts on where to address those in the process

Full log
15:01:56 #startmeeting Security guidelines | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours 15:01:56  Meeting started Fri Jun 13 15:01:56 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:56  Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:56  The meeting name has been set to 'security_guidelines___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' 15:02:05 #chair sumanah csteipp 15:02:05  Current chairs: csteipp sumanah 15:02:11 Sorry for the late start, folks! 15:02:11 Thanks sumanah! 15:02:15 Sure csteipp 15:02:23 #link https://www.mediawiki.org/wiki/Security_for_developers/Architecture 15:02:49 so, first, raise your hand if you've read this in the last 2 weeks? 15:02:51 o/ 15:02:58 o/ 15:03:11 o/ 15:03:24 Hi zwol! great to see you! 15:03:35 * halfak clicks link 15:04:03 Unfortunately I haven't. :( I'll check out the updates now. 15:04:16 So first off, do people think this is overall going in the right direction, to help developers know how to design and write secure code? 15:04:17 "IP address or UserAgent of editors" should be rephrased. 15:04:27 #action csteipp "IP address or UserAgent of editors" should be rephrased. 15:04:29 got it superm401 15:04:42 superm401: how so? 15:04:54 csteipp, IP of logged out editors is not confidential. 15:05:08 Ah, yeah, good clarification :) 15:05:18 I'll step back and say, 15:05:46 I think this document has morphed into a little of "secure development process" as well as "best practice for security architecture" 15:05:53 I'm not sure if they should be split. 15:06:14 I don't want yet another thing for users to read, but if it seems too processy, I can split it out. 15:07:06 If anyone has feelings one or or the other, yell 15:07:16 (/me thinks 15:07:18 er 15:08:55 so csteipp it seems to me like https://www.mediawiki.org/wiki/Performance_guidelines ok, so I'm going to talk about whether the same model applies here 15:09:11 This is kind of the obligatory thing for an academic security researcher to say, but I think there should be a section discussing the threat model. 15:09:21 Who is the adversary, and what are they trying to accomplish? 15:09:33 zwol: You mean for MediaWiki as a whole? 15:09:57 BTW I perceive this guideline to be aimed at people writing code that will run on Wikimedia servers 15:09:58 (This can wind up being just a perspective flip of the existing "What are we trying to protect" section, but it's valuable because people find it difficult to think from the adversary's perspective.) 15:09:58 primarily 15:10:14 with a secondary purpose of helping people writing code that will run in other MediaWiki installations 15:10:17 (Especially, people often have a blind spot when it comes to realizing what the adversary can _do_) 15:10:20 and this includes core, extensions, gadgets, templates 15:10:29 csteipp: this is pretty generic advice 15:10:45 zwol, there are a lot of threat models I think ("people who want to spy on users", "people who want to vandalize the wiki", "people who want to do things without accountability"...) 15:10:45 zwol: I think that would be a good update 15:11:11 I mean, the threat model between Wikipedia and an intranet private wiki are going to be a lot different. 15:11:14 superm401: yes but they're buried in the "what are we trying to protect" section 15:11:22 #action: Update "stuff we're trying to protect" to be more clear about the threat model 15:11:25 For comparison: the performance guidelines say "here are our performance principles and here are top-level guidelines on how to implement them (and NOT implement them), with brief explanations of good and bad examples. One of those guidelines is "follow the secure dev process, e.g., making this diagram." Really detailed stuff, such as HOW to make the diagram, should go in different pages IMO 15:11:40 sumanah, Lua modules too. 15:11:49 parent5446: that's kind of a mechanism-versus-policy issue from where i'm sitting 15:11:54 zwol: I think superm401 is saying that those adversaries *exist* not that they are described in the doc yet 15:12:12 ...maybe i'm reading between the lines too much :) 15:12:46 Could be. :-) 15:12:58 sumanah, correct, my point was there are a lot of threat models, not sure how useful it is to explicitly mention them all. But it may be good to explicitly mention the biggies (either in a dedicated section or elsewhere). 15:13:41 btw folks Zack is an old pal of mine from my pre-Wikimedia days and I owe a bunch of my early FLOSS/engineering informal education to him :) 15:13:57 (Zack being zwol) 15:14:02 Yeah, exhaustive list is pretty much impossible... but we can certainly call out the major ones 15:14:21 zwol: Nice to meet you! 15:14:40 Yep 15:14:50 It may help to say that I'm the person who was talking about traffic analysis on wikitech-l last week. 15:14:55 What does, "(neg) User identification" mean? Is it saying our user identification is too complex? 15:14:59 zwol: you may already know the folks here from the list, but csteipp is Chris, our Security Engineer; parent5446 is Tyler, a volunteer & CS student; superm401 is Matt, who works as an engineer at WMF 15:15:22 Thanks, Sumana.  I may or may not remember those names from the list :) 15:15:31 parent5446: And I do totally agree, wmf vs intranet wiki are very different, but I *think* intranet wiki will mostly be a subset of big public.. but are there any specific threats to the intranet wiki scenario you're thinking of? 15:16:54 Alright if I add wgEnableUploads (default false) as another example of fail-safe defaults? 15:17:02 I don't spend a ton of time thinking about non-public wikis, so I could totally be missing a threat model. 15:17:15 superm401: btw I would love from you an answer to my early question - do people think this is overall going in the right direction, to help developers know how to design and write secure code? I know you see problems but I wanted to check whether you overall are liking this 15:17:34 csteipp: The primary consideration is that confidentiality of content is a more important factor in a private wiki, whereas a public wiki prioritizes integrity. 15:17:41 sumanah, sorry, the reason I didn't answer that is that I'm reading during the meeting for the first time, but it looks very good so far. 15:18:12 :) thanks superm401 15:18:16 csteipp, also, confidentiality of users. 15:18:44 parent5446: cool. That probably is a good distinction to call out, based on our history of assuming everything is public. 15:18:53 * sumanah agrees 15:19:18 #action threat models should call out private wikis-- where confidentiality is more important than integrity, vs. public wikis. 15:19:53 concur 15:20:38 sumanah, superm401: seconded. i've enjoyed reading it 15:21:07 Thanks, that's great, phuedx! Was there anything in particular you either learned, or liked how Chris phrased maybe? 15:22:21 Btw, on the security principles section, I recently read, "I�ve learned that preaching about security principles, �economy of mechanism� and �complete mediation� and �least common mechanism� (and whatever else Saltzer and Schroeder talked about 40 years ago) and publishing manifestos are a waste of time. There�s nothing actionable; nothing that developers can see or use or test." 15:22:22 i was actually thinking that the sections could be reordered to: Threat Modelling, Implementation, Assess your feature's security, Security Testing 15:22:28 (https://blog.whitehatsec.com/easy-things-are-often-the-hardest-to-get-right-security-advice-from-a-development-manager/) 15:22:33 Agree/disagree? 15:22:46 which, in my head, is the way i'd go through the process of building a thing 15:23:32 csteipp: I'm gonna defer here to more experienced engineers, but I'm leaning towards agreeing with that author 15:23:33 phuedx: Yeah, that part is hard. I want to emphasize people should think about the threats before they build. But you're right, it's also after implementation. 15:24:11 csteipp: maybe: Thread Modelling, Assess your feature's security, Implementation, Validation/Security Testing? 15:24:54 Oh, hey, yeah. The "security testing" section deserves to be quite a bit longer. 15:25:10 phuedx: Yeah, validation is probably a good way to put it. 15:25:15 phuedx: csteipp - maybe there's some kind of milestone or ritual we can tie this to in our Agile Nimble world ;-) -- how do we integrate this into the rhythm of a team's iterations? 15:25:26 I find things like https://www.owasp.org/index.php/Top_10_2013-Top_10 (security issues that are specific, but not too specific, and keep coming back) helpful. 15:25:50 And it's a bit buzzwordese right now. Someone in a QA mindset might not realize that "positive and negative tests should be used" entails "obsessively test the code's response to *invalid* input, because the adversary can send in whatever the heck it feels like". 15:25:54 sumanah: to answer your question: in particular: STRIDE/MITRE's CAPEC list (that's /awesome/), and that section on psychological acceptability was really nice 15:25:55 So keep in mind every software process follows the process of Requirements -> Design -> Implementation -> Testing. During requirements is when threat modeling should be done. In design, it should be made explicit what security features are put into the feature. Then during testing, security testing should be done. 15:25:58 there's probably more ;) 15:26:00 I think things like "least common mechanism" (need to learn what this is) are useful to, but to a different audience. 15:26:14 parent5446: *every*? 15:26:15 s/probably/definitely/ 15:26:35 I like the "all input is evil unless proven otherwise" formulation in that article 15:26:44 And yeah, "Security Testing" needs a fair amount more. Mostly because that is where we spend the least amount of time in our process currently (sad but true). 15:26:58 sumanah: Yes. Even if you're following an agile development process, software features still do have requirements, and still need to be designed before they are implemented. 15:27:16 The difference is just in what order you do things and how often you do each phase. 15:27:27 Of course it's a bit more complicated, but that's the general idea. 15:27:36 sumanah: i think including security requirements (gathered during the assessment phase) should be part of the ticket 15:27:37 parent5446: OK, glad to see you're backing off a bit :) 15:28:02 sumanah: Yeah, trust me, I've worked with waterfall before. It's not the greatest. :P 15:28:03 that way a feature couldn't be complete until those requirements are satisfied 15:28:22 parent5446: I don't need to trust you. I've spent more years in the tech industry than you have. ;-) 15:28:45 Yeah, security basically needs to be baked in at every phase. 15:28:53 Lol good point 15:29:04 phuedx: Yeah, I was thinking about adding a section on that.. Non-functional requirements, or something along those lines. 15:29:12 zwol: (on the matter of prose: I've been fighting some other developers who want to put passive voice into guidelines and make things generally more "official-sounding". Argh.) 15:29:20 From user-facing requirements (i.e. "assess whether this feature is a good idea", high-level security) all the way down to XSS prevention while implementing. 15:29:50 superm401: That's exactly what I'm trying to do :) 15:30:18 sumanah: 'Official-sounding prose makes you sound more authoritative but also more boring, you risk people not paying attention'?  /table for later 15:30:19 phuedx: part of the Trello/BZ/etc. ticket? 15:30:28 superm401: One thing I was trying to do with this document is to convey that, without making a developer feel overwhelmed, and give up. 15:30:31 (Mingle/Phabricator/etc.) 15:30:32 sumanah: yeah 15:30:34 nod 15:30:39 all of 'em 15:30:46 Here's something else that's not covered.  I don't see exactly where to fit it in, though: 15:31:08 Interaction of security requirements with other requirements (e.g. usability, performance, features) 15:31:16 #idea Sam Smith suggests: i think including security requirements (gathered during the assessment phase) should be part of the [Trello/Mingle/Phabricator/Bugzilla] ticket 15:31:43 right 15:31:55 Sometimes they go hand in hand and sometimes they conflict. And a system that's super-secure but unusable ... won't get used. 15:32:04 YES 15:32:26 phuedx: Thanks. On platform, we don't do trello, I'd definitely love to hear ideas on how your teams could do that.. 15:32:52 Do what? 15:33:11 (Reliability is kind of an exception -- I have yet to see a case where improving security hurt reliability or vice versa. Some people encourage developers to think of security as a special case of reliability, in fact.) 15:33:32 superm401: Make gather requirements in the requirements phase integrate with your teams process 15:34:05 let's say you changed the SSL cipher settings to have better security but it would exclude all IE users 15:34:15 would that be an example of security hurt reliability? 15:34:35 mutante: I'd characterize that as security hurting usability, but not affecting reliability. 15:34:39 or is it availability 15:34:43 mutante: That's a great example, though. 15:34:44 ok 15:35:01 So I want to remind people that we do have some additional pages right now - https://www.mediawiki.org/wiki/Security_checklist_for_developers and https://www.mediawiki.org/wiki/MSG help you see them - in case some things from the current guidelines ought to be split off onto those 15:35:03 mutante: Ideally what you do in that circumstance is find a way to offer the weaker ciphers only to IE users 15:35:10 csteipp, we tend to work by creating Trello cards, sometimes breaking them down, and using meetings with video calls and Etherpad (copied to MediaWiki.org after the meeting). 15:35:29 and then put a banner on the page saying "hey, your browser is forcing us to use weak security" 15:35:36 MSG => MediaWiki Security Guide 15:35:40 ... but sometimes that's just plain impossible. 15:36:04 mutante: btw would you characterise yourself as someone who can speak to the needs of non-WMF MediaWiki installations as well? we need to be thinking about their threat models as well, as parent5446 pointed out 15:36:40 #action "For a long time, MediaWiki" needs to be more specific 15:36:48 zwol: I think a section like that does need to be in there. I want to think that all the way through. I personally like to take the optimistic approach that security is an enabler, but I know there is a conflict often. And it needs to get resolved at the correct level. 15:37:04 sumanah: hmm, spontaneous thought is "it's maybe not so much WMF vs. non-WMF wiki but it is 'private' wiki vs. public wiki" 15:37:15  (yes) 15:37:18 oh right. Because we do have a 1 or 2 private wikis too! 15:37:18 so a private wiki (which mediawiki was never really made for) also wants to hide content 15:37:28 true, office wiki 15:37:30 #action Section about conflict between security and other requirements, and thoughts on where to address those in the process 15:37:35 we don't want people to read that 15:37:40 nod 15:38:13 hey greg-g - sorry I didn't catch what you were saying yes to? 15:38:36 csteipp:i think it could be made as simple as: whenever a new card/ticket/thing is created with a user story and a requirements section simply add a distinct "Security requirements" section to it 15:39:03  private vs public wiki instead of non-wmf vs wmf, I didn't want to interrupt, mostly ignoring and trusting ya'll+chris :) 15:39:04 as a team you'd have to commit to giving the security requirements the same weight as the other requirements 15:39:06 zwol: greg-g is Greg, release manager at WMF; mutante is Daniel Zahn, an Operations engineer at WMF; phuedx is Sam Smith, who hacks MediaWiki for WMF 15:39:16 every public wiki wants to do something against spam, sooner or later they activate captchas, if the captchas are broken (re-captcha f.e.) that's no good. 15:39:21 hullo o/ 15:39:40 i'm on the growth team with superm401 and halfak 15:39:52 captchas are pretty much broken in general, these days :-/ 15:39:53 well, i guess, halfak's not "on" the growth team 15:39:55 greg-g: phuedx & mutante - zwol is Zack Weinberg, security researcher who has been helping us think about traffic analysis, HTTPS, etc on wikitech-l 15:39:57 as opposed to WMF wikis they don't have an army of anti-vandalists and tools 15:40:11 zwol: hi 15:40:15 phuedx, :P 15:40:17 phuedx: that would be nice.. we can talk more later, but I'd actually love to try that out with a/your team and see what happens. If "n/a" just becomes the automatic response, or if it does provide a good constant reminder. 15:40:20 zwol: hullo 15:40:21 Pleased to meet all of you :) 15:40:21 I'm straddling 15:40:33 zwol: i like to suggest Asirra 15:40:35 halfak: you're a master of bridging 15:41:11 * halfak waves at zwol 15:41:14 #idea bring up 'whenever a new card/ticket/thing is created with a user story and a requirements section simply add a distinct "Security requirements" section to it; as a team you'd have to commit to giving the security requirements the same weight as the other requirements' on https://lists.wikimedia.org/mailman/listinfo/teampractices ? 15:41:34 csteipp: i suspect that n/a might be a normal response 15:41:43 It'd be nice if Phabricator has some sort of security planning widget. I wonder if such an app exists. 15:41:48 but reminders are Good Things (TM) 15:41:54 Yeah, I'm not sure if requiring it on every card is the right approach or not. 15:41:58 #idea It'd be nice if Phabricator has some sort of security planning widget. I wonder if such an app exists. 15:42:09 superm401: we don't need to decide that here & now - let's talk about it on teampractices maybe? 15:42:10 But IETF RFCes do that, and it seems to work pretty well. 15:42:20 mutante: It's an arms race. Anything that gets used as a captcha, suddenly the black hats start pounding on that as a machine learning exercise. I give "is this a cat or a dog?" two years. 15:42:20 phuedx: Yeah, at least there's a chance it will trigger action, vs the current :) 15:43:06 Should we have something about spam & captcha in the security doc? is that what I'm hearing? that one adversary is the spammer, and the threat model & prevention need to be covered? 15:43:15 <_joe_> I may introduce myself as well - I'm Giuseppe Lavagetto, operations engineer as mutante. I'm looking at the PFS implementation on ops side 15:43:25 Solution: just conduct the Turing test. If a WMF staff person thinks they're human, it's good enough. 15:43:34 "PFS" - Perfect Forward Secrecy for those who don't know :-) 15:43:34 mutante / zwol, did you see google's blog about how the captcha system is no longer about getting the right or wrong answer, but it's now a platform where they watch *how* the useragent interacts to determine spam/human? 15:43:43 <_joe_> sumanah: sorry, yes 15:43:57 no prob _joe_ - I am a pathological explainer, that's all ;-) 15:44:01 csteipp: link? that sounds interesting 15:44:05 Speaking of PFS, was that nginx patch merged yet? 15:44:16 Sorry, I'm going off-topic. Nevermind 15:44:21 zwol: i think it has survived more than 2 years, but yea, remember when they talked about Google Labs making the self-learning machine cluster just by feeding it random images from the internet and first thing it learned was to recognize cats?:) who knows, maybe even a hidden pun against Microsoft's captcha ? haha 15:44:24 csteipp: Yeah, I saw that. I'm sure that works great for them because they have dozens of people thinking about nothing else, and giant compute farms to back it up. WM is not so fortunate... 15:44:56 hey zwol mutante csteipp - do we need to talk about CAPTCHA now or should we take that to the talkpage/another time? we have about 15 min left here and I wanted to ask people about giving us the examples we are missing 15:45:13 phuedx: http://googleonlinesecurity.blogspot.com/2013/10/recaptcha-just-got-easier-but-only-if.html 15:45:14 sorry, it's an easy rabbit hole 15:45:17 ta 15:45:25 sumanah: no, we don't need to talk about captcha now 15:45:28 go ahead 15:45:30 sumanah, it already has ConfirmEdit, which equals captcha 15:45:31 like, good & bad examples for https://www.mediawiki.org/wiki/Security_for_developers/Architecture#Secure_Design_Principles 15:45:32 I say move on for now. 15:46:06 sumanah: I think at the architecture level, we need to stress integration with anti-spam. But the exact methods there are going to be very narrow, and probably not applicable to 99% of developers. 15:46:12 Nod nod nod 15:46:54 so, we need a past example of how Wikimedia (doesn't HAVE to be MediaWiki specifically) screwed up on "Secure (fail-safe) defaults" 15:46:56 for instance 15:47:05 And I actually need to leave in about 7 minutes, since I have to catch a 9:03 train :) 15:47:32 ah :) 15:47:39 eh, we just had an example where the new Match captcha was used as a defualt 15:47:43 the other day 15:47:49 can you link at all mutante? 15:48:34 We also need a positive example of how we have done "Simplicity" 15:49:25 sumanah, kind of subjective. Candidates: 15:49:35 1. One markup language (although it's certainly debatable if that one is simple). 15:49:48 superm401: hold on 15:49:59 superm401: I'm talking about simplicity *in security* 15:50:00 Also food for thought: If anyone has a project they would like to threat model, I'd love to do a real example and link from there. 15:50:21 sumanah, I meant that, markup is security-relevant since the parse has to validate/sanitize. 15:50:24 at least, I am. Maybe I misunderstood Chris! 15:50:26 ohhhhhhhh 15:50:30 sumanah: https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm 15:50:37 thanks for unpacking that superm401 :) 15:50:42 No problem. 15:50:42 sumanah, do you mean simplicity in the implementation of security? or are you referring to an internal security module whose interface is simple? 15:50:50 Yeah, sanitization in our language is good... I'm not sure how simple it is :) 15:50:51 * sumanah defers to Chris 15:50:52 see how the default is the MathMath ML 15:51:19 2. Pretty simple user-user email model (no formatting, email is shown to recipient so no reply proxying). 15:51:28 #action csteipp add https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm as a bad example of "Secure (fail-safe) defaults" - the new Match CAPTCHA was used as a default (per mutante) 15:51:29 parent5446: Preferably some place where the simplicity of a feature / internal mechanism / api has kept it secure in the long term. 15:51:30 Or to simplicity in the feature, which reduces attack surface? 15:51:34 Because HTMLForm, while incredibly complex, has a relatively simple interface for security, i.e., built-in CSRF tokens and validation. 15:52:07 I know of examples in the broader environment, but not within WP/WM 15:52:14 #info sumanah: I think at the architecture level, we need to stress integration with anti-spam. But the exact methods there are going to be very narrow, and probably not applicable to 99% of developers. 15:52:37 e.g. the notoriously complicated OpenSSL programming interface .vs. djb's NaCl 15:52:40 mutante, might want to take that offline, but don't see how that change connects to a CAPTCHA (although MathCaptcha uses that extension as one) 15:52:50 zwol: I may ask you for those if our local well runs dry. But my rationale is that the deep shared context of Wikimedia/MediaWiki will help developers grok these examples better and help them emotionally hit harder 15:52:59 makes sense 15:53:13 sumanah, we's always been pretty stingy on allowed file types, partly for security. 15:53:41 superm401: it's not related to captchas, i was trying to find an example where the default value was causing issues for the site 15:53:55 #info "Minimize the attack surface" - we've always been pretty stingy on allowed file types, partly for security. 15:54:20 May not want to put stingy in the actual doc, but yeah. :) 15:54:30 parent5446: I think I'm liking the htmlform example. That shows one side of the issue pretty well. I wish we had something else really simple, but I think we tend to complicate a lot of features :) 15:54:42 :-) CAREFUL. CAUTIOUS. SIDE-EYE. 15:55:04 ok, csteipp I want you to catch your train so maybe we can throw these questions to wikitech-l 15:55:16 Yeah, simple != MediaWiki 15:55:33 Alright folks, thanks for the help. sumanah, can you send me any further conversation? I should get a bouncer one of these days.. 15:55:39 sumanah, https://www.mediawiki.org/wiki/Manual:$wgFileExtensions 15:55:54 sure will do csteipp 15:56:00 example for least permissions, in the past we had our admins::restricted class also on hosts just needed for deployers, nowdays it just gives you bastion access 15:56:03 cya 15:56:52 so "simple" may be Chris's translation of "economy of mechanism" which I will quote from the Saltzer paper 15:56:54 "Keep the design as simple and small as possible. This well-known principle applies to any aspect of a system, but it deserves emphasis for protection mechanisms for this reason: design and implementation errors that result in unwanted access paths will not be noticed during normal use (since normal use usually does not include attempts to exercise improper access paths)." 15:56:57 http://www.cs.virginia.edu/~evans/cs551/saltzer/ 15:58:01 if that helps us get ideas about what we have done simply! HTMLForm and "only 1 markup language" seem like candidates 15:58:45 it could be that there are past good examples where we *did things right* and had a simple, secure design to *start* with, then mucked with things.... 15:58:46 Not sure how great "only 1 markup language" is now that I think about it. 15:58:51 <_joe_> sorry, I've got to leave as well - it's the end of the work day for me. 15:58:54 does anyone want to talk about "Secure and split"? 15:58:59 closely related principle: in API design, the _easiest_, _most normal_ thing to do should also be the secure thing. Sometimes you need to allow people to do something unusual that is less secure, but then they should have to jump through extra hoops to demonstrate (to themselves and to future readers of the code) that they have thought about it and understand the implications. 15:59:04 I agree zwol 15:59:11 #info closely related principle: in API design, the _easiest_, _most normal_ thing to do should also be the secure thing. Sometimes you need to allow people to do something unusual that is less secure, but then they should have to jump through extra hoops to demonstrate (to themselves and to future readers of the code) that they have thought about it and understand the implications. 15:59:31 I can provide tons of external negative examples (starting with, of course, SQL injection...) 15:59:35 #link http://pyvideo.org/video/2647/designing-poetic-apis - the bit about building shoulders for the road is applicable here! http://www.slideshare.net/ErikRose/poetic-apis is the slides 15:59:35 Counter-argument, if it's too common, people learn to jump through the hoops, and ignore them when it's actually dangerous. 15:59:50 E.g. SSL certificate warnings (now people just click through three dialogs without a second thought). 15:59:51 superm401: yes, you have to be sure you understand the use cases 15:59:52 superm401: um, how is that a counterargument? 16:00:26 sumanah, because if they have to jump through the hoops for something mildly dangerous, they don't worry about jumping through them when it's really dangerous. 16:00:31 I understand superm401 to be saying that if a case that you _think_ is unusual and should require hoop-jumping is in fact common, then all you've done is train people to jump through the hoops 16:00:31 anyway, it's noon here which means I'm gonna end the meeting - any last praise for Chris? ;-) 16:00:40 ah thanks zwol - that helps! 16:00:48 and SSL cert warnings are a great example of that 16:00:48 yeah agreed 16:00:52 yuppppp 16:01:55 You and csteipp (and the other contributors) have done a great job. 16:02:05 Got to go. 16:02:13 (and the related "if you ask users to make apparently-irrelevant decisions in the middle of task flow they will ignore everything you are telling them and smack the 'whatever' button" phenomenon) 16:02:13 thanks sumanah, csteipp 16:02:18 gotta go 16:04:41 I'd like to leave everyone with some thoughts from a site called "The Codeless Code" that I find is really good at explaining this sort of thing (if you don't mind a bit of cartoonish violence every now and then): 16:05:02 * sumanah waits for this before ending the mtg 16:05:08 http://thecodelesscode.com/case/148 <-- nominally about caching, but just substitute security and it's the same principle 16:05:30 http://thecodelesscode.com/case/138 <-- why is computer so hard anyway? 16:05:43 http://thecodelesscode.com/case/140 <-- "Code as if everyone is the thief." 16:05:48 -- 16:06:34 Love that site. 16:07:03 OK! 16:07:05 #endmeeting