 A tradition, I like to take a speaker selfie, if you'll indulge me in it in a second, hang on. I have to remember how to work Twitter. Okay. Okay, everybody say hi. Everybody say Jenga. Okay. Thank you. Yes. 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. My background is in backend development in Scala for many years and Java before that. I joined sexual health innovations a little before the beginning of the year to build Callisto. Callisto is, as the Adrian's fabulous intro explained, a confidential and secure reporting system for sexual assault on college campuses. It is live as of last week at two schools, 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 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, 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. You're probably familiar with the concept of escrow in terms of money because you do it off 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 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 the site besides text. So there's no files that are uploaded. There will be dragons. If you're doing that, there's a whole host of security concerns that you need to be worried about. 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 it doesn't work at Ashley Madison just because suddenly this idea of data losses in the news, right? And there's a ton of fear around it, understandably. It was a really scary situation. And you know, in a lot of ways this is true. If someone comes up and tells you they can have data that's perfectly secure, they're selling you snake oil, right? 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. 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. And 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, 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? 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 sensitive information. Many of us use, say, Internet-connected 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 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, they're anonymous. 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 consumer's data. They've actually said there is no indication of any software vulnerability being exploited during this incident. What that means is that people were able to get access through the same means that other people were getting access. Whether it was because it was a disgruntled employee, which is what some people said, or they just didn't lock down their stuff is, 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 we're taking really sensitive data and putting it on the Internet. So, 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 JINGU is that you totally get a lot for free. JINGU is a pretty security-minded web framework. They do care about security. They, being you and me and the people who comprise JINGU 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. 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 JINGU uses the algorithm that is sort of recommended, which is PBKDF2. I don't know what that stands for. Look it up. 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. That iteration number depends on the power of the computer being used both to generate the password for real uses and to try to crack it. So you want to increase that as computers get more powerful, as we know they do. And JINGU actually not only uses this best sort of best practice one, but it's built into, as computers get faster and as the algorithm gets improved, you can get increased iterations for free. So it stores it and it'll recalculate it. So even if you logged in with an older version of JINGU and you only use, say, X number of iterations, the next time you log in, if the developer has updated JINGU, it'll recalculate in the background and get two X iterations. That's really cool. That's kind of like cutting-edge stuff, right? Not all web frameworks do that. So you get a lot for free that's built in just by using JINGU. You also get a lot for cheap if you do some basic things that JINGU and the ecosystem make really easy to do. So one of those set your secret key correctly, right? Like 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. Eric's Pony Checkup is a good one. JINGU Secure is, it gives a management command that lets you run checks very similar to JINGU's Pony Checkup and you can integrate that into your continuous integration or your build system. By the way, I have a blog post. You don't have to frantically Google this stuff or write it down if you don't want it. 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. Other sort of basic checks that we did that were really cheap and easy and got us pretty far was two scripts of JINGU, 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 JINGU Debug Toolbar, but you can look at everything that you're sending and getting back and storing really easily with JINGU 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. We use Cloudflare, which provides some DDoS protection, which means that you're not sending every request through, so you get a little bit of a rudimentary block in front of it. That's all stuff you get basically out of the box. Some of those you might have to put in one installed app or 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 nitty-gritty, the more serious stuff of 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 really like elite hacksawer when you talk about threat modeling, which basically, it's what it says in the name. You want to know what info is an attacker looking for and how will they get it, and what is it for, right? 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 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. So that's the first step of threat modeling, is actually system modeling, which is instructive anyway when you're building a site, so it's something that you should be thinking about early on 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 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 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 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. Also, session-based attacks, we wanted to make sure that we are operating in a college context, and the user research we did indicated that there are a lot of shared computing resources that get used, so making sure that our sessions were really well locked down and that people weren't accidentally exposing stuff. Another threat for us, or a threat factor for us that you probably won't be dealing with, depending on what you're working on, is that we not only anticipate, but frankly expect to be subpoena at some point for this data because the user data that we're storing could potentially be a factor in a court case. Now, that's a really interesting threat model as an engineer, right, to look at your system and to have this threat model 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 the sheriff's office. That was a big factor in our design. What we ended up doing with that is we actually store the reports, I'm lost to say outright zero knowledge, but the concept is that we encrypt them with a key that's known only to our users. 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 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 were able to build this encryption model that we think will be 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 binary data. So that was sort of what came out of our threat modeling process. So the biggest threat is either in this room or someone that you know. And what I mean by this is I don't even necessarily mean what I was talking about briefly with disgruntled employees, although that's absolutely a thing. Has anyone heard of Allcrypt? Anyone? Okay, so Allcrypt is this story. Okay, I got one. Allcrypt is this amazing story of this Bitcoin exchange. And they, I mean again, they were storing data that directly impacted, 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 who was very technically adept, very trained, someone who had an interest in security, but this person was running a private e-mail server on their own machine. And that was how they did all their work e-mail, was on this private e-mail server that only this contractor had access to. Someone, and it's not clear who, by anyone, someone sent a fraudulent password reset e-mail on their WordPress blog. Nothing to do with 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 going to make sure that this isn't an exploit, and forward it to the technical team. However, so that private mail server had been taken over by someone malicious. And when the e-mail with the marketing person correctly forwarded to this technical contractor with this password reset e-mail came, the person who 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 over $10,000. That is an amazing story. Lacey's talk about English majors and code, that's some Agatha Christie stuff. I love it, but I bring it up because that's a team that did a lot of things right and still managed to get totally taken, their shirts taken, right? Because they didn't really have the right sort of protocol for their employees. So this really should be something that your team is taking care of. You've got to have good password hygiene. You've got to be tracking all your data, including e-mail. You want to have clean separation of concern from your marketing and blog and user form and 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. Jango-specific information in this. Lock down your admin because that's a really... That's actually like when people are attacking a Jango site, that's the first place they go. Change the URL is a really common one that's suggested. You can use Jango 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 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? It's sort of called comfort if you've locked everything down on your server and code side, if your user is either encouraged to or allowed to make security choices that expose their data. They're not gonna make that distinction and neither will your other customers. Frankly, it's a messaging thing. So a lot of security 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 a project that I'm excited about, which is Dropbox's 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, password strength and password design is a really interesting and deep topic. There's a lot 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 in one special character or whatever doesn't really cut it, for example, and so this is a password strength meter that, for example, what is the 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. Another thing I like about this is, and it's also a little experimental, but 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 it's kind of a cool way, 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. 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 a couple of Django apps that make... Oh, and there's, sorry, I will put on the website, there's a couple of Django implementations or, like, integrations of ZXC VPN. That's the last row on your keyboard if you're wondering why it's called that. There's a couple of Django 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. Rate limiting. So Django access is a really common use one. It's on your... It'll apply to your authentication model and that one is you can lock out users and you can do combinations of users and IP if people are trying too many times a password for a given user. We also needed to rate limit our encryption and decryption function, like entering your secret key. So we used something called Django rate limit, which lets you apply that to various different views. It's a decorator. 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 and you make it longer and longer as you go eventually locking out. Another thing that you can do is default to captures. So, you know, sometimes we'll 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. And there's 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 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. Often it'll be a text message or an email. We are still user testing it. People have a lot of 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. So basically boundaries are hard. This is a lesson from my mother. No, I'm kidding. Any of us 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 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 in and out of a DB, serializing, deserializing, that's what you want to look at. Looking at whether you can avoid those kind of data being readable at all or even moving across that, we do store some data as anonymized as possible because we want to evaluate the use of our system and also make sure that we can provide information to our schools about sort of broad aggregate statistics about what's going on in the climate and campus. We decided to store that in a way that wasn't accessible online. So we have it encrypted with asymmetric 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 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 wavier, I would say, is the boundary of your app versus not your app. And that's kind of like, we're getting into, definitely into user design considerations but stuff like, if you're storing really sensitive data, how far away can someone read it off someone's screen? Like, yeah, that's not your responsibility but it's something you can help mitigate. And 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. So that's a big data boundary for us. And we think we have a reasonably secure process. It involves asymmetric encryption, PGP. What that means is I'm teaching regular people who are university admins to use PGP, which if you've ever done IT support for university or used PGP, you might be horrified right now and it is a really difficult thing UX-wise and there's different solutions we could do to make that easier but we talk to people and what they're doing is they're taking these reports and putting them into their student conduct tracking systems and if we can figure out, and this is our goal, to integrate with those, we'll have much more control over that boundary and it's 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 Pi Salt, 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. That was a trade-off for us because of some of our subpoena questions, but we could not afford to hire someone to lock down our networks and our servers the way that Heroku can and I think this is a really like no-brainer if you're starting with low resources. And I don't want to recommend some specific shops for like a pen test or a 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 the security stuff which involved consulting on this, Lee Honeywell, Sophie Haskins, Sina Barum, Selena Deckelman, Chris Valasek, Don Bailey, and Jenga Wez, I want to thank, as I'm sure we all, most all of us, do the incomparable Lacey Williams Henshel. Friends who helped out were Ben Hughes, Jacob Kaplan Moss and his team, 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 hybrid entry and the better we can do to lower that, the better off everybody is. Thank you.