In this episode of Top End Devs, we dive deep into the realm of security within the Rails ecosystem with our guest, Greg Molnar. Known for his expertise in this field, Greg joins our panelists Valentino Stoll and host Charles Max Wood to unravel the intricacies of security measures and updates in Rails 8 and 7.2. From exploring built-in features like rate limiting, authentication generators, and parameter filtering to discussing the importance of tools like dependabot and Brakeman, this episode offers a comprehensive look at how developers can maintain high-security standards in their Ruby on Rails applications. We also touch on practical strategies for handling authentication, authorization, and the evolving nature of security challenges developers face today. Whether you're a Rails veteran or new to web development, tune in to gain valuable insights into creating secure applications with ease.

Charles Max Wood [00:00:04]:
Hey, everybody. Welcome back to another episode of the Ruby Rogues podcast.

Charles Max Wood [00:00:08]:
This week on our panel, we have Valentino Stoll.

Valentino Stoll [00:00:12]:
Hey now.

Charles Max Wood [00:00:13]:
I'm Charles Max Wood from Top End Devs. We have a special guest this week. It is Greg Molnar. Greg, we've had you on before, but but how are things in the middle of the Atlantic?

Greg Molnar [00:00:25]:
Hi, guys. Yeah. All is good. It's still we are still alive in the middle of the

Charles Max Wood [00:00:31]:
ocean. Yeah. The the island's still upright, so I think things are good.

Greg Molnar [00:00:36]:
Yes. Yes. Yes. Shitty weather sometimes, but, yeah, it's wintertime.

Charles Max Wood [00:00:40]:
I heard a clip not that long ago. It's an older clip, but it was a a US Congressman that, he was interviewing, a a general or an admiral or something. And, basically, he was talking about Guam, and he said, well, are you worried that the island is going to capsize and, the the general with the straight face? Right? Because they have to have some decorum in there, and they don't wanna tick off the congressman. He looks at him, and he goes he goes, no. No. We don't anticipate that.

Greg Molnar [00:01:14]:
But the

Charles Max Wood [00:01:14]:
Maldives So your island didn't capsize.

Greg Molnar [00:01:17]:
No. No. But the Maldives is supposed to be gone for a few years now, and it's still there. Right? So I don't know what are these forecasts about.

Charles Max Wood [00:01:24]:
Yep. Alright. Well, we brought you on to talk about, security in Rails eight. I I don't even know where to start. Did did did a whole lot change, or is it mostly the same as 7.2?

Greg Molnar [00:01:40]:
Well, yeah. There are a bunch of things which are 7.2, but I think the invitation was, triggered by my talk at Railsware

Charles Max Wood [00:01:48]:
Yes.

Greg Molnar [00:01:48]:
Which was titled the state of security in Rails eight. But some of the things I mentioned were actually Rails 7.2, But I think it was still worth mentioning those because a lot of people don't even know about those new features, which were Right. Like, many years old back then. And, yeah, real estate wasn't even it was released at the conference, so it was

Charles Max Wood [00:02:09]:
a bit

Greg Molnar [00:02:10]:
of a a pre planned talk.

Charles Max Wood [00:02:15]:
So, so yeah. So where do we start then?

Greg Molnar [00:02:18]:
Well, I can just list out the things which I was talking about. If you guys are okay, we can go through all of those and you can ask questions and we can,

Charles Max Wood [00:02:27]:
Sounds good to me.

Greg Molnar [00:02:27]:
Check all of them. So one of the first things I mentioned during the talk was, every new Rails app, this is a 7.2 feature. Every newly generated Rails application has a default dependable GitLab CI file, which means if you are using, not GitLab, sorry, GitHub. If you are using GitHub, then on your CI automatically runs dependabot, which is, dependent, vulnerable dependency checks. So if any of the gems you are using has a vulnerability published, then you are getting alerted, and then you can just upgrade and save yourselves from any hassles.

Charles Max Wood [00:03:07]:
And, Sounds good.

Greg Molnar [00:03:08]:
Yeah. I think

Charles Max Wood [00:03:10]:
yep. Well, I I was just gonna say some people I think most people know what depend about is, but effectively, you get pull requests if you have vulnerable versions of your dependencies.

Greg Molnar [00:03:22]:
Yeah. Or even for outdated ones. That's why I don't like dependable actually. I prefer bundle audit, but it's basically it's very similar thing, but bundle audit only alerts you about security issues. Whereas dependable, I think you can configure it dependable also allows you about outdated ones where usually my way of when I work on the rails, my way of handling upgrades is it's like in a regular basis. Like every three months there is like a spike upgrade all the dependencies. But security dependencies are different. Security issues are different, obviously.

Greg Molnar [00:03:54]:
You wanna upgrade them immediately. But the rest, I don't really care when a new gem comes out. If it's just, a non security issue, I will upgrade it when I do my regular upgrade upgrades.

Charles Max Wood [00:04:06]:
Right. That makes sense. I I do the same thing because a lot of times your your upgrades, if it's, major or even sometimes a minor version, it Yeah. You know, it it changes the API. Right? It's not just, oh, hey. You're gonna upgrade this, and you're gonna get security goodies. Right? Now you may have to pull a major or minor upgrade version because because there is a security issue, and they didn't fix it in the version you're using, in which case, yeah, you have to go through the upgrade rigmarole and up update your code as well as the gem. Yeah.

Charles Max Wood [00:04:39]:
But, yeah, I'm with you. I I tend to tackle those things when I feel the need. Right? So sometimes, legitimately, it's like, hey. There's a new feature in this that I need. Yep. But if it's the older version, how do I put this? I I've been having conversations with people about, like, AI and programming, and it's like, hey. Look. It makes you more effective in all of these different ways.

Charles Max Wood [00:05:02]:
And and a lot of people are asking, is that gonna replace programmers? And I'm like, have you ever met a pro have you ever worked on a project that ran out of things for you to work on? And the answer is, you might have had a side project that you decided was done. Right? And so with this, it's the same thing. It's like, okay. Until I it's a real high priority, there's just no reason to do it. And so I'm with you on that.

Greg Molnar [00:05:25]:
Yeah.

Valentino Stoll [00:05:25]:
Yeah. It's funny. I I've been trying to push people to just, like, bundle update patch on like every deploy because like the chances of something going wrong in a patch release is like so low that like you've gained so much more by like all of those security enhancements and like fixes in the patch level version. It's almost worth just, like, doing it if a test pass. Right? Like Yeah.

Charles Max Wood [00:05:50]:
So what does bundle update patch do? Because I've used, like, the pessimized gem that locks in your version. Right? Yep. And lets you upgrade from there?

Valentino Stoll [00:05:58]:
Yeah. So bundle, bundle update tool, it has, like, a a way to give it different flags of, like so it's canonical version to all the Ruby Gems typically are. So as long as the Gems here your dependency using are canonicals, meaning there's, like, a a patch level, a minor, and a major version

Charles Max Wood [00:06:15]:
Right.

Valentino Stoll [00:06:15]:
To it, then you can just say, okay. Give me only the latest, you know, patch updates. And, like, peep I feel like as at least for like everything that Reels would touch, like the gem maintainers of those are very careful about what to release in a patch version to not like cause any issues. Because like they don't want to deal with all the issues that come from that, right? Like I'm sounding like oh hey, like I have like this new like obscure thing, like they would rather just like okay let's make it minimal and then you know in a minor major version like it's to be expected, right? We've outlined these things, it's gone through the process. But a patch version, like, it's like, hey. We fixed this thing as serious. Like, you should really integrate this.

Charles Max Wood [00:06:58]:
Right. So if I have in my gem file just sidekick and I didn't specify a version and there's a major version update, I can do bundle update with patch flag, and it'll just update it to the highest patch version, and it won't Right. Do a major update.

Valentino Stoll [00:07:15]:
It won't do it won't even do the minor. Right? So it will keep it. If it's, like, 3.2, it'll do that and then just, like, bump it to the latest one, which, to be honest, doing that with Rails may be a little trickier, because it does like

Charles Max Wood [00:07:26]:
Yeah, Rails is funny.

Valentino Stoll [00:07:27]:
You know, it has so many patches that get released. So if you like fall behind, but like that's why you're like if you're deploying a lot anyway, right, like then like getting reals to update itself incrementally as it gets updated at a patch level is not going to be so bad. And a lot of times, you know, if you have a good test case, which you know, let's hope everybody does, but like if you don't, like, obviously, maybe you don't want to build this into your deploy process. But, like Right. If you if you have a good, like, test infrastructure, like, doing a patch update, like, it's gonna be almost nothing and you'll catch most of the issues in any of the test files.

Charles Max Wood [00:08:04]:
Makes sense.

Greg Molnar [00:08:05]:
About applications? What if they deprecate things in a I know it's they shouldn't, but sometimes they do, and then your logs are littered with all of the deprecation warnings.

Valentino Stoll [00:08:14]:
Right.

Greg Molnar [00:08:15]:
And then you are like, oh, shit. Now I just have to write a particular

Valentino Stoll [00:08:18]:
I mean, to be personally, I would rather have it be secured than like, you know, worry about all the verbosity of the outputs. Right? Like, I feel like what, you know, yeah, littered logs is not great to deal with but like it's honestly better than the alternative of having like a security hole and then like getting like, you know, pager doo doo

Greg Molnar [00:08:42]:
doo doo doo doo doo doo doo doo doo doo doo doo

Valentino Stoll [00:08:43]:
doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo doo do We need to, like, start an incident response. Right? Like

Greg Molnar [00:08:49]:
Yeah. But that's why you should use bundle audit or depend on what we do security updates because then Yeah. Even though it's a patch release, you are notified that this is an important patch release. You need to

Charles Max Wood [00:09:00]:
Right.

Greg Molnar [00:09:01]:
Do this upgrade.

Valentino Stoll [00:09:02]:
Yeah. So I'm curious what your thoughts are there. Like, is is that the best, like, approach still today is, like, using the audit feature? Like, what is your workflow, like, look like for

Greg Molnar [00:09:14]:
That's what I use. It's running on CI, and it's running also in, development in a git hook. And then it's just you are not dividing the data. And also on CI, a lot of people, what they forget is they set it up to run on the merge request or pull requests, whichever git host they use, but they don't run it daily on, the master or main branch, which is if you don't deploy every day, if you don't merge requests every day, then you might not be notified about an important secretary. So it's good idea to actually the way I set it up, if I have the chance to set it up anywhere, run it twice a day on the master branch and run it on every pull requests, merge requests. Because then you are notified anyways. Also like weekends. So if it's on a weekend, it's not really something on a Saturday, you are not getting notified if you only write on pull requests.

Charles Max Wood [00:10:04]:
Right. And it'll it'll fail the build if if it doesn't pass the audit. Right?

Greg Molnar [00:10:12]:
Yeah. And if it fails on master, but you are not expecting a build, then you will get an email notification or whatever you set up. Yeah. And then you will know that, oh, I need to look into this because something is up.

Charles Max Wood [00:10:24]:
Makes sense.

Valentino Stoll [00:10:25]:
Yeah. I'm I'm just waiting for the day to have, like, you know, reels autopilot. Just automatic like, if you have, like, a bunch of hobby projects that you just, like, oh, like, I'm not gonna spend any time on this for six months. Like, just like automatically merge any updates as it comes and like resolve itself. Like, I would love that and then just come back and then, you know, if when I'm ready to work on it again, at least it's up to date and I could like resolve any issues that there are. Right. But, you know, every single time I go back to a hobby project and I'm like, shit. I can't spend any time on this because I gotta spend the time updating it.

Valentino Stoll [00:10:57]:
And then I lose that, like, you know,

Greg Molnar [00:11:00]:
you should try Dependabot. I think Dependabot doesn't. You can set it It just automatically does it? Yeah. You can.

Charles Max Wood [00:11:06]:
Yeah. You can. Yeah.

Greg Molnar [00:11:07]:
Matches. Yeah. For, for patch level and I maybe you can even do it for minor. Maybe you can do it for every level. I don't know. But you can do it for sure. And then, yeah, it updates everything. Things might break because

Charles Max Wood [00:11:19]:
Right.

Greg Molnar [00:11:20]:
You might not carry it with a test, but there is

Valentino Stoll [00:11:22]:
at least,

Greg Molnar [00:11:23]:
but you never know. I don't know. I don't maybe it's just me that this is why I also don't trust AI. It's I just, I trust humans more for some reason. There is some human oversight. I trust that process like an order of magnitude more than if it's just something wholly automated.

Charles Max Wood [00:11:41]:
Yeah. I think I think it's getting better, but I don't blame you there. Yeah.

Valentino Stoll [00:11:46]:
Yeah. I've I've been, like, in the review process to, like, automate but review. So, like, you know, we'll they'll just, like, set out a plan and then, like, they okay. I executed all the plan and then notify you. Okay. Review this. I did these things. Right?

Charles Max Wood [00:12:01]:
Right.

Valentino Stoll [00:12:01]:
And then if you do, like, decide not to review it, like, okay. Well, that's the same as, like, working with a coworker that did the same thing. Right? And you didn't review it and they did it anyway. Right?

Greg Molnar [00:12:11]:
Yep. Definitely. But also from a human, I expect more than from, so with AI, my, my issue is that I write a piece of code, right? I ask him, can you refactor this to me? It speeds back a bunch of changes, which I need to review. And Right. If I ask a junior developer, can you work on this feature? They work on it. They submit a pull request. And if they are uncertain about some things which they did, they will highlight that. Here's my pull request, but I'm not really sure about this part.

Greg Molnar [00:12:40]:
Can you review that more thoroughly? But AI doesn't do that. It's confidently says this is the solution, and then you are like, okay. It's like 50 lines of changes. Am I gonna focus on each 50 line in the city?

Valentino Stoll [00:12:54]:
You bring up a great point. Maybe what we're missing is a junior AI. Right? Like, that hasn't programmed in, I am not confident. I don't know what I'm doing. And, then it can, you know, be maybe a little more cautious. I think you're onto something there.

Greg Molnar [00:13:10]:
Or evade or evade what it gives you because it can be confident about some parts which are, like, basic or or or it knows it well. But if you are a little bit uncertain about something, highlight that so I can review that more thoroughly. Right.

Charles Max Wood [00:13:24]:
Yeah. The the issue that I run into though is that a lot of times what I get back from AI, I'm I'm not confident that, a, it would flag the right things, or, b, that a lot of times I get code back that it's like it's like, yeah, like, the general structure as far as, like, I have to loop over these things or I have to make this kind of a request or, you know, call into this API is generally correct. And then the rest of it, it's it's it it may as well have written pseudo code. Right? And it's like it's like you guessed at the the method name instead of looking it up, which a human would do. They'd go look it up. How do I whatever. Anyway, we're off on a tangent. I wanna get back to security.

Charles Max Wood [00:14:07]:
So, so the petabot is in there by default. You can, use bundle audit if you want instead and put that into your CI. What else do we get?

Greg Molnar [00:14:21]:
On on the change is really similar. It's Brakeman. It's also got a default CI file. So Brakeman is a static code analyzer for security issues. It basically highlights code spots where you might do something which is insecure. I think that's also a great addition. It gives you false positives. You can ignore those, but it at least makes you aware of certain things and saves you from silly mistakes.

Greg Molnar [00:14:45]:
It's so easy to make a silly mistake, which you don't realize. You use an insecrate, an API in an insecure way because you just forgot about something, and it just saves you from those issues. I think that's also great change or great addition

Charles Max Wood [00:14:59]:
from us. The thing I like about break man is that, yeah, it gives you false positives, but, like, all of the commonly understood bad things you can do or the thing the traps that you'd more easily fall into, it's got all of that in there. And so, yeah, it might give you a false positive and say this is insecure, and you look at it and you go, no. I'm not doing what you think I'm doing, but it catches the really easy dumb stuff.

Greg Molnar [00:15:24]:
Yep. Yeah. Definitely. And the next one is, which is a new feature in this, it's the rate limiting, the built in rate limiter. I'm sure you guys heard about that one. And, I'm

Valentino Stoll [00:15:37]:
really excited about this.

Charles Max Wood [00:15:40]:
I have I don't know how many

Valentino Stoll [00:15:41]:
times But I don't know how many times I've built rate limiting.

Charles Max Wood [00:15:45]:
I've got I've got an app that I want to build to replace a process we went through last year. It's part of my political stuff, but letting people register for our caucus night in Utah. We get we have, like, 900,000 party members that are eligible to attend our caucus meetings, and we got DDoSed last year, by somebody who doesn't like the party. And so, I'm wondering if something like this will help.

Greg Molnar [00:16:14]:
It could help, but it might not have. For a DDoS ed tech, I think it's, you would need something like Cloudfare,

Charles Max Wood [00:16:21]:
which is That's what I'm seriously looking at, but yeah.

Greg Molnar [00:16:23]:
Yeah. So for what this one is good for, the thing this one is good for, rate limiting is save you from credential stuffing attacks, for instance. You know, when there is a leaked password database and then a malicious actors will try to use all of those login details on your side to see if the same person has, an account with the same credentials and then they can take over the account and do whatever malicious things. And in my talk, I highlighted a few examples from a actually now two years ago from 2023, it was the year before, like '23 and Me, the DNA analysis, site, they had an issue with this. Also, General Motors had a big issue. They had a bunch of accounts taken over and, like, credit partial credit card details leaked, and Roku, the streaming platform, also had, like, half a million of their users. Access details were leaked because of our credentials stuff, credential stuffing attack.

Valentino Stoll [00:17:24]:
Right.

Greg Molnar [00:17:25]:
So I think this is a very good addition to us to prevent all of these issues. We already had a rack attack, which is a gem. It's a very old gem, but a lot of people don't know about that. And this is why I really like these changes in rails because once it's in rails core, a lot of people are becoming aware of these issues, which they, these tools solve, and it might not be the best for that team or that person, but at least now they are, oh, I need to think about cutting into a staffing.

Charles Max Wood [00:17:52]:
Right.

Greg Molnar [00:17:52]:
And then they find a solution which works for them.

Charles Max Wood [00:17:56]:
So is this in rails seven two or is this in rails eight only?

Greg Molnar [00:18:00]:
It's in rails seven two. It got some improvements, which only landed in rails eight.

Charles Max Wood [00:18:05]:
Okay.

Greg Molnar [00:18:07]:
And it's really simple. You add a single line to your controller, and you just set the you said that the two parameter, which is how many requests you want to allow, and you set the within, which is like the timeframe. Let's say you want to allow 10 requests within 10, within three minutes from the same user, and then that's it. And then you have rate limiting. You can also configure which actions you want it to be called on. It's like a before filter in the controller. You can set if you want to exclude any actions or if you want to include only certain actions. You can also configure a custom response because by default, it raises a four two nine header, and then you can change that and just redirect your page, display a message, or whatever you want to do.

Greg Molnar [00:18:59]:
And also another important thing to mention, initially when the first implementation used Redis, but then it's been rewritten, and now the storage, the back end is any Rails cache compatible storage can work. So you can use the solid cache or whatever you want, and you don't need to be you don't need to have Redis as a dependency.

Valentino Stoll [00:19:25]:
I love that. I love

Charles Max Wood [00:19:26]:
all the moves away from Redis.

Valentino Stoll [00:19:28]:
The storage patterns, across the board are just really great to see it become more cohesive. Yeah. I I really like this, byline too where you give it a proc and say, like, hey, you know, rate limited by IP or whatever you wanna filter a scope to.

Greg Molnar [00:19:45]:
Yeah. If you would want to have something like CloudFlare, you could achieve that using that parameter. So you would set a cookie, and then you will basically buy that cookie and then you can handle more, properly a DDoS attack as well. Otherwise, if you do it by the IP, a DDoS is usually they use a whole range of IP addresses. Right. It's one client. So if you set a cookie on that client, then you can identify it's the same client from a different IP. Yeah.

Charles Max Wood [00:20:14]:
I I I'm liking where this is going for sure. I think cloud CloudFlare is probably the best answer for what I'm looking for. But I like this to manage your credential stuffing and things like that.

Greg Molnar [00:20:27]:
Yeah. My only problem with Cloudflare, I love them. They are really cool. It's very cheap, but I think now they are swallowing a big part of the Internet. And maybe one day they will say, okay. Now we are greedy. Now we start to call an extortion amount on everybody. Let's hope they never do this, but it happened before.

Greg Molnar [00:20:49]:
Yeah. And they might say, yeah. Now we want all the money, and now you rely on us. There is nowhere else to go. All the small competitors are gone, and they need to pay us a lot. But let's hope they are not gonna do that.

Valentino Stoll [00:21:04]:
Yep.

Greg Molnar [00:21:07]:
Cool. And so the next thing I mentioned in the talk was the new authentication generator in Rails.

Valentino Stoll [00:21:14]:
Oh, I love this.

Greg Molnar [00:21:16]:
Yeah. Well, we had another one before. It's called authentication zero, which is Uh-huh. Wasn't in Rails. It was done by, I forgot the name of the guy. He's a Brazilian guy. I probably can't even pronounce his name properly. Lazaro Nixon, I think, or something like that, but I'm sure my pronunciation is not correct.

Greg Molnar [00:21:36]:
So sorry for for Yeah. But it

Charles Max Wood [00:21:38]:
was an awesome project.

Greg Molnar [00:21:39]:
Yes. It's still a it's still a great project. Yeah. And, it does more what the built in rails, generator. But the thing is, even though the generator was there, other people don't know about it. Now that Rails has a built in one, a lot of people are aware, oh, we can have an authentication generator and they might say the built in Rails one is not for me, but they find the other one or other alternatives. So this is why I love getting these features into Rails. And the built in one in Rails doesn't have registration and, what else? It doesn't have a few features which you would expect from an authentication flow because I think the reason for that is the core team believes that they are custom for applications.

Greg Molnar [00:22:26]:
Usually like sign up, it might it's very different for a lot of applications. So they expect you to implement that one on your own. Mhmm. But this authentication zero, for instance, it generates all of those parts as well. If you are into a full fully flashed, you just want your own code, the code to sit into the repository, but you don't wanna write the line of code, I think that's a better option. If you want to have something custom and use just the rails generated stuff, then go with the built in rails one.

Charles Max Wood [00:22:55]:
Yeah. I'm working on a generator of my own that will generate the views because I don't like the views that I got when I ran the rails generator. But, yeah, I mean, just it's it's basically I would like to build the tool build things that run on top of the the built in rails generator because I think it it does a really good job.

Valentino Stoll [00:23:17]:
Yep. I'm I'm curious here. I love your insight, Greg. I know it's it does, like, passwords as, like, the default, for the generation. How are you how do you feel about, you know, passwords with users? Like, I know there's a lot of talk around this, like, do we go passwordless, passkeys, we're in the future for a bit, like, you know, where where do you see, like, the industry, like, coming together? Or is it still kind of, like, a little bit uncertain?

Charles Max Wood [00:23:48]:
Or the OOS. That's the other one.

Valentino Stoll [00:23:50]:
Or the OOS. Right? Yeah.

Charles Max Wood [00:23:51]:
Somebody else is managing your credentials and so you have Apple or whatever it is.

Greg Molnar [00:23:55]:
Yes. You have

Charles Max Wood [00:23:56]:
a token from them and you authenticate them on the token.

Greg Molnar [00:23:59]:
Yeah. Well, I in on both of those cases, I think I might not be the mainstream with my opinion. So for FastKeys, I love FastKeys. I use a YubiKey for two factor authentication. I think it's amazing for that because for that, you can have multiple options. For instance, I have, I have a YubiKey, but I have two laptops. So sometimes I don't have my YubiKey with me. And, I have two YubiKeys, but I keep one as a backup at home, So I never really, that's not in a laptop.

Greg Molnar [00:24:27]:
That's just if I, if mine breaks, I can use that one. So I have multiple authentication, two factor authentication set up at most services. I can use my phone with India, the app on my phone, or I can use the YubiKey, which is much more convenient when I'm at home, I just touch it and then it's done.

Charles Max Wood [00:24:42]:
Great.

Greg Molnar [00:24:43]:
But for, for whole authentication, I think there are a bunch of things which are not so easily resolved. Like what are you doing with, logging in on your iPhone and on your Windows laptop? With the same pesky, because you can't really transfer it between device. You can, if you are on iOS and Mac with everything, it's amazing. It's fine. It's convenient. Everything is, is in the whole ecosystem, but what if you have an Android phone and the MacBook, or it's not so easy to transfer your credentials between different services. That's my main problem with PESQIES. It will be probably solved eventually in the future.

Greg Molnar [00:25:21]:
Then I will be all for pesky. But since then, I think it's not so easy to handle all of those edge cases.

Charles Max Wood [00:25:31]:
Yeah. One one thing that I'm wondering that along the lines of what Valentino is asking though is that it seems like when folks credentials get compromised, it's it is the password. Right? It's, hey. Here's a username and a password that'll get you into the website. So do you favor more passwordless options? I mean, that's what the pass key is, but you've also got, like, magic links or, you know, hey. Here's an email, and we're gonna send you one time password or any of that. Like, is is that any more secure, or is that just an illusion?

Greg Molnar [00:26:04]:
In my opinion, not at all because if I get access to your email account, I have the keys to all of your Right. Accounts. Right? But usually so that that that it's not that clear because also if all of the sites you signed up for support a password reset by email, then I can also take out

Charles Max Wood [00:26:21]:
your account.

Greg Molnar [00:26:22]:
Right? So I think the solution for all of this is multifactor authentication. Mhmm. Because even with best keys, what if my laptop gets stolen and, not stolen in the state when it's open and then they have access to all of my, all I have. Right. Usually this is why it should be something you know, and something you have access to because my one password shuts it down after five minutes or whatever. So if someone gets access to my laptop, they can't get access to my passwords. They can access to my YubiKey because it's plugged into the laptop, but they don't have the password. So I still have two things, which they can only get one of them.

Greg Molnar [00:27:00]:
Same with the email. Once someone's accepted the email, they can take over your account. But this is the same it's true if it's only password. So just passwords on their own, I don't think they are good enough.

Charles Max Wood [00:27:14]:
So the other piece of this for me is, how do I put this? I'm super cheap. And so, like, Riverside, for example. Right? I could set up an account for every single one of the hosts to be able to start the podcast. But, realistically, that's a lot more expensive than setting up, you know, a couple of generic host accounts. But then, you know, how do you set up third party authentication for shared accounts or two factor authentication for shared accounts? That that's been the rub. Right? And so I I tend to not turn it on and then essentially just trust the people that I've shared the password out to because I don't have a better way to do it.

Greg Molnar [00:28:02]:
You can do that actually. So I'm working on something with the team where we have the same problem and the way we resolved it. You know, if you set up two factor authentication on with an authenticator app, it's just, you just need a seed and it generates a token based on that seed. So we have that saved and whenever you want to share that 2FA with someone, he gets the seed and he can have the same setup on their phone. And then you have the same authort to be the setup on multiple devices for multiple people, so they can still have the second factor. I see. That makes sense.

Valentino Stoll [00:28:37]:
Factor. That's really cool.

Charles Max Wood [00:28:39]:
That that's that's been the piece that I've been missing is, yeah, it's like, okay. How do I share the second factor of two factor authentication?

Greg Molnar [00:28:46]:
Or you can go down the other way, which I don't recommend, but it's quite popular. You use something like one password where you can share the

Charles Max Wood [00:28:55]:
That's essentially what I've been doing because I've been sharing the password out of one password.

Greg Molnar [00:28:59]:
My problem with that then it's not two factor because you have the password and the second factor at the same place. So Yeah. If anybody gets access to that one, they have everything they need to log in. I like to separate these, the factors from each other.

Charles Max Wood [00:29:13]:
Right. Well, that's the whole idea.

Greg Molnar [00:29:16]:
Yeah. And on the

Charles Max Wood [00:29:17]:
topic I may have preempted other questions from Valentino, so I'll let him keep minding that.

Greg Molnar [00:29:22]:
On the topic of outsourcing your authentication, I don't think that's a good idea. Actually, the q and a, somebody asked me about this. And, Okta is one very popular service for outsourcing your authentication.

Charles Max Wood [00:29:36]:
Okta Okta and Auth0, but Auth0 is owned by Okta these days. So

Greg Molnar [00:29:39]:
Yes. So they had break breaches in the past, and they just had a breach after my conference talk again. Not a breach, but a security incident, but they had a proper b breach a few months, before the conference. And I think

Valentino Stoll [00:29:53]:
I mean

Greg Molnar [00:29:55]:
Yeah?

Valentino Stoll [00:29:56]:
I I kind of like the approach, like, single sign on took in that it's like, at least there's a a rollover approach. Right? Like, okay. If they if you've been identified of a breach, like, you can invalidate everything that's in that, right, organization.

Greg Molnar [00:30:16]:
Use a password manager and you have unique passwords everywhere, if you are in a breach, it doesn't really matter because they don't have the old password.

Valentino Stoll [00:30:23]:
Right, that's true.

Greg Molnar [00:30:24]:
And my problem with Okta is their attitude. I think even though they are a security company, they are more money and profit oriented than security oriented. That's what I see from their behavior. They might not like that opinion, but that's what I see. And I think they care more about sales than actually making a security, and you can see that from the security issues they had in the past because some of them is, I don't wanna be rude or just because everybody makes mistakes, but some of it you wouldn't expect from a security company.

Charles Max Wood [00:30:57]:
Yeah. I will say so when I started building top end devs, I was using Auth0, And I had two problem well, I had more than two problems. But a couple of the problems came into if they were down, I was down, was one. Yeah. Right. Because nobody could authenticate.

Greg Molnar [00:31:14]:
Yeah.

Charles Max Wood [00:31:15]:
The the other issue that I ran into was, it was way more complicated than just allowing people to have passwords in my own system using device or, you know, building my own. These days, I just roll my own. I I use the rails generator, and then I just put put what I want on top of it. And so so it was just overkill. And then, the the last issue was, I mean, literally anytime I had any kind of problem, like, it yeah, it it wasn't just the complications, and it wasn't just that I was down when they were down. But but there were some other issues within just the way that I I had things set up, and it was easy to fall into those problems. And it affected everybody. So Yep.

Charles Max Wood [00:32:03]:
Anyway.

Greg Molnar [00:32:04]:
And sometimes if there is an issue, you can't resolve it because it's out of your hands. It's

Charles Max Wood [00:32:08]:
on your

Greg Molnar [00:32:09]:
end or the way you implemented their integration. Right. But they do a

Charles Max Wood [00:32:14]:
lot of things for you too. I so, you know, they they do some level of authorization. They'll handle the the third party, like Google and Apple and Facebook, you know, whatever. Whoever you wanna let people log in with GitHub, like, they do all of that. And so you don't have to go and jump through the hoops with an OmniAuth. Right? There there are reasons why people go for it. You know, they're probably a little bit better at security than you are, but, you know, as you're pointing out, Greg

Greg Molnar [00:32:45]:
Except Okta.

Charles Max Wood [00:32:47]:
Yeah. You you you may not know the issues that they actually have because you're outsourcing it and trusting them instead of being in your own system where you can audit and verify it.

Greg Molnar [00:32:57]:
So Exactly.

Charles Max Wood [00:33:00]:
Anyway, I I see people use it. They seem to like it, but but I think it's for those bigger apps where you're really looking for that enterprise level set of features for for the things that I was doing. It just didn't make

Greg Molnar [00:33:15]:
sense. Yeah. I also think it doesn't make sense for most organizations, but probably it does for some. I don't know. But even then, I wouldn't go with Okta for sure. I haven't heard of OZERO, which is probably a good thing. Probably they didn't have any break fees or any major security.

Charles Max Wood [00:33:31]:
Okta acquired Oat Zero, like, three or four years ago.

Greg Molnar [00:33:34]:
So Oh, so it's basically the same company now.

Charles Max Wood [00:33:36]:
It's more or less the same company. But for for for me, and I think this is what you're saying too is, do your due diligence if you're gonna pick one, and, make sure that you know why you're going that way as opposed to building yourself.

Greg Molnar [00:33:54]:
Yeah, definitely. And one more thing I wanted to mention about the Rails authentication generator is the reason I really like this one because Rails has a bunch of helpers which people don't know about, like has secure password, all of these, new, secure token generation methods and validation methods.

Charles Max Wood [00:34:15]:
Are so nice. You use them for Yeah. You the here. So I'm gonna back up for a second because I love these. So I use them for all kinds of things. Right? People people think, oh, I have a secure token generator that's you know, so I'm gonna put it in my my cookie as some kind of authentication key or, you know, I'm gonna use it for this other auth and that other auth. But you can generate keys for anything. And so, I've been using it.

Charles Max Wood [00:34:39]:
I'm I'm trying to get to the point where I'm running my own, premium podcast feeds, and it's like, hey. Look. If you donate to the show, you'll get, you know, ad free stuff. Right? And so you can generate tokens for that. You can generate toke I anyway, I don't mean to derail, but this is a really, really handy feature. And if you if you need something that's not guessable, then this makes it really easy to do it.

Greg Molnar [00:35:05]:
Yep. And verify it is just built in. It's just super easy. And we're experimenting. Yeah. Yeah. And I think that's why it's good because you you generate your authentication system and then you read through the code and you learn from it. You just need, oh,

Valentino Stoll [00:35:20]:
what

Greg Molnar [00:35:20]:
is this this helper? I've never heard of this. I think this is also why it's good to have this. It's just raises awareness of certain areas, helpers, and features which people wouldn't know about otherwise, probably.

Valentino Stoll [00:35:32]:
Yep.

Greg Molnar [00:35:35]:
And then the next thing I mentioned in the talk is it's not really a technical change, but it's, an important change. It's Rails has a new maintenance policy, which is, I need to read this because I can't say that tell it from the top of my head. So every minor releases will receive security fixes for two years after the first release in its series, which means in practicality, if 1.1 is released January 2023, it will receive security fixes until 01/01/2025. After that, it will reach its end of life. So it's I think the maintenance period became shorter, which means that you should everybody should take upgrades seriously and don't stay on all versions of Rails because it's just, it's not gonna get security updates. They all they make exceptions sometimes, but you shouldn't rely on that. In my opinion, you should make sure your apps are up to date.

Charles Max Wood [00:36:36]:
Yeah. I think a lot of things have changed on that front too though, because, I've worked on a handful of apps for clients where I had to upgrade from, say, a Rails four, Rails five. Right? And those upgrades were often rather painful for one. And the the other thing is is that yeah. It's just it you know, it was kind of a giant thing, and you had to take it on and, you know, the maintenance cycle on things. Anyway, lately with everything past about rails six, rails seven for sure, like, the upgrades have not been nearly as bad. And so, I you know, you're mentioning the the maintenance cycle and, hey, this encourages people to upgrade and, you know, maybe you have a different window to get security patches and stuff like that. But the the other side of it is is that, like, I I have a whole bunch of Rails seven two apps that I need to get around to upgrading to Rails eight, and I've kind of been waiting for, like, a a couple of patch versions to come out.

Charles Max Wood [00:37:46]:
Right? So that whatever issues everybody else is finding, good on you folks, and I really appreciate the work you're doing. And, you know, and then I can go pick them up. But, yeah, I from what I've seen, like, seven o to seven one to seven two to eight, they really haven't been that bad. And so, you know, it's okay. I'll I'll I'll spend a few days on this or a week on this. If it's a really big app, maybe it takes longer. But yeah.

Greg Molnar [00:38:14]:
Yeah. It's much better. I I did three years two to three upgrades as well. So two point two point three to three, that was a big thing about three. Four was a little bit easier. Four to five, a little bit easier. From five on, I think, yeah, it's much easier.

Valentino Stoll [00:38:29]:
That's good.

Greg Molnar [00:38:29]:
Except, when you go rails eight, you need to ask yourself the question, what am I gonna do with the front end stuff? Are you gonna keep that bucket or are you killing it? Because then it might be a bigger change.

Charles Max Wood [00:38:42]:
Yeah. I remember my prop shaft.

Valentino Stoll [00:38:45]:
My first rails upgrade. Yeah. Prop shaft.

Charles Max Wood [00:38:49]:
Prop shaft and, you know, all the stuff that's there, the the way that rails eight and rails seven too, frankly, in a lot of ways, handles the front end stuff. It is it is so nice. You know, I don't I don't miss, a what is Sprockets. Don't miss Webpacker. When I moved off of Webpacker, I I wanted to throw a party because it was so much easier. I mean, the the issue with Webpacker, a lot of people had was just setting it up and knowing how to do it, but I found myself having to tinker with it a lot. And so Prop Shaft, I've just kinda set it and forget it. It's been really cool.

Greg Molnar [00:39:28]:
Yeah. And the the build step is always like, yeah, something fails at the build step. It's like, I need to deal with this.

Charles Max Wood [00:39:34]:
Yeah. And it

Greg Molnar [00:39:35]:
was just slowing things down. I I also didn't like that.

Charles Max Wood [00:39:37]:
Import maps. I love them.

Valentino Stoll [00:39:40]:
It's funny you don't you don't realize how stable, like Rails and Ruby ecosystem has become. Because I mean, I've going back, like, to, you know, upgrades, like, you know, I was thinking of my first Rails upgrade. I did, like, a Rails one app, that was on Ruby 1.87 which was like the nightmare Ruby, to upgrade. Because there were just so many drastic changes, right? And so like I don't think people realize like what the early stages of a framework or language are, right? Like, because like the stability that we get now like it's just mind boggling, right? Like, you know, yes there'll be some deprecation warnings or things like that or like, you know, the big changes like are really not that big in like the grand scheme of things, right? Like if you look at, like, some of the other libraries out there, you, like, you know, the whole, like, back end could get swapped out and you'll be like, well, what do I do with all this stuff I built? Like

Greg Molnar [00:40:35]:
Yeah.

Valentino Stoll [00:40:36]:
You know? It's, like, incredibly stable now. So it's it's just wild. Yeah.

Charles Max Wood [00:40:41]:
Yeah. And for the record, when Greg was talking about upgrading from Rails two three to Rails three, that was when they merged another framework called Merv

Valentino Stoll [00:40:50]:
Merv. Merv.

Charles Max Wood [00:40:51]:
Yep. Into Rails. And so there were just major, major changes. I mean, a lot of stuff got a lot better, but the upgrade was painful.

Greg Molnar [00:41:02]:
Yep. Octi record was pretty much completely changed. It was a lot of changes.

Valentino Stoll [00:41:08]:
That said, shout out to, to Vikandra who, like, maintains the rails RT LTS. Oh, yeah. Yeah. If you're, like, honestly, if you're out there stuck on a rails upgrade and it's just, like, not worth it for to your business, like, just pay this service Rails LTS and long term support and it just like they make sure that like Yeah,

Charles Max Wood [00:41:30]:
they give you the security

Valentino Stoll [00:41:31]:
patches and yeah. We used that for a couple clients a long time ago and it just like it works incredible out of the box. It's like

Greg Molnar [00:41:41]:
turnkey. Yeah. We have to

Charles Max Wood [00:41:43]:
get them on an s then how that all goes.

Valentino Stoll [00:41:47]:
They've been all so long now. Tricky sometimes. Yeah.

Charles Max Wood [00:41:50]:
What was that?

Greg Molnar [00:41:51]:
I'm sure it's very tricky to to solve issues sometimes for them. I wouldn't wanna be in their shoes.

Charles Max Wood [00:41:59]:
Yeah. But at the same time, I mean, it's gotta be really because the, I just went to their page, and they have LTS versions for Rails

Greg Molnar [00:42:07]:
two. Crazy.

Charles Max Wood [00:42:08]:
And so I'm going, boy, what what what are you having to fix? You know? And and how deep into the weeds do you have to get?

Greg Molnar [00:42:19]:
Yeah. But from a security perspective, I think it's still risky to be on the third version because nobody really tests

Charles Max Wood [00:42:28]:
That's true.

Greg Molnar [00:42:29]:
Those versions. So there are no no security patches or security issues made public. There might be some non public ones which people might abuse. You just don't know about them. So I think it's because like the latest version of Rails, a lot of companies who are using Rails gets penetration tests and sometimes issues are upstreamed from the reservoir to a penetration test. They find an issue. It turns out, oh, it's actually an issue inside of Rails. So we upstream the, the patch and fix it for everybody.

Charles Max Wood [00:42:59]:
Yep. That's true.

Greg Molnar [00:43:01]:
But those old versions, I think, are not a good idea to use, even though you get some support.

Charles Max Wood [00:43:08]:
Yep.

Greg Molnar [00:43:10]:
Yeah. And then the next thing I mentioned in the talk is, is a bit of a it's a pretty small change is the CVV and CVC was added to the parameter filter defaults. But the reason I wanted to mention that in the talk is because a lot of people don't know about the areas parameter filtering, which is a very handy tool to filter out anything sensitive from your logs. Like, you you know, when a request comes in with a password in it, you don't want that to show up in your logs. Or if you store social security numbers, you don't want them to show up in your logs before you encrypt them. And, this feature is just amazing for anything sensitive, which you don't want to be in the logs. You can just add it to your your initializer, and then it gets excluded. These are the things which I also think Rails access it because a bunch of other frameworks don't really have an an easy solution for this problem, but RAYS is just out of the box and for years, it's it's amazing.

Charles Max Wood [00:44:10]:
Yeah. I did have this bite me in the rear end once, But, yeah. I I agree. The way it bit me in the rear end was, I had a stripe webhook key that

Greg Molnar [00:44:25]:
for

Charles Max Wood [00:44:25]:
some reason wasn't being set, and it still showed it as filtered. And so I didn't know it was empty until I actually, like, forced it to log it out.

Greg Molnar [00:44:38]:
I see.

Charles Max Wood [00:44:38]:
But, yeah, this is definitely a best practice. And if you get into, like, HIPAA or, what's the financial one? PCI or any of these

Greg Molnar [00:44:49]:
spoke to ISO.

Charles Max Wood [00:44:50]:
They they they will crucify you on this stuff if you're not doing it. And and the logs are usually an area of vulnerability that's overlooked.

Greg Molnar [00:45:02]:
Yep.

Charles Max Wood [00:45:03]:
And Rails does it by default for all the common sense stuff.

Greg Molnar [00:45:07]:
Yep. Yeah. And then the second half of my talk was these, these are the new features, which wasn't that many, to be honest, but still there are some small progresses and that's all we need, I think. And the second half I wanted to highlight to people why I think somebody should choose Rails if they want a if they need an application with high security standards. And my main reason for that is there is a tool for everything you would need in the Rails and Ruby ecosystem. Mhmm. Like parameter filtering, which we just mentioned, built into the framework, rate limiting now built into the framework. Authentication, you have device and a bunch of other things.

Greg Molnar [00:45:53]:
Multi factor authentication, bunch of gems you can choose from. It's super easy to implement all of these features. Or I have a list here. Oh, the other thing which is

Valentino Stoll [00:46:04]:
scripting stuff.

Greg Molnar [00:46:05]:
Oh, yeah. Syscripting. Yeah. You don't even need to think about it. Actually cross site scripting you need, but cross site request forgery, for instance, is just built the framework for Yeah. I don't even know which version, like rails have like even.

Charles Max Wood [00:46:20]:
It's been in there forever.

Greg Molnar [00:46:22]:
Yeah, it's, so we have a lot of things which you just get for free and granted, it's amazing. And other things which are not built into the framework, like if you're talking about compliance, one of the requirements to be SOC two or ISO compliant is that your developers shouldn't access anything in production without you knowing about it, so if you have a rogue employee, it's not like they can just steal whatever they want, they still, usually they can, but at least you have an audit log so you can pinpoint who was the malicious actor. And there are there is a gem from, 37 signals called audit, nineteen eighty four and, console nineteen eighty four, which is if you install that, anybody who goes to the res console, they need to authenticate themselves, so they need to say who they are and why are they accessing the data. And then, you have an audit trail. So whenever somebody accesses production data, you have a now an audit trail. One important thing to know about this, though, is it's advised to store this data in a read only database. Sorry, a write only database, so they can't nobody can update the data. They cannot it only writes, but you can't update.

Greg Molnar [00:47:43]:
Otherwise, if somebody wants to be really tricky, they can just Ruby is very dynamic, so they can find a way. I found a bunch of ways, but now it's it's much more secure than the initial release was. You can find a bunch of ways to to trick the system and override existing log entries. But if you store it in a database, which is only you you block update commands on the database connection, then it's pretty set secure and safe.

Valentino Stoll [00:48:10]:
When did they, change that to write only? That's really awesome.

Greg Molnar [00:48:15]:
They didn't change it. You need to change that on the database.

Valentino Stoll [00:48:17]:
Change it yourself. Okay.

Greg Molnar [00:48:18]:
Yeah. You can't you can't build it into the gem because you do it on the database level. If you build it into the gem, then you can you might still find a way to override it in Ruby because it's a super dynamic language. You can do

Valentino Stoll [00:48:30]:
Mhmm.

Greg Molnar [00:48:31]:
Things that you wouldn't even think about. That's how I found a bunch of things to over to to bypass it. But, yeah, that's a really good, tool for compliance, reasons. Also static code analysis, there is break man, there are other tools. Dependent vulnerable dependencies, we just mentioned, bundle audit, dependabot, and probably there are others as well. CSP, content security policies, built into Rails. Open redirects. Open redirect protection is default built into Rails nowadays.

Greg Molnar [00:49:06]:
So you have a two you have for every security requirement or need, encryption, active record encryption, It's really easy to do now. You don't even need to think about anything cryptography. It's just you set your keys, and you are good to go, and everything is encrypted in the database.

Valentino Stoll [00:49:25]:
The only thing that's missing is secret scanning.

Greg Molnar [00:49:28]:
Secret scanning? You mean, the repository?

Valentino Stoll [00:49:34]:
Like, something like Truffle Hog, as an example.

Greg Molnar [00:49:40]:
Yeah. Well, but you you should do that on the repository and, there are services or there are tools for that for sure even with in Ruby. I don't know any on the from the top of my head, but I'm pretty sure there there are some.

Valentino Stoll [00:49:57]:
How do you feel about like, storing encrypted real secrets in a repo?

Greg Molnar [00:50:03]:
As long as your master key is stored safely, it's a very hard to break encryption. Yeah. With quantum computing, we might get into trouble in a few years, but until then, we are fine and safe. And then we'll figure out how to how to solve it. I'm sure. Not us, but someone who's good with cryptography, they figure out the way. But I think that's perfectly fine. You just need to make sure your master key is safe and secure.

Charles Max Wood [00:50:29]:
Right.

Greg Molnar [00:50:31]:
And then it also it simplifies the whole process. You can use environment variables, but then how do you handle that during the deployment flow? How how are you gonna pull those from, secret storage? It all adds complications and complexity.

Charles Max Wood [00:50:47]:
A lot of that I've just been doing what Kamal does, so it just sticks it on the container when it runs.

Greg Molnar [00:50:54]:
Yep. Yeah. And Kamal has good integration with the one password and other sec secret storages like with Bitbucket or not Bitbucket. Yeah.

Charles Max Wood [00:51:04]:
I haven't used any of that because I'm the only one that deploys.

Greg Molnar [00:51:08]:
Yeah. Then it's yes. It's super easy if it's only you. Yeah. If it's a team, it gets a bit more complicated, but still it's it's not hard to solve.

Valentino Stoll [00:51:15]:
Do you have, like, a, a security checklist that you run through for real zaps? They make sure, oh, make sure all these things are, you know, configured.

Greg Molnar [00:51:26]:
Not really, to be honest. I when I do penetration test, I have a checklist which I go through, but it doesn't really depend on a Rails app. I have some Rails specific things, which I know it's a real set that I need to check this and that, but a lot of it is only in my head to be honest.

Charles Max Wood [00:51:45]:
Right.

Valentino Stoll [00:51:46]:
I mean, to that point, like, you know, Rails is pretty secure out of the box, right? Like, it's not exactly difficult to, you know, break that but like, it's not easy either, right? Like, I feel like with the reels new, like, it's gonna be pretty hard to like do something insecure until you start actually, like, you know, adding new things.

Greg Molnar [00:52:12]:
Yeah. Most of the vulnerabilities I see, now it's it's used to be XSS, and it's still, I would say, that's kinda the second, but the top one nowadays is authorization. So because it's super easy to make a mistake, to forget, to authorize some endpoints and then it can be accessed by someone who shouldn't have access.

Charles Max Wood [00:52:32]:
Right.

Greg Molnar [00:52:32]:
So But I think if you are talking about a basic level of security, make sure your authentication is secure, make sure your authorization is secure, and then make sure that there are no accesses and that's pretty much it. The rest, like SQL injections, really hard to have a secret injection issue in Rails now because 80% of the APIs in Rails in their active record are are safe and secure. And for authorization, what I always recommend is use a, white list approach rather than a blacklist, a blacklist, because it's always better to have someone complain about not not having access to something they should have access to than realizing, oh, shit. Somebody has access to something they shouldn't. Right.

Valentino Stoll [00:53:16]:
Right.

Greg Molnar [00:53:17]:
Because then it's, you need to report it and to your customers, etcetera. If you have, it's basically a data breach. If somebody can access things they shouldn't.

Valentino Stoll [00:53:26]:
Well, one thing I'm curious, I know we're short on time, but, I'm curious to get your thoughts on, like, one common pattern that Rails has embraced has been this, like, restful resources, like, targeted by IDs. And, like, part of the problem with that is this, like, guessable because they're, like, sequentially ordered IDs. Like, do you do you feel like Rails could is, like, overdue for, like, a new pattern there? Or, like, is it not worth the effort to try,

Greg Molnar [00:53:57]:
like, use it? Matter. Even if it's guestable or not guestable. I found authorization issues with the UIDs because they are not secure. They can be guest, they can be brute force, and they can be leaked. That's the that's the most common thing that you have UIDs and you think, oh, it's safe. We don't need authorization, but somewhere in your API, you leak the UIDs and then people can just find them and

Charles Max Wood [00:54:23]:
Security through obscurity,

Greg Molnar [00:54:24]:
Exactly. You should you should have authorization. That's why actually I think numeric IDs are better because then you it it forces you to think about authorization. If you are like, oh, it's hard to guess, we don't need authorization. Yeah. Down the line, you will see for sure you have issues.

Charles Max Wood [00:54:42]:
Well, the other thing is is that typically you're gonna see your authorization at the controller level. Yeah. And so if you've got good tests around either end to end or controller tests, you you should be able to pick up, you know, person has what what whatever it is that credentials them. Right? Whether it's a membership or a role or something. Right? You should be able to test that and say, okay. I with reasonable confidence running my tests every day or, you know, whatever, twice a day or yeah. Or every time I check-in. Right? I I can say with reasonable confidence, people don't have access to stuff they shouldn't have access to.

Greg Molnar [00:55:25]:
Yeah. But you can still make mistakes and

Charles Max Wood [00:55:27]:
you use this

Greg Molnar [00:55:28]:
new feature and then you forgot forget to add authorization to that. And, like, I found an issue recently during a pen test where they were doing authorizations. The same endpoint could fetch one record or a list of records. So they were expecting either an ID or an array of IDs, and they did the authorization on the on the on the first item. So what you could do, you could set the ID to something which the user is authorized to have access to, and then you can set the IDs in the same request to something they don't have access to. And then because it thought, oh, it's only requesting one item, but actually it returned all of the items because they also sent the second parameter. The authorization check was successful, but you could still get access to things which you shouldn't. It's easy to make mistake, to be honest.

Charles Max Wood [00:56:24]:
Yeah. I guess I guess what I'm saying is for kinda your baseline stuff. If you're testing it, you know. But, yeah, you're right. If if your strategy isn't well thought out and your test only tests that your strategy works

Greg Molnar [00:56:40]:
Yep. Yeah. This is why I think, gems like Bandit is really useful because with Bandit, you can turn on a feature which we erase an exception if you don't call the authorize, I think it's called authorize the method in a contract action, So it forces you to have authorization in every endpoint. And if you don't, then you might make a mistake and then it will warn you. And also it's really like you can do a whitelist approach easily with that one. So nothing can be accessed by anybody, and you explicitly grant access to to certain records

Charles Max Wood [00:57:19]:
Right.

Greg Molnar [00:57:21]:
For certain conditions.

Charles Max Wood [00:57:24]:
Yep. Alright. Cool. Well, is there anything else you wanna make sure that people know before we do our picks?

Greg Molnar [00:57:34]:
I think that's it, basically. Well, Rios is still a great choice for security, in my opinion, but still, you need to be aware all the time and be on the lookout because it's easy to make a mistake. Nobody to blame for that. We all make mistakes. We should learn from them and get better.

Charles Max Wood [00:57:54]:
Yep. Alright. Well, let's go ahead and do some picks. Valentino, you got some picks for us?

Valentino Stoll [00:58:01]:
Oh, yeah. So I was, at the last, New York City Ruby AI meetup and happy hour and demo night, which has now been consolidated into a nice artificial Ruby event. So, I gave a talk, on a project I'm working on called Ruby Tuner, to try and fine tune an LLM specifically for Ruby code generation. And I, I have this whole framework built, that wraps Python basically to start, with the idea of over time moving it, away from Python as the new Ruby features start to become available. And so, I showed showcased kind of like the whole process end to end of fine tuning a very specific contrived example of turning a URL into markdown, and then getting a, you know, response out of it. So it's it's a lot of fun. There's a new, event in March I recommend people signing up for at artificialruby.ai, and check out Ruby Tuner. And then just, like, something really fun and because I always share, something very specifically AI.

Valentino Stoll [00:59:13]:
Peter Cooper has been, like, diving deep, and he runs the Ruby Weekly. Mhmm. He shared this really fun, and kind of hilarious, prompting strategy for, basically creating a group of specific, authors of software. So he has, like, Paul Graham and, Linus Torvald and David Hanover Hansen and, like, kind of made personas for each of these characters and then got them into a prompt to, like, argue over very specific implementation strategy, at a very detailed level. And then and he shared the prompt that he used for it and, like, it's it's kind of fun to, to play with this. And it, like, brings in kind of, like, the a combination of mixture of agent or a mixture of, experts as well as, like, planning execute, like, combination of those two. It's just, like, really fun to see, that kind of stuff evolve and, like, see a panel of judges judge thinks, in a simulated way. I recommend checking that out.

Valentino Stoll [01:00:17]:
It's it's just fun.

Charles Max Wood [01:00:19]:
That sounds that sounds so funny. I'm gonna go ahead and throw in some picks. So first of all, I do a board game pick or a card game pick. This week, I'm gonna be picking a card game. It's called The Gang. It is essentially it's Texas Hold'em poker cooperative, Texas Hold'em poker. So what you're trying to do is you are trying to sorry. I'm trying to copy and paste the link while I talk.

Charles Max Wood [01:00:55]:
You're so you're all playing Texas Hold'em, so you have two cards, you flip over the river, all that stuff. Right? That you're, normally do. Right? So, and then what you do is once you have your cards, you can there are tokens out. There's one for each player. Right? So if you have five players, there's a five star token, a four star, three star, two star, one star. And so what you're trying to do is there's no bluffing in this game, because what you're trying to do is you're trying to get the tokens to the right people. So the five star token is with the person that wins, and the four star token is with the person that would come in second. Right? Third, fourth, fifth.

Charles Max Wood [01:01:40]:
We played it with three players, so we you know, it was just, you know, three tokens. So, anyway, so you grab the token that you think you deserve, and then somebody may say, no. I think I think I have that. Right? And so, usually, it's the top one that gets passed around them a lot and the bottom one that gets passed around a lot. Right? So it's like, you know, I look at my my cards. I can't remember the pocket cards, I think, is the term. Right? I have a two and a three. I know that I've you know, I'm probably not gonna win.

Charles Max Wood [01:02:11]:
Right? But as you flip over the river, maybe you flip over a two and a three. Right? So now I have two pair. Now I have a good hand. And so, you know, then I may be more aggressively grabbing the top or next to top. You know? And so and you can't talk about what you have, but, you know, so if somebody has, you know, three of a kind in Kings, right, they may more aggressively take that five star token back when I grab it. And but I can take it back from them, then they can take it back from me. And so then I may be looking at it and going, well, I have two pair, but they're kinda crappy pairs, so maybe they do have something better. And then as you flip over cards, you every every time you flip over cards, you put more tokens out.

Charles Max Wood [01:02:52]:
And so you can see where people are changing what they want to do. And so a lot of times, right, you'll flip over a 10 and somebody who was kind of not sure where they were all of a sudden is really aggressively saying, I I should get the top one. And it means that, you know, my hand went from having nothing to having a pair or something like that. And so you're kind they're trying to read the table and figure out what it is. And the way you win is you get three in a row or not three in a row, but you get three correct before you get three incorrect. And, that's pretty much it. And then there's a deck of cards. We only played with with a handful of these, but there's a bunch of cards that put restrictions on what you can do.

Charles Max Wood [01:03:34]:
Right? And so maybe it takes a way a way around of tokens where, you know, you you would get more information or things like that. So, anyway, it was a lot of fun. The gang board game geek has it as a weight of 1.64. So it's pretty approachable for, you know, most gamers. I think my kids you know, I don't know if I'd play it with my kids just because I'd have to explain poker to them. And mostly, it's that I would have to like, you you you have to explain the statistics and why this hand beats that hand and how how to figure out. Right? So, anyway, that's where it gets complicated is just knowing which hand beats which hand and then recognizing I have a straight or I have a flush or I have, you know, whatever. So, anyway, fun fun fun fun stuff.

Charles Max Wood [01:04:27]:
We played it after it was readily apparent that the Eagles were gonna win the Super Bowl, so we played it for, like, an hour. By the way, go birds. Anyway, so that's my pick there. And then the other pick I have is I'm pretty aggressively pulling together Ruby Geniuses. I have meetups planned starting on the February 25. We're gonna be getting into, all kinds of stuff. There's gonna be a book club at the March, and we're reading the O'Reilly book on prompt engineering for AI. You know? So just diving into a whole bunch of stuff.

Charles Max Wood [01:05:08]:
Basically, it's meetups. I'm gonna set up a Discord channel for each of them. Right? So we can collaborate with that. You get discounts on summits that I'm putting together. Right? They're not doing RubyConf this year, so I plan to put on a summit about when they would do that and, have people show up and and speak at that. You know? So just just stuff like that. I'm trying to think because ultimately, I guess the other thing is is if you sign up by the end of the week, which means that I I I guess people we didn't go live. So, anyway, I was also offering, if you had questions, you could text or send me a voice message, and I would get back to you, and you would get that for six months.

Charles Max Wood [01:05:55]:
But, anyway, so yeah. So it's it's the book club. It's the meetups. It's the the collaboration with other people. Just the ability to kinda get feedback on what you're doing or get help when you need it. These are the things that really came through for me when I was newer programmer. And what I found is that even as a senior developer, I'm craving that kind of interaction anyway. And so, you know, getting a bunch of people in and okay.

Charles Max Wood [01:06:22]:
What's new? What's going on? Things like that. And then finally, I'm also lining up. Some of the meetups are gonna be with people that are on the show. Right? So, you know, I've asked some of our past guests to do them, and we're gonna start doing some of those in March or April. So the the first handful, I just wanted stuff on the calendar that people were asking me for that I could teach. And that way, I didn't have to worry about whether or not I could fill those meetups with other presenters. But, yeah, we're gonna have a lot more of that because there are a lot of people that know a lot more about stuff than I do. So, anyway, you can go get it at rubygeniuses.com.

Charles Max Wood [01:06:59]:
And, yeah. Greg, what are your picks?

Greg Molnar [01:07:03]:
I have two picks. One is, a gem called Pandit, which we just mentioned because I think it's really good for authorize to handle authorization in Rails app. It just it it's a good help, and it helps you to solve a bunch of issues easily or a bunch of problems. So that's one of the picks. And the other pick is a bit of a self plug, which is I'm I'm working on a course for almost a year about security for Rails developers. And now I'm, I'm close to get it ready and publish it and it's already in on presale. And, once I record the video, videos, it's basically the written version is pretty much done. I just need to record the videos and then I will publish it.

Greg Molnar [01:07:48]:
And I hope it's gonna be useful for people to learn more about the caveats of security things in Rails.

Charles Max Wood [01:07:57]:
Cool. Where do people find it?

Greg Molnar [01:08:00]:
Just go on my website. There is a link somewhere on it, probably. I should I should put a banner on it, but you can find it on my website. There is a link, I think, at the top somewhere. So I'm Greg.com.io.

Charles Max Wood [01:08:14]:
Alright. Cool. We'll we'll put a link in the show notes too, and that way people can go and keep an eye out for it.

Greg Molnar [01:08:20]:
Great.

Charles Max Wood [01:08:20]:
Thank you. Yeah. Thanks for coming.

Greg Molnar [01:08:24]:
Thanks for having me. It was fun again.

Charles Max Wood [01:08:28]:
Yeah. Alright. Well, we'll go ahead and, stop here, wrap it up. Till next time, folks. Max out.