 All right, so I'm Matt, I'm an ATM, the co-founder and CTO of Splice. Splice is a cloud-based music platform for creators, for musicians. And we basically hook into the digital audio workstations, like Logic, or Ableton Live, or FL Studios. And every time people create music, we keep track of all their dependencies, everything they do, and we give them kind of a version control of all that work. And they can see a timeline of their work. They can actually go and see what we call the DNA of the music, so they can go and see all the different parts of the music, they can do inline comments, and they can also share the information with the rest of the world, so they can release open-source music. And we believe that we can change the way music is being created and shared and learned by open-source music at a lower level. And really something behind Splice is the concept of knowledge is power from Francis Bacon. And knowledge is power. This is a very serious quote, people. Be serious about it. So we really believe that, and we believe that we can share that with music, but it's also a hard thing to do if you don't think about security. And this is another quote, security and crypto is really hard. And we're going to talk about that, but before we get into the topic, there's another quote that I really like from my wife, who really likes Barcelona. Unfortunately, or fortunately, she's pregnant. She's actually very pregnant. She's due in just a few weeks, so she could not fly with me, and she was very, very sad. But because I'm going to be a dad again, I figured I should practice not being a dad, but storytelling with you guys tonight. And I figured I should start by the way every story starts, once upon a time. Oh, I forgot about that slide. So the lawyer has asked me to tell you that this is a true story, and the names have been changed, but everything else is correct. So this is the story of Alice and Bob. Alice and Bob are two young entrepreneurs, and they want to change the world, like everybody in California, and probably all around the world. But they're thinking about building a different kind of application to really change the world, and they call the application Abe. Abe is a new kind of social network. It's kind of like Tinder mid-secret, so you have this platform for pet lovers, people who love animals, and you can upload onto the website a lot of the photos of your cats, and the software will find matches for your pets, and then you can go on pet dates with the owners, and you might actually end up finding a mate for you, or for your animal. They also have this really cool feature where you can take two pets, and then it generates a photo of the pet that would get together as a baby pet. That's amazing, and it turns out the application is turning to be very successful. They hired a few developers, but, well, actually, I'm getting ahead of myself. When they wanted to build this application, they had a big question, what technology should we use? And they looked back, Facebook was the most popular social network in the world, and they looked at it and said, well, Facebook is written in PHP. Should we also use PHP? And they asked around, and people told them, now, don't use PHP. Rails is a new PHP. You should use Rails. So, they use Rails. And it turns out the application is super successful. A lot of celebrities start putting the photos online, all the pets, and we even heard, I don't know if it's really true, but I was told that Emma Watson found a new boyfriend because of Abe. So, this is a big deal. It starts bubbling up, and they get more users, but as they get more users, they're also getting into scalability issues. And, you know, especially around image processing and all these things, the bill also is getting pretty high. So, network latency, response time, image processing, all these things come together. And they don't quite know what to do. So, one night, they go to one of these nice hack karaoke nights. You know, it's kind of a night where you spend half of the night hacking on some code, and then you all go sing with your friends. I'm sure all of you do that all the time. And this is where they meet Carlos. Carlos is a well-known, respected, neck-beard programmer. She's also known as Conchita. And she's a low-level programmer who used to write assembly and C, but she recently moved to Go because Go is faster. She's not really into magic, so she's not using Rails. She basically explained to them that she can write a Go API for the image processing that would probably be about 50 times faster, and it's probably worth it. Alice and Carlos dream to become the new DHH. They want to raise cars in the 24 hours of Le Mans. They really dream about it and they're like, we need to hire Conchita. Let's just do it. And the hire Conchita, and the first thing Conchita realizes is that it's not as easy as she starts because she's getting all these web requests from the web, so people are going to the Rails app and they want to go and upload a photo, but at that point she gets the photo inside the Go API, but she has no idea where it's coming from. Like, who is this from? Is it authenticating or not? She doesn't know what to do. So, well, she calls Dave. Dave is a friend from a karaoke night and he's just back from two intensive months of bootcamp training where he learned everything about Rails and about JavaScript. He also paid $20,000, but that's a different story. He knows everything and he basically tells him or tell her, remember Francis Bacon? Knowledge is power. I will tell you the answer and I will not charge you for it. The solution is to use a web session and Conchita is like, well, yeah, I figure that much, but that doesn't help me. It's like, wait, wait a second. I'll explain to you. A web session is just like a hash. You can put whatever you want in it. You send the user back. The user does some other stuff and when they come back, you get your hash back. This is magical. It's like stateful web. This is really great. And Conchita asks, how do you get the information from the user? And Dave says, it's easy. Just call session.currentUser. And Conchita is like, wait a second. I'm not using Ruby. I'm inside Go. How does that work? And Dave answers, well, it's magical. Well, Conchita doesn't really believe in magic. So what she does is that she takes her phone. Actually, she faced time, but we'll skip that part. She calls Frank. Frank has a dark past. Frank knows a lot about the web. And Frank was one of the first developers working on Abe, but he was dating a girl called Eve at the time. And he got caught at Starbucks, hijacking Facebook sessions and stealing a lot of information. So Frank needed up going to jail. Well, he was going to go to jail. And that's not, I mean, I'll just say it. Just don't repeat it. Frank needed up working for the NSA instead. So he didn't go to jail. And nobody was able to prove that Eve was working with him. But Eve got let go. But Frank still has all this knowledge and is a good friend. He also does karaoke nights. And Frank explains, well, it's not that complicated. I'll explain to you. Basically, a web session just uses a cookie. And a cookie is a key value. And the key value is kind of a log box. And you get a log box per domain, per server. And the domain puts this log box onto the user. And the user goes away. And when it comes back, you get the log box. So the server can put whatever information it wants on the log box. And then you get it back. Now, there's just one problem. Is that you're driving around with this log box attached to your car. And you have bad people around. Actually, a lot of the bad people are you on users. If they can, they would change the username, the ID. They would do weird things like that. So to prevent that, what Rails does, and what most web servers do, is that they sign the cookie. They sign the session. So this is a way to prevent... It's a way to prevent people tempering with their data. It sounds very magical, but it's actually not. And Frank goes into explaining how that works. So everything lives inside Active Support. Active Support is a library that's inside Rails. And Active Support has this class called Message Verifier. And Message Verifier, the only job is to sign messages so they can be verified, and we know that the data was not tampered. So how does that work? Well, every single application, as if you were using something before Rails 4.1, you get a secret token.rb file that you might not even pay attention to. And this file has this long string of random characters. And this is the secret. This is what you use to sign everything. Now, the problem is if there's only one key, it might be really easy to find this key by looking at all the encryption. So instead, Rails does something else, and it's called key stretching. So instead of just simply getting one key and using this key everywhere, it takes one key and gets derived keys. And a derived key, it's crypto, it's a bit boring, so I'll try to make it less boring. But basically, we're using a key generator, and we pass the secret, the secret that we will not use directly. We want to derive it. And we say we want a thousand iterations of this secret, whatever that means. What it means is we're going to use a password-based key derivation function 2, not 1, 2. And remember Francis Bacon, knowledge is power. So after the talk, go and Google it. You will learn a lot. But in the meantime, I'll show you the high-level explanation of how that works. So Rails calls a key generator and generates a key by passing a salt. So salt is basically some extra information that is used to make the encryption a bit more robust so you cannot find what the original key was. That's kind of a very simplified explanation. But here's how the function works. You take a hashing function like shall1. You take the secret, that's the original secret we add. And then we take the salt and we add 1. And the result of this function becomes the salt of the second iteration. And the second result becomes the result of the third one, all the way through X amount of iterations that you want to run. And you should do about at least a thousand. Rails does a thousand. It's really the minimum recommended. So you end up with a derived key. Now you pass this derived key or derived secret into the verifier. And the verifier can take an object, like here this hash, and will generate a string that you can put in a cookie or you can send as a param or you can do different things like flash messages and things like that. Now this information is not so magical. It's basically a string split in two. You have the two dashes and you have the signature after the two dashes and you have a dump version, base 64 encoded at the beginning. So if you take this information, the server can look at that, verify that the signature matches the encoding and then can base 64 decode the string and then load it into Marshall to get the object back. And that's how it works. Now there's one thing though. You might not want to expose the session content to just everybody. But let's say you have a session and in the session you have a flag that says, you know, VIP or moron or a knowing user too. You don't want people to see this information. You might want to actually hide. It's safer to hide a lot of this information. So Rails uses also Message Encryptor. And Message Encryptor lets you encrypt and sign your sessions. So we can look at the code. It works the same way. We need to generate another secret. So you don't want to use the same secret. So we derive another one with a different salt. And then we pass both secrets into the Message Encryptor function or method. We get a new instance of this encryptor and we say encrypt and sign by seeing whatever object we want to encrypt and sign. And on the other side we can call encrypt, decrypt and verify. And we'll verify that the signature is right and the message was not tampered with and we'll extract the data back. So this is how a web session works. Conchita is really happy. There's a lot of crypto and math. It seems to be working well. She understands how that works. She can move on with her things. But all of a sudden there's something bad that happens. Big drama. She gets a phone call from Alice and Bob. And Alice and Bob are explaining that something bad happened. All the posicat photos of the celebrities got leaked on 4chan and Reddit. It's all over the web and everybody's looking at them and they're over the press. Now at that point Conchita is freaking out. Like what did I do wrong? Did I do something? Is it my fault? I didn't even write any code yet. Turns out Alice and Bob don't care too much because there's no such thing as bad publicity for them. And they get pretty cool like, hey, everybody's talking about Abe. The signups are going through the roof. Don't worry about it. Also when we fired Frank and Eve, we switched all the servers to HTTPS so we don't think the session was hijacked. Don't worry about that. It's probably something else. Maybe these people, I don't know, maybe they did like Apple and they figured out the password. Maybe the password were 1, 2, 3 or something like that. Don't worry about it. And as they're on the phone, something even worse happens. They're like, oh my God, stop everything. This is so bad. Turns out the entire database is gone. The website is down. The data is gone. Everything is gone. And at that point, this is not fun anymore. This is not like we're getting good press coverage. We got hacked. There's something really bad that happened. So Alice is freaking out. Bob is freaking out. That's not helping much. They don't know what to do. Conchita and Dave just don't even know where to start. What happened? Did they like hack our firewall slash Amazon VPS stuff that I don't understand? What's the big deal here? How did they manage to dump the database like that? On the other side, Frank is pretty impressed. It's like, man, they got pawned big time. I don't know how they did it, but it's very impressive. And this is when we meet for the first time Wendy. Wendy is Frank's new girlfriend. When Frank went to work for the NSA instead of going to prison, Eve left him. She could not handle the fact that he was working for the government. And he met Wendy. And Wendy is a very, very smart girl. And she says she knows exactly what happened. Sorry, I need to take a break now. So Wendy says Eve did it. Eve is the one who did it, and I can prove it. Eve was working on the code base. And Eve had a secret token on the machine because you committed it in the code base because that's the way it works in Rails. And because of that, she was able to generate signed cookies on her own machine because she would put this key running any Rails app on her machine and then she would create a cookie that's signed and it would change the user ID to be the user ID of Emma Watson and she would now be logged in as her and she could see everything that Emma Watson would see and that's how she leaked the photos. She had the cookies that were signed and trusted by the server. However, there's one more thing. You relied on Marshall. Do not trust Marshall. Marshall is a nice guy, but you cannot trust Marshall. Marshall is not such a good friend. It's good to have around, but do not trust him with anything serious. Instead, you should be going for Jason. So Jason is not that smart and it's very simple. It doesn't do much, but what it does, it does it very well. So let me show you, says Wendy, what happened here? She dropped the database, if did, by running a very simple code by using a very simple exploit, which is not an exploit. It's actually normal Ruby code. In Ruby, you can use these hooks into any classes, Marshall load and Marshall dump, and these are hooks that get executed automatically when you Marshall an object. So what Eve did is write this class and she had this function called Marshall load, or this method called Marshall load, and the first thing it does is connect to the active record, list all the tables and drop them one by one. Very simple code. Don't need to do anything when you dump the data, and then we're going to assign it because cool hackers put the name in the hacks so we can find them. Then she put this information in the session, all of that into her own local machine with the right key, and then she copied the session from the browser. She went on to Abe.com, she changed her cookie to use that, and now she's executing whatever code is inside the first method. Now granted, Eve was not very smart because everybody noticed now that the website is done and it's down and it got hacked. If she would have been smarter, she would have found ways of leaking the information, copying the data, like stealing credit cards. She just wanted to mess with them. But you can see that you can execute any code doing that. And this is how you can basically own any Rails server if you have this key, which is why you should not have this key and this is why things got changed in Rails 4.1. You might wonder, am I going to be attacked this way? Well first, you need to leak this key and if you trust the people you work with, it's probably won't happen, but if anybody left or if the source code got released on the web, that might be a different story. But you can verify quickly the serializer. But when he explains, you can actually, if you upgrade it to Rails 4.1, make a big change. And you can basically change the serializer from Marshall to Hybrid. And what Hybrid does is that it will take any Marshall sessions and it will cover them into JSON. Now you could switch directly to JSON, but if you do that, everybody will get logged out. You might not want to log out everybody. Now in this case, you're probably issued, but in your case, you might not want to do that. So you could switch the serializer to Hybrid, give it a month so all the active users get the sessions updated, and then you switch to JSON, everybody who doesn't have a JSON will be logged out and then we need to log in again. Now there's one thing though. Remember, Marshall is all fancy, but JSON is pretty dumb. So you cannot put any kind of complex objects inside a session in JSON. That means no Ruby objects. That means no dates, just very basic JSON structures. When she ties Relived, she understands what the problem is. She actually has a solution for the different applications now because she can rely on JSON. So the first thing she does is like, she restore a clone of the database, get it back up and running. They switch the session to JSON and she's now looking for a solution to connect a Go API authentication mechanism to the Rails authentication mechanism. And lucky enough, she finds an amazing library written by an awesome and handsome developer that does all of that already in Go. And she just needs to use the code and here is how it works. This is Go code. Don't get too, too scared. A tied person structure is kind of like a Ruby class with a few attributes, ID, first name, last name, and age. The thing on the right is called tag and it basically says when you convert it to JSON, use these names instead for the keys. And then let's pretend you want to create a session with John inside the session. You would create an instance of this person, then you would get the Rails secret. So now you need to have the same secret as the one you use on the Rails app. You take the secret, you use the two cookie salts. So Rails uses two salts, one for signature and one for encryption. You can find all that in the documentation. They are not the right ones. They are not fitting on the slide. Once you have that, you create a key generator. You pass the big secret that you have and you do exactly the same thing as Ruby. You derive the keys. You get two different keys. You pass them into a message encryptor and then you can encrypt and sign. You end up with the same string that's base 64 encoded with the dash dash and the signature and you're good to go. On the other side, when you get the session, which is in the case of Kanjita, she's getting the session coming from Rails. She could open the cookie. She gets the information. She takes the string and send it into this decrypt and verify that would do the same thing that Rails does and she would get exactly the same information on the other side. Now what's exciting for Kanjita is like she listened to Evan Phoenix this morning and she knows that to a certain point she's going to have to run services but she also knows that other developers might want to use other languages. They might want to play with other things. More than likely it might not be Rails or it might not be Ruby. If it's Ruby, it's pretty simple. You can use the same code and you can use the active support outside of Rails so you can have a Sinatra API and do the same thing and do all these things. But what if I need to use a Java library? What if I want to use Rust or Elixir or Julia? That gives her a lot of options because now she understands how the session mechanism works and what needs to be implemented to get the same transfer authentication. The website gets very popular. They do an IPO, make a lot of money. Obama ends up posting photos of him and his dog. The Queen of England and her two dogs do that. Everybody makes a lot of money. Kanjita moves on to her next startup. She's building a typewriter, Bluetooth-based typewriter so she can type assembly on a typewriter connected to a Mac. She feels really good about that. Eve, well, she ends up in jail and that's a different story for a different time. Or if you have Netflix, you can watch it directly. Alice and Bob are throwing wild parties all over the world with all their friends. And Frank and Wendy end up moving to the Kingdom of Far, Far Away where the laws around cryptography and reverse engineering are different and they still consult but they have way more fun doing what they like the most. That's it. It's the way to do this with public key. Not in Rails, no. Sorry. It was already hard to actually get the patch in so the story behind it is that I was actually really trying to do like Kanjita to get my session in Go and that's when I was like, I don't want to write Marshall in Go. I started doing it and I was like, no, this is really wrong. I think Evan was like, no, what are you doing? And so I started porting and looking at the code and that's when I realized the exploit and that's what I basically documented it and a lot of people worked on it on making it into a patch and now you can choose the serializer. So technically you might be able to choose a different serializer that would use a different key and you might be able to do a public-private key system. I just didn't try it. More questions? Yeah, I'm trying everything now. Okay, one more so I feel good about myself. I had a cool experience a while ago. So one of our team leaked Amazon key pair that had pretty high privileges in our account. Did you do that during a presentation? No, that would have been cool. I did put good keys on yesterday. About two hours later I realized anyone could do anything from my Twitter account with those keys and I should probably take them down. But yeah, he put them in a public repo on GitHub by accident and he realized straight away took it down, re-based and pushed up a commit without them in. So they were gone from GitHub. About five hours later we got an email off Amazon telling us our keys had been leaked, which GitHub repo it was, and a URL to where they'd found it. So Amazon must go through and anyone from GitHub is here, they can tell us this is some sort of partnership. But Amazon must go through every repo and every push that's put up there, cash it for any sets of keys that they have which I thought was pretty awesome by both Amazon and GitHub to tell us about that. No more questions? Excellent, let's give Matt a round of applause. Thank you very much.