 We had, like, three minutes before we were supposed to start, but, like, who was here for Mike's talk just a few minutes ago? Okay. So this is, like, part two, just when you thought it was safe to go back on the web. Yeah, so Mike, you know, he covered some specific problems and then, like, some breaches that have happened. And when I... This was, like, you know, a week ago or so, I saw, like, I knew he was speaking and I've known him, we used their product. So I sent him an email and I was, like, hey, actually, your talk sounds really similar to my talk. You're, like, talking about breaches that have happened and I thought I'd go through some real things that have been found. And I was, like, here's my list of things that I might talk about. Does this conflict with anything you're talking about? And I couldn't believe it. He wrote me back and he's, like, I'm not talking about any of those. Although he did kind of lie because he mentioned Ashlee Madison, but he didn't really talk about it. So if you were in that talk, this is kind of, like, a similar talk except sort of the details of vulnerabilities that have been found in different people's sites. So if you were... In case you were curious about this topic versus that talk. Also I just like to talk, so when I get up here I like to talk. We have one minute before we're officially supposed to start. I like to use vacation pictures now for my title slides and this is Meteor Crater in Arizona. It's actually the first crater that, like, anyone actually figured out came from a meteor. In fact, for a long time they thought it was, like, a volcanic thing. So yeah, this is, in case you're wondering, it's pretty big. I don't remember exactly how big, but it's pretty big. There you go. No, no, it's not that big. Well, so you would have to have detection, right? And then you would probably have to have some way of avoiding it or deflecting it, right? All right, so I should start the real talk. My name is Justin Collins, at President Beef on Twitter and most of the internet. Wanted to give this talk. I've actually heard people say phrases very similar to this. In fact, I heard at least one person say it this week. Not quite like, you know, I believe Rails is going to do everything for me. But sort of that question like, well, but isn't Rails pretty good at security? Doesn't it kind of do a lot of stuff for me? And so I thought it was a good title for this talk. And so the question is, doesn't Rails take care of security for me? The answer, no, it doesn't. And that's all I have. Thank you. This is, I would have put up pictures of my cats, but everyone does that. And mine are not as funny looking as Aaron's. So here's my turtle instead. Okay, so some more detail as I would guess. I hate doing these slides, but it's somewhat relevant. I believe Snapchat shows you your soul. So this is what my soul looks like. I've been doing application security for about six years and working on Breakman open source project for essentially the same amount of time. Last couple years working on Breakman Pro, if you just need to be more professional about your security tools. If you really like Breakman, but you don't feel like you need the pro version, but you want to support Breakman, you can buy licenses for Breakman Pro. And you don't have to use them, but you can buy them and that will support the open source project. Okay, so that's all I'm, that's the sales pitch. Okay, so this talk, I already kind of told you what it was, but if you're looking for what Rails does give you and what Rails does not give you, I gave a talk last year, that was the vacation to the Grand Canyon about like kind of the security things that Rails does well, things that doesn't do well, things I wish it would do better. And then Brian Helmkamp, a couple of years before that, gave a talk about Rails insecure defaults, some of which have changed in the meantime, so that's good. So if you're interested kind of in that topic, which is not what this talk is about, you could watch those. Like in between those two talks, I did a talk with Aaron Bedra and Matt Konda, where we kind of did like a hypothetical scenario where we acted out like, oh, we're developers and like we wrote really bad code and like these are all the things that are happening because of it. And I don't know how well that went over, but this talk is kind of like that, except this is all real. And these all come from public disclosures, mostly from bug bounties, sometimes from people who didn't necessarily get a bounty out of it. I'm not picking on these companies at all. I like most of these companies and I'm sure they're great, especially Twitter since I work there. But these are just like the well done write ups that I could find so that I could share with you sort of the, not just like, not to pick on Mike, but like not just like there's SQL injection, but like what actually happened. And none of these are things that Rails will save you from, essentially. Okay, let's start with Twitter. Like I said, I work there, so I feel like I can share this. It's public anyway, but just letting you know I'm not picking on them. Okay, so let's get into it. The researcher was looking around on our ad site and he noticed something that when you put in a credit card and we check it and we go, oh, that's not a valid credit card. You get this little modal and it's like, oh, you know, we weren't able to approve that card. And then you have two options of what to do with it. One is try again and the other one is dismiss. And he noticed what happened when you hit dismiss, there's a method that gets, or a URL that gets hit and you can see there's like the account ID and this is actually the bug bounty researcher's account. And then payment methods handle failed and then an ID. So I'm starting off the talk. This is a Rails app we're talking about and so you know that thing at the end is probably the ID for the payment method. And he noticed what would happen is the payment method would go away, right? So he's looking at this number. He's thinking this is probably the ID of the payment method. What if I just like changed it? Does that still work? Is that gonna delete that payment method? Well, it turns out in the back end there was code that looked something like this where it looks up the payment method from the ID parameter and it deletes it. I still think like when I was making these, I'm like that's so weird that dismiss deletes it but that's another thing. So this is exactly what was happening and in the sort of web security world this would be considered an insecure direct object reference to direct object reference because that ID is the row in the database and it's insecure because we're not checking that the person who's deleting that row actually owns that row. There's another term for this exact thing right here which is an unscoped find and I don't think I came up with this term but then I searched and it doesn't seem like anyone else uses it but in Rails you can scope your finds or you could not scope them or you could unscope them so this is kind of like a find that wasn't scoped properly. So the way you should do this is to scope it to the current user and then do your find for the payment method and then delete it. Okay, so for this we paid out $2,800. I'm fairly certain that was our largest bug bounty payout to date, why? Because someone could delete all of our customer's payment cards and that's how Twitter makes money. It's from people paying for ads and you can imagine that would be a huge loss for us. So thankfully they reported it to the bug bounty, we paid them $2,800. All right, next up United and I put the links for later if you wanna read the write-ups from the people who found these. So in this case there's a guy, United launched a bug bounty program kind of famous because they're like we'll reward you in reward miles which is kind of not a lot of companies give you that but then you have to fly United. So anyways, he was looking and what he was doing, he was just proxying the traffic from the mobile app just to see kind of what was going on and he noticed there was a request. Is that on the screen for you? Oh sorry, it's a little bit off. The details don't really matter. It's making a post request, I cut out some stuff but he noticed in the request there's MP number. So United they have mileage plus or something like that. Yeah, okay, I don't fly them. So mileage plus number and he thought, oh that's kind of like my user ID. What if I change that? You might notice a trend here, right? So he's just like, what if I changed it to someone else's number? What would I get back? And he got back a whole bunch of information and I know this is kind of small but I'm gonna zoom in including what flight they're on or what flight they're booked for, their name, where they're going, is it late, when's it coming, when it's going? Every leg of the trip, there was a whole bunch of more information. Well he noticed in particular there's a record locator and there's a last name. Any guesses as to why those might be important? Yes, exactly. So what do you do when you check into a flight? What do you do when you need to look up a flight and you didn't create an account on the airline's website? You put in your record locator and your last name. So the reporter who found this, and you can kind of see that, he noticed that yeah, you can go on, all you need is that number and last name and there's a list here of all the things you can do, look at your reservations, change it, cancel it, get a receipt. Another thing he mentioned is you can see the person's emergency contact information, so whoever they put in for their emergency contact, you can see that. All you need is a confirmation number, last name. And you can look that up for any mileage plus member number. So that's pretty bad. There was some drama because he reported it to them and they didn't fix it for a long time and then he threatened to publicly disclose it and then suddenly it was fixed and they're like, no, no, no, we were working on it the whole time and by the way, your report was a duplicate so we're not giving you any money, which happens a lot in Bug Bounty and being on the other side, it just happens but he didn't get any money for that. I guess it was a pretty obvious thing that other people found. All right, Domino's Pizza. I don't eat a lot of Domino's but I seem to recall the name came from them having rectangular shaped pizzas which like, do they even have those now? I don't think I'm that old that you don't remember square pizzas and I do. Not that old for sure. Okay, so again, someone was, actually in this case it was kind of interesting because he was actually looking for something else. He was curious how they generated, apparently sometimes on the mobile app they would give you like a random coupon for $10 off or something and so he was actually looking for that but what he found instead is the way the payment system worked was the phone actually handled the payments so you put in your credit card number, it would send it to the payment processor and payment processors look like this, you just kind of shove your credit card into your laptop screen and then it would send back, okay that was successful and here's sort of the transaction ID or the reference number for that credit card transaction and then the app would send it to Domino's with your order and then they would make your order for you so he thought, right and if there's a failure it just doesn't send it to Domino's, right? So he thought, oh yeah I gotta tell you there's some XML ahead if you need to avert your gaze it's fine. It's not that bad though. So this is what would come back from the payment processor if it failed, let's say not authorized and then there was a reason, it was declined and then a status number and we assume seven means declined for some reason. So he thought, what did he think? What if I changed it, yes, catching on. What if I just set that to success and as far as I know he didn't change anything else just change it to success and then I'll send that on to Domino's. So it kinda looks like this, it failed but we're gonna just change that to success send it to Domino's and then he had no idea if this would work of course. So he checked his app and he sees, well it says they're working on it but you know how mobile apps are, maybe it's just like a UI thing or something so he called them and said, hey did you get an order from me and they're like, yeah we're working on it and we're gonna, we'll get it to you 30 minutes, whatever it was. And he felt kinda bad about it, he felt kinda bad about it so he did pay for it, like when the guy showed up he was just like, oh I think there was a mistake, like here's the money for it. So he didn't actually get a free pizza out of that. But in this case it's simply that the server didn't check that what the client told it was true. It had the reference number from the payment processor, all it had to do was ask the payment processor, hey I got this ID, was it successful? If they had just done that validation, no problem. And so a theme in the security world really is that you shouldn't trust anyone. And I was thinking about that because I thought I would just tell you don't trust anyone, but when you're building an application you actually do have to trust some of the things that are sent to you, right, depending on where it comes from. So the main thing is you need to know, think about who you're trusting and what you're trusting and if you should, right? So unfortunately you can't just trust no one. All right, so talk about Ashley Madison. I included their motto or tagline here because I think it's like a total logical fallacy. Life is short, so have an affair. It's like, well, life is short, so make your life even worse by ruining it. So they had a whole bunch of information stolen. I don't know how it was stolen. I'm not talking about how it was stolen. But part of what was stolen, database dumps and source code, but interestingly, not just source code, but Git repos, which is very interesting, right? It'll become apparent in a moment why that's interesting. So in that, about 36 million passwords, however, they were hashed with B-crypt, which is maybe not like top of the state of the art, but pretty much recommended use B-crypt with a decent work factor, which they were doing. So that was good. And at the time, not that long ago, but at the time, a lot of people were like, oh, okay, we gotta start like trying to crack the B-crypted hashes so we can get the passwords. But there was a group that took a different approach. I gotta warn you, again, even worse than last time, there is some PHP code ahead, but it's not that bad. I think you will survive. I almost rewrote it in Ruby, but it was actually kind of longer and I wanted to fit it on. So they found some code and it's calculating this login key and we actually don't care what that was for. All we care about is the login key was in the database associated with a user. So they saw this code and they say, okay, well it's an MD5 hash, that's a red flag. It's got the username and it's got the password in it. And for some reason, they're lower casing both of those which just makes this whole thing worse. But they're encrypting it first. So now we're dealing with the hash of a B-crypted password so that's not very useful if I'm trying to crack the passwords. So then they looked in the get history and they found that this code used to look like this. So it used to just hash the lower cased password directly. So that was pretty interesting because they knew the username and they knew the login key and they know how it's constructed. So now you can calculate, I believe it's billions of MD5 hashes, like a second. So this was a good place to start. There was another piece of code though and here LC means lower case where they were doing, and weirdly this was also to calculate a login key so who knows what was going on in the code base. But in this case, they had username, password, email, and then this secret key. But remember we have all their database and all their source code so the key is not secret, username's not secret, password's not secret. The only secret is the password. So this was another avenue that they decided they could use to try to crack these hashes. So they started doing this. About two and a half million passwords were cracked. They didn't say exactly how long, but they said in a few hours they had this. And remember there were all these other people who were trying to crack the B-crypt password, which would probably take years and years and years. So in a few hours they had two and a half million passwords. In a few days, I didn't follow up with all of it, but the second post they did, they said they had almost 12 million passwords that they had cracked. To be fair, and I don't have a link to that post, but you could probably find it, most of those passwords were pretty awful passwords. So I think this is an interesting story because they were doing the right thing. They were using B-crypt for storing their passwords. But then on the side they were doing something with a much weaker hashing function. And that led, I mean, I guess I should say, researchers and attackers to be able to crack the ones that were using the much stronger hash. And if you're paying attention, yes they were lower casing the password, but most of the passwords were a lower case. But as the researchers were cracking them, if they found a hash that worked, then they would just try a few iterations of different capitalization, and they could pretty much get it fairly quickly. And then they compared those to make sure they compared those with the, they could calculate the B-crypt hash, and so they could be like, yeah, these are actually the passwords. So don't use weak hashing algorithms. I know this example with the picture is not actually a hashing algorithm, but it's the idea, right? You're trying to hide something and you kind of feel like you hit it, but you didn't really. So just avoid using MD5, avoid using SHA-1. Use SHA-256 for this kind of thing. Well, not for passwords, but for things other than passwords. All right, Facebook. This one will be really quick. So you want to reset, or you forgot your password on Facebook. So you go in and they say, okay, we're gonna send you a six digit code. You type in the code, we'll reset your password, or actually I don't know what happens after that, but we'll get you into your account. So six digits, how many possibilities is that? Yes, very quick, one million. So that's actually a reasonable number to just try all of them. So a researcher for bug bounty and probably other security researchers, the like forgot password flow is often a weak point in websites because you're basically saying, I don't know the true credentials that I should be using to get into your site, so give me some other way to get in. And a lot of times there's flaws in that. So he's looking at this and he hit it and I don't know how many times he hit it, but it was rate limited. So he's like, oh, okay, that's expected. But then he went over to another site that he happened to know about, which was Facebook's beta site. Well, it just happens to turn out that they did not have rate limiting on that site. So essentially, for any account that he knew, the username, email, or phone number, he could get into their account because he'd just request the code. It doesn't matter what the code, wherever that went, it doesn't really matter. And then you just sit there trying at most a million times in the absolute worst case, which you could do relatively quickly, especially compared to trying to brute force a password. So in this case, it's just straight up missing rate limit. Should have been a rate limit, there wasn't one. And interestingly, this is probably the simplest of all these examples, and yet he got the most money because the impact is, well, gee, I can get into anyone's Facebook account. So, does anyone know how to pronounce this? So I say imager, I don't know. So imager, you upload photos or whatever, and people look at them and comment and upload or whatever. I'm saying that very casually, but I spend a lot of time on this site. Anyhow, they have this functionality where you can give them a URL to a video, and then they convert it to a GIF. I gotta be honest, I'm a real introvert. I don't talk to a lot of people, so most words I only pronounce in my head, and then I have to get up and talk about something, and I say GIF, I'm sorry. So in any case, you point it at a video, like YouTube or something, and it will convert it to a GIF, and then you can show it on the site, right? So a researcher was looking at this, he noticed how it works, it hits some endpoint, and it passes in a URL, and then it goes and fetches that URL, of course. I mean, it's pretty simple functionality. Something like this, so you give Imager a URL, and then it hits it, like maybe Bitly or something, and this is called server-side-request-forgery, because you're basically asking a server, like Imager servers, to go and make a request to another server, essentially on your behalf, and you can use this for things like denial-of-service attacks, or any kind of attack where you'd kinda like to hide behind someone else, or maybe they have way more bandwidth than you do, or maybe they have a trust relationship between the servers that you don't have. But that's not exactly what this is about. So the researcher was like, what if I changed that? What if instead of HTTP, I use SFTP? And I'll just set up a server, not Bitly, but I'll set up some server where I can see the request that comes into my server and just see what happens. So I set up using Netcat, and he's like, just listen on this port, see what comes in. One of the things that came in was, hey, I'm coming to do my SFTP or whatever. First string that comes in is like, oh, I'm a lib curl, and this is my version number. That's pretty useful information. And so what he did was he basically started trying all these different protocols, and essentially, whatever you gave it, it would just go and do. And I didn't go through the whole example because from a security point, it's not that interesting, but if you go read the post, which again I linked, and of course the slides will be available, he set up a server that it would hit with, I think it hit it with SFTP, but then he redirected them to a gopher URL and tricked them into sending an SMTP request to another server. So he was actually using them to send mail through, I think it was mail.ru. So it's just like kind of a over complicated example of what you could do with it. The main thing is you can make these requests, and essentially use them as a proxy. You got $2,000 for that. And I don't think I put the slide, but basically, if you're not expecting to make these kinds of requests, you should be checking that you're not making these kinds of requests. So you got $2,000 for that. All right, last example, and I realize this is also Facebook, I'm not picking on them. So this came out a little bit ago. There was a lot of drama around it. I'm not gonna talk about the drama or the causes or who may or may not have been at fault. Just gonna talk about what he did because it's just such a really interesting example of going from having some little bit of information, research, well anyways, why did I have to tell you? I'm gonna tell you what happened. It's just a very interesting chain. So he's a bug bounty guy. He's a security researcher. Someone tells him, hey, I saw on Instagram, they seem to have some kind of admin panel that's on the internet. That's all I really know about it, but maybe you can check it out. So he starts, he goes, he starts looking around like, what is this? Whatever, he ends up on GitHub and he notices that this admin panel is actually open source. And you may not notice something, which is this is totally a Rails app, right? We're at RailsConf, I'm bringing it back. Started with a Rails app, ending with a Rails app. So this is a Rails app. So he pokes around, there are well-known issues with the Rails apps, right? And he finds this. All right, so you're well aware. So he finds the secret token and honestly, like, is it bad that this is here, yes, but if you're, probably the point to take away here is that if you're using an open source Rails application somewhere in your infrastructure, you should go and change this value, right? Okay, so he sees this, he's like, well, that's pretty good. And also, this is running Rails 3214, which is, I believe, from 2013. So pretty old. And he does some more research, it doesn't really matter, because we know in this room that Rails 3.2, the session cookie is signed, but it's code that has literally been marshaled to a string, but it's signed. And usually the signed part is kind of what keeps us safe, but he has the signing key. And when you un-martial code, it's possible to execute code. We're probably, if you've been around for a couple years, you probably remember 2013. So session cookie signed, marshaled code, and if you have the signing key, you essentially have remote code execution. Now, if you read his blog post, I actually got a little confused because the exploit he used was for Rails 3211, or no, no, 32110, which was supposed to be fixed in 3211, but then he used it on 3214, so I have no idea what that means, but I'm just letting you know. But in some case, however he did it, he was able to create a forged session, server accepted it because he signed it with the correct key. They hadn't changed it from the open source repo, and he got a remote shell on the box. So at this point, honestly, he was done, and again, I'm not talking about the drama, but this is where it begins. So he has the remote shell, that's awesome, but what can he do? So he decides, well, there's a database for the web server. I'll just connect to it through my shell and see what's there, and what is there? Passwords are there, that's awesome. However, they're re-crypted, okay. Now there isn't like an MD5 bypass this time. Instead, what happens is he's like, well, whatever, I'll try cracking them anyway. Long shot, but I'll just try it. Well, like jackpot. Six of the passwords were just change me, so probably someone set up an account for someone, and then they never changed their password. Three of them were the same as the username. Two of them were just the word password, and one was the word Instagram, and which makes me believe probably when he set up his cracking tool, he seeded it with some of this information, right? So that's bad. He logged in just to show that he could, but then he's like, this isn't actually that interesting as a web app. He was talking about like, well, maybe I could like set off some pager duty alerts, but not that interesting as an attacker. So then he starts poking around, and he notices on that box, there are keys for AWS. And then, so he goes to that box, and on that box there are more keys to other S3 buckets. And then he starts looking around, and again, not talking about the drama, but you can see where some drama would come from. He starts seeing like, wow, there's like tons of stuff. Anything you could kind of imagine, I can probably access. And this is all from using an open source Rails app that had the secret token in the source code. Yep, secret in the source code, really old version of Rails. There were weak passwords, which he didn't use for anything except for logging in, but weak passwords. And then the keys were sitting on the servers, which like, how you solve that, like it's, I think that's like the worst, or the least bad thing on this list, really. So he got, he did get $2,500. I don't know if it was worth the drama that he went through. Again, you can read that on the internet. All right, so just to kind of summarize here of, like, oh, I'm sorry, it's kind of off to the side, but things you should do. Okay, so verify that the current user can do the thing that they're asking to do, that they can access the data they're asking to access. And I want to point out that, like, this is not just like from the web browser, necessarily. If you're in like a service-oriented architecture, you got to think about that too, because again, think about who you're trusting, think about who they're trusting, and never trust the client. So think about those trust relationships. Always try to use strong hashing algorithms. And I know, like, there's a strong temptation when you're like, well, this doesn't really matter. Like, I'm just using it for this, or like, I'm not really hashing their password, or something along those lines. You can use SHA-256, it's like super fast and strong. So just use that. For important actions, like logging in, confirming codes, any kind of action that is either someone can brute force something, or even if it just causes you financial loss, put a rate limit on it. Don't put your secrets in your source code. And it's kind of a hard thing, because you're like, well, but my source code's right here, and then like, well, where do I put my secrets, and so on. The thing is, if you have someone steal your source code, which happens because it happened to Ashley Madison, you don't want to have your secrets right there in the code. And certainly don't put them on GitHub, which it happens like all the time. So if you just don't have them in your source code, it's just not a problem. And then finally, you know, this is, I know it seems like such generic security advice, like always use strong passwords, but think about it when you're at work, and they're like, oh, we just set up this admin panel and like, you know, here's a password or whatever. What if that admin panel ends up on the internet? You don't want to be the person who's using the password password. You're not gonna feel good when your security team comes to you and says, by the way, someone just logged in with your account and your password was password. It's not a good time. Okay. People always ask about resources. I know people were asking Mike. He probably actually knows better, but if you're like totally new to web vulnerabilities, check out the OWAS top 10. It is a good list. It's very good reference. If you're looking for like, what should I do as opposed to what should I not do? There's a new OWAS top 10 of proactive security controls, which sounds very formal, but actually the documentation, it's very good to go through and it tells you things like think about who you trust and you know, protect stuff and encrypt stuff. It's just kind of like a good checklist to go through. If you're looking for like hands-on trying stuff out, the last two are actually from Invisium, but Rails go to an OWAS project. It's like a purposely vulnerable Rails application, but it also gives you like hints of like, maybe you should try this or that and if you really want to, it'll walk you through things. So it's a good resource. And then also Invisium has these sec casts which you do have to sign up for, but they're free and they're a pretty good resource for Rails security and security in general, both on like sort of defending against things and also trying to hack into stuff. All right, okay, so made this slide. So like I believe almost everyone at this conference is packing stickers to give away. So if you would like one of these three, I have them with me. After the next talk, we're gonna have a security birds of a feather. I don't know where the, does anyone know where those are? Say that? Oh, the lunch room? Okay, so, okay, great. So it's in the lunch room zone A right after the next talk. So if you wanna come and talk to us about more of this stuff. And if you live in the San Francisco Bay area, well, not if you live there, but if your company lives there, feel free to contact me if you want me to come and talk at your company. I'm happy to do that. And this is where you can find me on the internet. Thank you. Yeah, so the question is, aren't those bug bounty payouts kind of low? And there's like, I can talk forever about bug bounties because it's a hard thing. Like what are things worth? And I mean, yeah, maybe you think it's low. Maybe they think it's high. You have to also consider like, what's their budget for bug bounties? Of course, Facebook has a ton of money, so. And yeah, I mean, the guy, the other guy that did the Instagram thing, his whole thing was like, they should have paid me like a million dollars for this. So yeah, it's tough, honestly, because I've been a part of a couple bug bounty programs on the like receiving side. And it's very hard to think through like, what's this worth? How much do we pay? How does it compare to other things that we've seen? And I mean, the thing is like, well, this could destroy our business. Like can you really go to your finance department and be like, we'd like to pay them like half a million dollars. Like no one's gonna go for that, right? Even if it could have wiped out their whole business. Yeah, so the question is, where do you put your secrets? Because someone has to actually use them at some point. I mean, there are products that will do it for you. Essentially, you want to store them somewhere and make sure that only the servers that actually need certain keys get those keys. That's basically the best you can do. And then, you protect that store of keys. And the nice thing though is if you automate all that, then you can rotate them really easily, which is nice. But yeah, you basically just, you gotta put them somewhere and then make sure they're encrypted there and then make sure they only go to the boxes that need them and that access to that. You don't want someone using the Rails CVE that Mike mentioned to read those files, if you can help it. Yeah, so the question is, even when you're doing it that way, how do you securely transfer them between servers? I mean, I gotta say, at some point, you reach a point where you're like, okay, it's safe enough. Because really the main thing is them sitting on servers where they shouldn't be. Or being too widely available. You don't want everyone in your company to have access to the main keys. Of course, when you are transferring them, I mean, you could just use SCP or something and you'd have keyless, I mean, you'd be using SSH keys on the servers. Or I mean, if you want, you can encrypt them and send them over SSH and decrypt them on the box. I mean, but then you have, like you said, the next level, well, but then we have to share the key to decrypt it. Like I said, there are kind of commercial solutions. There are also open source solutions, actually, you can look into, but yeah, honestly, it's just a hard problem. And I think you just have to get to one point where you're like, this is not our weakest point anymore. There's a question over here. I thought, no? Okay, all right, well, thank you very much.