Making Django Really, Really, Ridiculously Secure (CW) by Kelsey Gilmore-Innis

Speaker 1: Okay, I have I have a uh tradition. I like to take a speaker selfie. Um if you'll indulge me in it in a second, hang on. Okay. Okay, everybody say hi, everybody say Jjango. Okay. Thank you. Kelsey? Yes. Um

Speaker 2: score for the front of that.

Speaker 1: Ah, there's an underscore on the front of that. Sorry. I changed my Twitter to be less discoverable, which kind of goes against the purpose of putting it on a slide, doesn't it? So who am I? I am Kelsey with an underscore in front on Twitter. I am a developer. I am not a security expert. Um my background is in backend development um in Scala for many years and Java before that. Um I joined Sexual Health Innovations uh a little before the beginning of the year to build Callisto. Callisto is, as uh the Adrian's fabulous intro explained, um, a confidential and secure reporting system for sexual assault on college campuses. It is live as of last week at two schools,

Speaker 1: Pomona and USF in California. And there's a lot of things that Callisto does. There's some really amazing UX around it. We've designed a UX that's meant to be supportive and survivor focused and to follow best practices in information design and in interview design, which is its own field, also to surface resources at a campus. for people who've had a victim of this kind of thing. There's a ton of it's that's another talk, all the UX stuff, which has lots of benefits and is really exciting. But data-wise, what's important about Callisto is that it's an information escrow. What that means is that survivors can come to the site and they can write down what happened to them and they can store it securely until they decide what they want to do with that information. This is kind of a new idea.

Speaker 1: You're probably familiar with the concept of escrow in terms of money because you do it often when you have a house. You give money to a trusted third party. Information escrow, you give information to a trusted third party, and then you can release it when you're ready. And um The challenge for us data-wise then is to keep that information really secure while the survivor decides what to do with it. So I'm going to talk to you about what we did to do that, what we used in Django to do that, a little bit about why we chose Django. One caveat I want to put in at the beginning. There is no user uploaded content on this site besides text. So there's no files that are uploaded. Um that would be dragons. If you're doing that, there's a whole host of security concerns that you need to be worried about.

Speaker 1: I'm not going to touch on it. But just so you know. So you can't secure data on the internet. So the Ashley Madison hack was like professionally really bad timing for me. Probably one of the few people who would say that who doesn't work at Astray Madison just because suddenly this idea of data loss is in the news Right, and there's a ton of fear around it, understandably. It was a really scary situation. Um and you know, in in a lot of ways this is true. If someone comes up and tells you that they can have data that's perfectly secure, they're selling you snake oil, right? Uh the all almost all of the practice of security in a big way revolves around being pessimistic. You assume a breach and you work from there. You want to figure out what the breach might be and how you can mitigate it

Speaker 1: That's where you should start from when you're securing your apps. You should have a plan for when a breach happens. You should have a plan for knowing that a breach happened, which is really big. And thankfully, Jacob Kaplan Moss is here to talk a lot about practices and sort of organizational tools you can build around that. So go to his talk and we'll go to the next slide. I think it's in an hour. So that said, right, I am personally kind of frustrated with some of the press around the Ashley Madison hack, right? Because Yes, um data on the internet, there's a lot of security concerns in general with the whole concept of data. But the Ashley Madison breach specifically What we had was a really deeply unethical company doing really deeply unethical things with other people's incredibly sensitive data, right?

Speaker 1: Obviously, you can do things that are reasonably secure on the internet. I assume many of us bank on the internet, for example, which is incredibly uh sensitive information. Many of us use say uh internet connected um health information providing offerings and things like that, right? There are things we can do. And in some ways I feel like this narrative that like That's what you get. If you put information on the internet, it'll be out there. It's kind of a cop-out, right? Because if you look at the specifics of the Ashley Madison hack, the the hackers have actually come out and said We were in there for years and they didn't notice. We were using default passwords from the internet. I mean, you know, their anonymous ha like you have to take all this with a grain of salt, but there's a lot of evidence out there that this was a company that wasn't taking care of their consumers' data. They they've actually said there is no indication of any software vulnerability being exploited during this incident.

Speaker 1: What that means is that people were able to get access to through the same means that other people were getting access. Whether it was because it was an a disgruntled employee, which is what some people said, or they just didn't lock down their stuff. is um, you know, still we don't know and we may never know, but it's important to like be clear that there are ethical things you can and should do when you have people's data that they're trusting to you. So obviously I would say that right because I built this system where you two were taking really sensitive data and putting it on the internet. So Let me talk let me start talking about one of the things we learned and one of the things we did to secure that data and to continue to secure that data. So one of the things that's really awesome about Django is that you totally get a lot For free. Django is is a pretty security-minded web framework.

Speaker 1: They do care about security. They being you and me and the people who comprise Django do care about security. Like one example for an example that I found when I was sort of, you know, I did a lot of due diligence when I was picking the framework I was using because this was a huge concern of ours. Um one example is that passwords are what's called cryptographically agile What that means is so you don't store passwords in plain text. You derive a key from the password or you hash it, right? And Django uses the the the algorithm that is sort of recommended, which is PBKDF2. I don't know what that stands for. Look it up. Um and it's an algorithm that uses a certain number of iterations. It's called a work factor. And the idea being that you can slow it down enough that like Large scale brute force is too expensive to actually crack something, but you can still have that be within the bounds of being usable

Speaker 1: Um that iteration number depends on the power of computer of the computer being used both to generate the password for real uses and to try to crack it. Uh so you want to increase that as computers get more powerful as we know they do. And Django actually not only uses this best sort of Best practice one, but it's built into um as as computers get faster and as the algorithm gets improved. So even if you logged in with an older version of Django and you only used say you know, X number of iterations. The next time you log in, if the developer has updated Django, it'll recalculate in the background and get two X iterations. That's really cool. That's kind of like best, that's like cutting edge stuff, right?

Speaker 1: Not all web frameworks do that So you get a lot for free that's built in just by using Django. You also get a lot for cheap if you can if you do some like basic things that that Django and the ecosystem make really easy to do. So One of those, set your secret secret key correctly, right? Like that that is a basic one that I'm sure you all do. There's also a bunch of basic checks that you can do that take Literally less than five minutes. Um Eric's Pony Checkup is a good one. Django Secure is mid is it gives a management command that lets you run checks very similar to Django's Pony Checkup and you can integrate that into your continuous integration or your build system. By the way, I have a blog post. Don't you don't have to like frantically Google this stuff or write it down if you don't want. I'm gonna uh it's posted on my website But I didn't put it up yet because you're all in here listening to me and not stressing out about looking things up, but I will share it at the end of the talk.

Speaker 1: Other sort of basic checks that we did that were really cheap and easy and got us pretty far was um in two two scoops of Django, which is excellent. The security chapter is almost like a checklist. You can go down and make sure you're doing each one I know I'm not the first person today to rave about Django Debug Toolbar, but you can look at everything that you're sending and getting back and storing really easily with Django Debug Toolbar, and it is so easy to use, which is amazing. Another easy thing that we did was we slapped a CDN in front of our content, which is a content delivery network, and that we use Cloudflare which built provides some DDoS protection, which means that you're not sending every request through. So you get a little bit of like a rudimentary block in front of it. So that's all stuff you get basically out of the box. Like some of those you might have to like

Speaker 1: put in one installed app or like go to a website. But those are all things that you could do in under an hour When you're starting to get into the like nitty-gritty, like the more more serious stuff of um preventing data loss and securing your site. The first step really is knowing your threats. And so you can say threat modeling, because that's the term that's used and you sound like really like elite hacksaw when you talk about Threat modeling. Um which is basic. It's like it's what it says in the name, right? You want to know what info is an attacker looking for and how will they get it, and then what will they use it for, right? Um What this requires is you really need to know your data model and flow really well before you can assess this. And so it's a little bit of a chicken and egg. You can have an idea of what what um attackers might be looking for, but until you feel like you really know where data is coming from and going to in your app, you don't have a good idea.

Speaker 1: So that's the first step of threat modeling is actually system modeling. Which is instructive anyway when you're building uh a site. So it's it's uh it's it's something that you should be thinking about early on in your process because you're already doing part of the stuff that you need to do to keep it secure. For us, for Callisto, we had two aspects that came out during our threat model that are a little unusual from, say, your standard, I don't know, e-commerce website, right? One is that we anticipated this data would be really valuable for specific personal attackers. There might be reason to think that a specific person 's Um report would be interesting to somebody who had the knowledge and ability to do this. We also had reason along those lines to think that an attacker may have access to one of our users' computers or to their accounts

Speaker 1: even. So that was a threat model we were dealing with that you may not be with, that you may not be, or that may be less important to you. And as a result, we really we um put some more focus on looking at things like brute force attacks, for example. If someone knew close to the password or elements of a password that someone was using. You know, again, like if I know your dog's name, I can probably get into your email, like that kind of thing. Um Also, session-based attacks. We want to make sure that uh we're operating in a college context and we had the user research we did indicated that there are a lot of shared computing resources that get used. Um so making sure that our sessions were really well locked down and that people weren't accidentally exposing stuff. Another um threat for us or a threat factor for us that you probably won't be dealing with depending on what you're working on

Speaker 1: is that we um not only anticipate but frankly expect to be subpoenaed at some point for this data because our the user data that we're storing could potentially be a factor in a court case Now that's a really interesting threat model to sort of as a as a com as an engineer, right? To look at your system and to have this threat model that that you can't really Necessarily build a moat around, right? Making the walls taller and it harder to break in doesn't matter if someone is knocking on your door from like the sheriff's office. So that went it, that was a big factor in our design. Um, what we ended up doing with that is we actually store the reports Uh I'm loath to say outright zero knowledge, but the concept is that we encrypt them with a key that's known only to our users.

Speaker 1: This is separate from their password. It's a secret key that they create and put into the website. And we encrypt it and we don't store that key anywhere. We don't have any way to recover it because if you can reset that key, we could then reset it to something we knew and get that information. So this is um This is sort of this came out of our model as an escrow, right? We're just storing this information until the user is ready to use it themselves. So we had the we we were able to build this encryption model that we think will be f fairly safe from subpoena in that if you subpoenaed our data, if you said, give me all the data for this person, we could give it to them, but it would be unreadable. It would just be a blob of of binary data. So that was sort of what came out of our threat modeling process.

Speaker 1: So the biggest threat is in this either in this room or, you know, someone that you know. And what I mean by this is I don't mean like I don't even necessarily mean like what we were talk what I was talking about briefly with like disgruntled employees, although that's absolutely a thing. Um has anyone heard of all crypt? Anyone? Okay. So All Crypt is this story. Okay, I got one. Um All Crypt is this amazing story of this Bitcoin exchange. And they, I mean again, like they were they were storing data that directly impact that was money basically because that's how that works. And they ended up shutting down, this was earlier this year And let me see if I can get this right. They had a technical contractor working on their site

Speaker 1: who was, you know, very technically adept, uh very trained, someone who had an interest in security, but this person was running a private email server on their own machine. And that was how they did all their work email, was on this private email server that only this contractor had access to. Someone, and it's not clear who, by anyone. Someone sent a fraudulent password reset email on their WordPress blog. Nothing to do yet with the Bitcoin parts of the system. Set a password reset for the WordPress blog to a marketing person on the team. The marketing person had been well trained and they had good policies. And the marketing person said, I didn't request this. I'm gonna make sure that this isn't an exploit and forward it to the technical team However, so that private mail server had

Speaker 1: been um had been uh taken over by someone malicious And when the email with the marketing person correctly forwarded to this technical contractor with this password reset butt email came. The person who had who was had access to that private mail server was able to reset the password, get into the WordPress admin, upload PHP files. That gave access to the rest of the machine, which happened to contain the databases that had all of the Bitcoin relevant information. And they stole 40 Bitcoin, which I think at the time was like over $10,000. That is an amazing story. Like Lacey's talk about like, you know, English majors and code, like that's like some Agatha Christie stuff. I love it. But um I bring it up because that's

Speaker 1: that's a team that did a lot of things right and still managed to get totally taken, their shirts taken, right? Um because they didn't really have the right sort of um protocol for their employees. So this really should be something that your your team is cap taking care of. You gotta have good password hygiene. You've got to be tracking all your data including email. You want to s have clean separation of concern from like your marketing and blog and user performance support stuff and your actual business logic. You want to again have strong employee policies and if you do end up having that disgruntled employee situation that you have a way to both detect that and mitigate it. Django specific information in this. Lock down your admin because that's a really that's actually like when people are attacking a Django site, that's the first place they go.

Speaker 1: Change the URL is a really common one that's suggested. Um you can use uh Django Admin Honeypot puts up a fake page there and lets you know if anyone's trying to get in through your fake admin page, your default admin page. I I I would suggest what we decided to do, don't use admin. So what we have is we have a staging site that my coworkers who edit the content can log into and they can edit content there and then I export over to prod when I need to. We don't have a prod admin, so that's one less vector of attack. You also can IP limit it and I have some links for ways to do that. So your second biggest threat though is on the user side I would say, right? Um it's sort of cold comfort if you've locked everything down on your server and code side if your user is either, you know, encouraged to or allowed to make security choices that expose their data, they're not going to make that distinction, and neither will your uh your other customers, frankly.

Speaker 1: It's It's a messaging thing. Um, so a lot of security uh concerns can be mitigated with really good UX, and that was another thing we focused on. Password strength is a big one here, right? So we used um a project that I'm excited about, which is Dropbox. ZXCVBN, which is a password strength meter that operates on a sort of more sophisticated concept of entropy and complexity. This is a really like um password strength and password design is a really interesting and deep topic. There's a lot of of academic and industry work being done on it. I would suggest that if you have a site that people log into, you should read up about this. Like eight or more characters and one special special character or whatever isn't doesn't really cut it, for example.

Speaker 1: And so this is a password strength meter that For example, if, you know, what is the X XKCD example is correct horse battery staple, which is very memorable and long, it's gonna get a higher score on that password meter than password one with an at instead of the a, which is a really common password. Um another thing I like about this is and it's it's also it's a little experimental, but it uses a um It uses a meter instead of just being like low, medium, good. And this is pretty arbitrary, but it actually tells you an estimate of how long it would take to crack the given password. It's an interesting reminder right there what's at stake when you're choosing a password. So that's kind of a cool And we're continuing to explore and to work with folks on password security because we have this unusual password UX, which is like a password that you can't recover, which like is the death knell for UX.

Speaker 1: It's a pattern that you don't normally see Another thing that you want to look at is rate limiting, particularly if you've identified brute force as a potential likely attack vector. So Oh, and there's sorry, I will put on the website, there's a couple Django implementations uh or like integrations of ZXC VBM. That's the last. Row on your keyboard if you're wondering why it's called that. Um there's a couple Jen implementations. We ended up sort of rolling our own just because the UI wasn't exactly what we wanted, but there's a bunch out there. Um Rate limiting. So Django Access is a really common use one. It'll apply to your authentication model. And that one is uh You can lock out users and you can do combinations of users and IP if people are trying too many times a give a password for a given user.

Speaker 1: We also needed to rate limit our encryption and decryption function like entering your secret key. So we use something called Django rate limit, which lets you apply that to various different views. It's a decorator. I, in terms of roadmap stuff that I want to do, I would like to implement exponential back off. So you start even at the first one, putting in a little imperceptible delay. Because with brute force you can expect sort of scripting to attack. Um, and you make it longer and longer as you go, eventually locking out. Another thing that you can do is default to captchas. So you know sometimes people forget passwords, especially in our case where we've got a password that we don't let you recover. So figuring out the balance between security and UX. There's a good one. Another one is session security, expiring sessions after a given amount of inactivity, making sure in general that your sessions actually expire and you don't keep them around forever.

Speaker 1: And there's um a middleware JavaScript combination called Session Security that we use to do that. And it's pretty nice out of the box, and you can customize it all kinds of ways. Another one that we have not implemented yet um or and may not ever but that you should probably look into is two-factor authentication so that's using another piece of information that the user has access to um Often it'll be a text message or an email. Uh we are still user testing it. Um people have a lot of uh sort of they're wary to put their information into our website, which is understandable and we want to sort of reduce friction in terms of registering so we're still figuring out whether that would work at all for us but it's definitely there's a ton of different things and there's now third-party services that will do a bunch of that stuff for you which is really cool.

Speaker 1: So basically boundaries are hard. This is a lesson from my mother. No, I'm kidding. Um so uh um any of what is that you're sending data around when you do that threat model, that's what you want to look at, right? Besides the sort of obvious ones like Is my org got good inf you know information security? And do my users have the tools they need to be secure? Any place where you're sending data across service boundaries or even you know in and out of a DB serializing, deserializing, that's where you want to look at. Looking at where whether you can avoid those kind of uh that data being readable at all or even moving across that. Um we do store some data Compl as anonymized as possible because we want to evaluate the use of our system and also make sure that we can

Speaker 1: provide information to our schools about sort of broad aggregate statistics about what's going on in the climate in campus. We decided to store that in a way that wasn't accessible online. So we have it encrypted with asymmetric uh encryption and we don't put the key online ever. So we have to actually pull that data off and put it on a machine that we can lock down in various different ways you know, and to read it because we don't need it real time. So think about whether you need to cross those boundaries. Another one that's a little um wavier, I would say, is the boundary of your app versus not your app And that's kind of like, you know, we're getting into definitely into user design considerations, but stuff like, you know, if you're storing really sensitive data, like how far away can someone read it off someone's screen?

Speaker 1: Right? Like, yeah, that's not your responsibility, but it's something you can help mitigate. And um one of our big things is when someone actually decides to report, to deliver their report to a school. We then have to get it into an admin's hands, right? So that's a big data boundary for us. And we think we have a reasonably secure process. It involves asymmetric encryption. PGP. Um what that means is I'm teaching regular people who are university admins to use PGP. Which if you've ever, you know, done IT support for university or used PGP, you might be like horrified right now. And like it's it is a really difficult thing you exercise. wise and this there's different solutions we could do to make that easier. But you know, we talk to people and what they're doing is they're taking these reports and putting them into their student conduct tracking systems.

Speaker 1: And if we can figure out, and this is our goal, to integrate with those We 'll have much more s control over that boundary in its one less spot. Okay, I have just a few more slides. This is like the number one security thing I learned and like Don't get cute. No new crypto. Look for audited libraries. Look for libraries that have been around for a long time. You don't want to be the first user. You don't want to be the zero-day pioneer. We're using PySalt, which is a wrapper of a very well-regarded C library. And another thing about this is you want to be able to tell your story to people. And this is actually a big part of security, is getting people to trust your security. And the more complicated that is, the harder that is. So Finally, pay someone smarter. This is a really good use of your budget to consult with someone. And we did this. One thing I want to point out, I didn't mention any network security. We're hosting on Heroku.

Speaker 1: That is a trade-off for us. because of some of our subpoena issue questions, but we could not afford to hire someone to lock down our networks and our servers. the way that Heroku can. I think this is a really like no-brainer if you're starting with low resources. And I don't want to recommend the specific shops for like a pen test or security review. in like a given talk, but ask your friends if you are looking for this, talk to me because I have a big spreadsheet of stuff we looked into. Finally, I want to thank our security board members who helped us with Um the security stuff, which involved consulting on this, Lee Honeywell, Sophie Haskins, Cena Bowam, Selena Deckelman, Chris Vallisek, Don Bailey, and Django Wise, I want to thank, as I'm sure we all, most all of us do, the incomparable Lacey Williams

Speaker 1: Henshow Friends who helped out were Ben Hughes, Jacob Kaplan Moss, and his team, and Andrew Becker at NCC Group. Ask your friends, we should talk about this more. It's security is scary. And I think that there's a high barrier to entry, and the better we can do to lower that, the better off everybody is. Thank you.