Speaker 1: Hey everybody, Welcome back to another episode of the Ruby
Speaker 1: Rogues podcast. This week, on our panel we have Valentino Stole.
Speaker 1: They know. I'm Charles Maxwood from Top Endevs. We have
Speaker 1: a special guest this week. It is Greg Monar. Greg,
Speaker 1: we've had you on before. But how are things in
Speaker 1: the middle of the Atlantic?
Speaker 2: Hi, guys. Yeah, all is good. Still, We're still alive
Speaker 2: in the middle of the ocean.
Speaker 1: The island's still upright, so things are good.
Speaker 2: Yes, yes, shitty leather sometimes, but yeah. It's been that time.
Speaker 1: I heard a clip not that long ago. It's an
Speaker 1: older clip, but it was a US congressman that he
Speaker 1: was interviewing a general or an admiral or something, and
Speaker 1: basically he was talking about Guam and he said, well,
Speaker 1: are you worried that the island is going to capsize?
Speaker 1: And the general with the straight face, right, because they
Speaker 1: have to have some decorum in there and they don't
Speaker 1: want to tick off the congressman. He looks at him
Speaker 1: and he goes he goes, no, no, we don't anticipate
Speaker 1: that didn't capsize.
Speaker 2: No, no, And the math it's supposed to be done
Speaker 2: for a few years now and it's still there, right,
Speaker 2: So I don't know what are these forecasts about.
Speaker 1: Yeah, all right, well we brought you on to talk
Speaker 1: about security in Rails eight. I don't even know where
Speaker 1: to start. Did a whole lot change or is it
Speaker 1: mostly the same as seven point two?
Speaker 2: Well, yeah, there are a bunch of things which are
Speaker 2: seven point two. But I think the imitation was triggered
Speaker 2: by my talk at Rails fird Yes, which was tied
Speaker 2: to the state of security in Rails eight. But some
Speaker 2: of the things I mentioned were actually Rail seven point two.
Speaker 2: But I think it was still worth mentioning those because
Speaker 2: a lot of people don't even know about those new
Speaker 2: features which were three years old back then, and Rail
Speaker 2: say it wasn't even know it really is at the conference.
Speaker 2: So it was a bit of a ah a pre
Speaker 2: planned talk.
Speaker 1: So so yeah, so where do we start then?
Speaker 2: Well, I can just list out the things which I
Speaker 2: was talking about. If you guys are that, you can
Speaker 2: go through all of those and you can ask questions
Speaker 2: and we can sound So one of the first things
Speaker 2: I mentioned during the talk was every new rails app
Speaker 2: this is a seven point two feature. Every newly generated
Speaker 2: Rails application has a default depend about GitLab CI file,
Speaker 2: which means if you are using not gitlabs for GitHub,
Speaker 2: if you're using GitHub, then on your CI automatically runs
Speaker 2: depend about, which is a dependent vulnerable dependency checks. So
Speaker 2: if any of the gems you are using has a
Speaker 2: vulnerability public, then you are getting alerted and then you
Speaker 2: can just upgrade and save yourselves from any hustles and
Speaker 2: so good.
Speaker 1: Yeah, I think yep, Well, I was just gonna say
Speaker 1: some people. I think most people know what depend about
Speaker 1: it is. But effectively you get poor requests if you
Speaker 1: have vulnerable versions of your dependencies.
Speaker 2: Yeah, or even for outdated bones. That's why I don't
Speaker 2: like dependabo. Actually I prefer bundle oud it, but it's
Speaker 2: basically it's very similar thing. But bundleoud it only alerts
Speaker 2: you about security issues, whereas depend about I think you
Speaker 2: can configure it depends a but also alerts you're about
Speaker 2: outdated ones. Where usually my way of when I work
Speaker 2: on the rest, my way of handling upgrades is it's
Speaker 2: like on a regular basis, like every three months. That
Speaker 2: is like a spike update all the dependencies. But secretary
Speaker 2: dependency is a different. Secrety issues are different. Obviously, you
Speaker 2: want to upgrade them immediately. But the rest I don't
Speaker 2: really care when a new GEM comes out. If it's
Speaker 2: just a non security issue, I will update it when
Speaker 2: I do my regular upgrade upgrades.
Speaker 1: Right, that makes sense. I do the same thing because
Speaker 1: a lot of times you're you're upgrades. If it's a
Speaker 1: major even sometimes a minor version, you know, it changes
Speaker 1: the API. Right, It's not just oh, hey, you're going
Speaker 1: to upgrade this and you're going to get security goodies
Speaker 1: right now. You may have to pull a major minor
Speaker 1: upgrade version because because there is a security issue and
Speaker 1: they didn't fix it in the version you're using, in
Speaker 1: which case, yeah, you have to go through the upgrade
Speaker 1: rigmarole and update your code as well as the gem.
Speaker 1: But yeah, I'm with you. I tend to tackle those
Speaker 1: things when I feel the need, right. So sometimes legitimately
Speaker 1: it's like, hey, there's a new feature in this that
Speaker 1: I need yep, But if it's the older version, how
Speaker 1: do I put this? I've been having conversations with people
Speaker 1: about like AI in programming, and it's like, hey, look,
Speaker 1: it makes you more effective in all of these different ways,
Speaker 1: and a lot of people are asking, is that going
Speaker 1: to replace programmers and I'm like, have you ever met
Speaker 1: a have you ever worked on a project that ran
Speaker 1: out of things for you to work on? And the
Speaker 1: answer is you might have had a side project that
Speaker 1: you decided was done right, And so with this, it's
Speaker 1: the same thing. It's like, okay, until it's a real
Speaker 1: high priority, there's just no reason to do it. And
Speaker 1: so I'm with you on that.
Speaker 3: Yeah, Yeah, it's funny.
Speaker 4: I've been trying to push people to just like bundle
Speaker 4: update patch on like every deploy because like the chances
Speaker 4: of something going wrong in a patch release is like
Speaker 4: so low that like you've gained so much more by
Speaker 4: like all of those security enhancements and like fixes in
Speaker 4: a patch little version that it's almost worth just like
Speaker 4: doing it if the test pass right, Like, yeah.
Speaker 1: So what does bundle update patch do Because I've used
Speaker 1: like the pessimized gem that locks in your version right
Speaker 1: and let's you upgrade from there.
Speaker 4: Yeah, so bundle bundle update tool it has like a
Speaker 4: way to give it different flags of like, so it's
Speaker 4: a canonical version to all the Ruby gems typically are,
Speaker 4: so as long as the gems in dependency's using our canonicals,
Speaker 4: meaning there's like a patch level a minor and a
Speaker 4: major version to it, then you could just say, okay,
Speaker 4: give me only the latest you know, patch updates. And
Speaker 4: like people I feel like as at least for like
Speaker 4: everything that reels would touch, Like the gem maintainers of
Speaker 4: those are very careful about what to release in a
Speaker 4: patch version and not like cause any issues because like
Speaker 4: they don't want to deal with all the issues that
Speaker 4: come from that, right, Like I'm not being like, oh, hey,
Speaker 4: like I have like this new like obscure thing, like
Speaker 4: they would rather just like, okay, let's make it minimal
Speaker 4: and then you know, in a minor major version, like
Speaker 4: it's to be expected, right, We've outlined these things that's
Speaker 4: gone through the process. But a patch version like it's like, hey,
Speaker 4: we fix this thing as serious, Like you should really
Speaker 4: integrate this.
Speaker 1: Right. So if I have in my gem file just
Speaker 1: sidekick and I didn't specify a version and there's a
Speaker 1: major version update, I can do bundle update with patch
Speaker 1: flag and it'll just update it to the highest patch
Speaker 1: version and it won't do a major update.
Speaker 3: It won't do it won't even do the minor right,
Speaker 3: so it will keep it.
Speaker 4: If it's like three point two, it'll do that and
Speaker 4: then just like pump it to the latest one, which,
Speaker 4: to be.
Speaker 3: Honest, doing that with Rails maybe a little trickier because.
Speaker 1: It does like, yeah, Rails is fine.
Speaker 4: You know, it has so many patches that get released,
Speaker 4: so if you like fall behind, but like that's why
Speaker 4: you're like, if you're deploying a lot anyway, right, Like
Speaker 4: then like getting Rails to update itself incrementally as it
Speaker 4: gets updated at a patch level is not going to
Speaker 4: be so bad. And a lot of times, you know,
Speaker 4: if you have a good test case, which you know,
Speaker 4: let's hope everybody does, but like if you don't, like
Speaker 4: obviously maybe you don't want to build this into your
Speaker 4: deployee process. But like, if you have a good like
Speaker 4: test infrastructure, like doing a patch update, like it's gonna
Speaker 4: be almost nothing and you'll catch most of the issues
Speaker 4: in any of the test files applications.
Speaker 2: What if they deplicate things in a I know it's
Speaker 2: shit they shouldn't, but sometimes they do, and then your
Speaker 2: logs are littered with all of the deplication warnings, right,
Speaker 2: and then you're.
Speaker 4: Like, I mean, personally, I would rather have it be
Speaker 4: secure than like, uh, you know, worry about all the
Speaker 4: proposity of the outputs, right, Like I feel like, you know, yeah,
Speaker 4: littered logs is not great to deal with, but like
Speaker 4: it's honestly better than the alternative of having like a
Speaker 4: security hole and then like getting like you know, page
Speaker 4: your duty in the middle of the night, like, hey,
Speaker 4: somebody took advantage of this. We need to like start
Speaker 4: an incident response, right Like, yeah.
Speaker 2: But that's why you should use bundle audit or depend
Speaker 2: on what we the security updates, because then even though
Speaker 2: it's a patrities, you will notified that this is an
Speaker 2: important paturities you need to do this upgrade.
Speaker 4: Yeah, So I'm curious what your thoughts are there, Like
Speaker 4: is that the best like approach still today is like
Speaker 4: using the audit feature, Like what is your workflow?
Speaker 3: Like, look like that's.
Speaker 2: What I use. It's running on CI and it's running
Speaker 2: also in development in a git hook and then it's
Speaker 2: just you not divide imitated also on cil of people.
Speaker 2: What they forget is they sell it up to run
Speaker 2: on the Magic Quest or Poor Requests, whichever geitos they use,
Speaker 2: but they don't run it daily on the master or
Speaker 2: main branch, which is if you don't deplay every day.
Speaker 2: If you don't match requests every day, then you might
Speaker 2: not be notified about an important secretaries. So it's a
Speaker 2: good idea to actually the way I sell it up,
Speaker 2: if I have the chance to set up anywhere, run
Speaker 2: it twice a day on the master branch, and run
Speaker 2: it on every poor quest MARGC quest M because then
Speaker 2: you all anyways also like weekends, so if it's on
Speaker 2: a weekend, really something on a Saturday, you don't getting
Speaker 2: notified if you.
Speaker 1: Right, and it'll it'll fail the build if if it
Speaker 1: doesn't pass the audit right.
Speaker 2: Yeah, and if it fails a musta but you are
Speaker 2: don't expect the old day, we'll get an need imlification
Speaker 2: or whatever you set up and then you know that,
Speaker 2: oh I need to look into this because something is up.
Speaker 1: Makes sense.
Speaker 4: Yeah, I'm just waiting for the day to have like
Speaker 4: you know, reels autopilot just automatic like if you have
Speaker 4: like a bunch of hobby projects that you're just like, oh,
Speaker 4: like I'm not going to spend any time on this
Speaker 4: for six months, like just like automatically merge any updates
Speaker 4: as it comes and like resolve itself, Like oh I
Speaker 4: would love that and then just come back and then
Speaker 4: you know, if when I'm ready to work on it again,
Speaker 4: at least it's up to date and I can like
Speaker 4: resolve any issues that there are. Right, But you know,
Speaker 4: every single time I go back to a hobby project
Speaker 4: and I'm like, shit, I can't spend any time on
Speaker 4: this because I gotta spend the time update again, and
Speaker 4: then I lose that.
Speaker 2: Like you know, uh, you should very depend I think
Speaker 2: dependab What doesn't You can set it automatic? Yeah you can.
Speaker 2: You can, yeah, yeah, for for a patch level, and
Speaker 2: maybe you can do it for mine, and maybe you
Speaker 2: can do it for every level. I don't know, but
Speaker 2: you can do it for sure, and then yeah it
Speaker 2: is everything. Things might break because you might not get
Speaker 2: it with the test, but there is you never know.
Speaker 2: I don't, right, I don't. Maybe it's just me that
Speaker 2: this is why I also don't trust AI. It's I
Speaker 2: just I trust humans more for some reason, there's some
Speaker 2: human oversight. I trust that process like an order of
Speaker 2: magnitude more than if it's just something wholly automated.
Speaker 1: Yeah. I think it's getting better, but I don't blame
Speaker 1: you there.
Speaker 4: Yeah, yeah, I've been liking the review process so like automate,
Speaker 4: but review, so like you know, well, all just like
Speaker 4: set out a plan and then like the okay, I
Speaker 4: executed all the plan and then notify you okay, review this.
Speaker 4: I did the things right right, and then if you do,
Speaker 4: like decide not to review it, like okay, Well that's
Speaker 4: the same as like working with a coworker that did
Speaker 4: the same thing right and you didn't review it and
Speaker 4: they did it anyway right.
Speaker 2: Yeah, definitely, But also from a human I expect more
Speaker 2: than from a So with AI, my issue is that
Speaker 2: I write a piece of code, right, I asked him
Speaker 2: can you refractor this to me? It speeds back a
Speaker 2: bunch of changes which I need to review. And if
Speaker 2: I ask a junior developer can you work on this feature?
Speaker 2: They work, They submit to polly quest and if they
Speaker 2: are uncertain about some things which they did, they will
Speaker 2: highlight that here is my polly quest, but I'm not
Speaker 2: really sure about this part. Can you review that more totally?
Speaker 2: But yeah, doesn't do that. It's confidently saying this is
Speaker 2: the solution, and they are like, okay, it's like fifty
Speaker 2: lines of changes. Am I going to focus on each
Speaker 2: fifty line?
Speaker 4: You bring up a great point maybe what we're missing
Speaker 4: is a junior AI right, like that has it in
Speaker 4: I am not confident, I don't know what I'm doing.
Speaker 4: And then IT can, you know, be maybe a little
Speaker 4: more cautious.
Speaker 3: I think you're onto something there or.
Speaker 2: Vey or vade what it gives it, because it can
Speaker 2: be confident about some parts which are like basic or
Speaker 2: or it knows it too well. But if you are
Speaker 2: a little bit uncertain about something, highlight that, so I
Speaker 2: carry you that more.
Speaker 1: Yeah. The issue that I run into though, is that
Speaker 1: a lot of times what I get back from AI,
Speaker 1: I'm not confident that A it would flag the right
Speaker 1: things or B that a lot of times I get
Speaker 1: code back that it's like it's like, yeah, like the
Speaker 1: general structure as far as like I have to loop
Speaker 1: over these things, or I have to make this kind
Speaker 1: of a request or you know, call into this API
Speaker 1: is generally correct, and then the rest of it it's
Speaker 1: it's it may as well have written pseudo code, right,
Speaker 1: And it's like it's like you guessed at the method
Speaker 1: name instead of looking it up what a human would do,
Speaker 1: they'd go look it up. How do I whatever? Anyway,
Speaker 1: we're off on a tangent I want to get back
Speaker 1: to security. So so the catabot is in there by default.
Speaker 1: You can use bundle audit if you want instead and
Speaker 1: put that into your CI.
Speaker 2: What else do we get on the change is really
Speaker 2: similar is Brakeman. It's also got a default CI file.
Speaker 2: So Breakman is a static code analyzer for security issues.
Speaker 2: It basically highlights code spots where you might do something
Speaker 2: which is insecure. I think that's also a great addition.
Speaker 2: It gives you false positives, you can ignore those, but
Speaker 2: it at least makes you aver of certain things. That
Speaker 2: saves you from sidy mistakes. It's so easy to make
Speaker 2: a silly mistake which you don't realize you use an
Speaker 2: insect an API and insecure way because you just forget
Speaker 2: about something, and it just saves you from those issues.
Speaker 2: I think that's also a great change or great addition.
Speaker 1: The thing I like about Breakman is that, yeah, it
Speaker 1: gives you false positives, but like all of the commonly
Speaker 1: understood bad things you can do, or the the traps
Speaker 1: that you more easily fall into, it's got all of
Speaker 1: that in there. And so yeah, I might give you
Speaker 1: a false positive and say this is insecure, and you
Speaker 1: look at it and you go, no, I'm not doing
Speaker 1: what you think I'm doing. But it catches the really
Speaker 1: easy dumb stuff.
Speaker 2: Yeah, yeah, definitely. And the next one is which is
Speaker 2: a new feature in this it's the rate limiting, the
Speaker 2: built in rate limiting. Sure you guys heard about that one.
Speaker 1: And I don't know how many times.
Speaker 3: But I don't know how many times I'm built rate limiting.
Speaker 1: I've got an app that I want to build to
Speaker 1: replace a process we went through last year. It's part
Speaker 1: of my political stuff, but letting people register for our
Speaker 1: caucus night in Utah, we get we having like nine
Speaker 1: hundred thousand party members that are eligible to attend our
Speaker 1: caucus meetings, and we got ddasked last year by somebody
Speaker 1: who doesn't like the party. And so I'm wondering if
Speaker 1: something like this will help.
Speaker 2: It could help, but it might not have for a
Speaker 2: DDA setech. I think it's a you would need something
Speaker 2: like cloud fare, which.
Speaker 1: That's what That's what I'm seriously looking at.
Speaker 2: But yeah, so for what this one is good for.
Speaker 2: The thing this one is good for eight limiting is
Speaker 2: save you from creditial stuff in attacks. For instance, you
Speaker 2: know when there is a league password database, and then
Speaker 2: a malicious ouctors will try to use all of those
Speaker 2: logging details on your side to see if the same
Speaker 2: person has an account with the same credentials and then
Speaker 2: they oh, I gotcha, and then they can take over
Speaker 2: doct and do whatever malicius things. And in my talk
Speaker 2: I highlighted a few examples from it's actually now the
Speaker 2: three years ago from twenty to twenty three, it was
Speaker 2: the year before, like twenty three, and Meter the DNA
Speaker 2: they analyze this side, they had an issue with this. Also,
Speaker 2: General Motors had a big issue. They had a bunch
Speaker 2: of account taken over and like Credit partially credit card
Speaker 2: details leaked, and Roku the streaming platform also had like
Speaker 2: half a million of their users access details were leaked
Speaker 2: because of our credentials stuff creditial stuff in attack. So
Speaker 2: I think there's a very good addition trails to prevent
Speaker 2: all of these issues. We already had wreck attack, which
Speaker 2: is a jam. It's a very old jam, but a
Speaker 2: lot of people don't know about that. And this is
Speaker 2: why I really like these changes in rails because once
Speaker 2: it's in rail score, a lot of people are becoming
Speaker 2: aware of these issues, which they these too solve and
Speaker 2: it might not be the best for that team or
Speaker 2: that person, but at least now they are oh, I
Speaker 2: need to think about credential stuffing, and then they find
Speaker 2: out a solution which works for them.
Speaker 1: So is this in RAILS seven to or is this
Speaker 1: in Rails eight.
Speaker 2: It's in Rael seven too. It got some improvements which
Speaker 2: only landed in Rals eight. And it's really simple. You
Speaker 2: add a single line to your controller and you just
Speaker 2: set the You set that the two parameter, which is
Speaker 2: how many requests you want to allow, and you set
Speaker 2: the wedding, which is like the timeframe. Let's say you
Speaker 2: want to allow ten requests within ten within three minutes
Speaker 2: from the same user, and then that's it, and then
Speaker 2: you have great limiting. You can also configure which actions
Speaker 2: you want it to be called on. It's like a
Speaker 2: before filter in the control aft. You can set if
Speaker 2: you want to exclude any actions or if you want
Speaker 2: to include only set in actions. You can also configure
Speaker 2: a custom response because by default it raised a four
Speaker 2: to nine header, and then you can change that and
Speaker 2: just redirect to a page, display a message or whatever
Speaker 2: you want to do. Also another important thing to mention initially,
Speaker 2: but the first implementation used reddis but then it's been
Speaker 2: rewritten and now this storage the back end is any
Speaker 2: rare cash compatible storage can work, so you can use
Speaker 2: the solid cash or whatever you want and you don't
Speaker 2: need to you don't need to have reddie as a dependency.
Speaker 1: I love that move away from reddis.
Speaker 4: The storage patterns across the border just really great to
Speaker 4: see it become more cohesive. I really like this byeline
Speaker 4: to give it a product and say like, hey, you
Speaker 4: know rate limited, biop or whatever you want to filter
Speaker 4: scope to.
Speaker 2: Yeah, if you would want to have something like cloud flare,
Speaker 2: you could achieve that using that parameter. So you would
Speaker 2: set a cookie and then you would rately meet by
Speaker 2: that cookie, and then you can handle more propell adidos
Speaker 2: attack as well. Otherwise, if you do it by the
Speaker 2: ip adidos is usually they use a whole range of ideas.
Speaker 2: It's one client, so if you set a cookie on
Speaker 2: that client, then you can identify the same client from
Speaker 2: a different idea.
Speaker 1: Yeah, I'm liking where this is going for sure. I
Speaker 1: think cloud flare is probably the best answer for what
Speaker 1: I'm looking for, but I like this to manage your
Speaker 1: credential stuffing and things like that.
Speaker 2: Yeah, my only problem with cloud Flare. I love them.
Speaker 2: They're really cool. It's very cheap, but I think now
Speaker 2: they are swallowing a big part of the Internet and
Speaker 2: maybe one day they will say, Okay, now we are
Speaker 2: greedy and now start an extortion amount on everybody. Let's
Speaker 2: hope they never do this, but it happened before, and
Speaker 2: they might say, yeah, now we want all the money
Speaker 2: and now you rely on us. There is nowhere else
Speaker 2: to go, or the small competitors are gone and I
Speaker 2: need to pay us a lot. But let's hope they
Speaker 2: are not going to do that.
Speaker 1: Yeah.
Speaker 2: Cool. And so the next thing I mentioned in the
Speaker 2: talk was the new authentication generator in rails.
Speaker 1: Oh I love this.
Speaker 2: Yeah, well, we had another one before. It's called Authentication zero,
Speaker 2: which is wasn't in reels. It was done by forget
Speaker 2: the name of the guy. He's a Brasadian guy. I
Speaker 2: probably can't even pronounce his name properly. Lazarro Nixon, I think,
Speaker 2: or something like that, but I'm sure my pronunciation is
Speaker 2: not correct, So sorry.
Speaker 1: For Yeah, it was an awesome project.
Speaker 2: Yes it's still it's still a great project and it
Speaker 2: does more. But the building in Rails generator. But the
Speaker 2: thing is, even though the generator was there, other people
Speaker 2: don't know about it. Now that res has a built
Speaker 2: in one, a lot of people are ever, oh, we
Speaker 2: can have an authentication generator, and they might say the
Speaker 2: build in Rails, but is not for me that they
Speaker 2: find the other one or other alternatives. So this is
Speaker 2: why I love getting these features into Rails. And the
Speaker 2: building one in Rails doesn't have registration and what else.
Speaker 2: It doesn't have a few features which you would expect
Speaker 2: from an authentication flow because I think the reason for
Speaker 2: that is the core team believes that they are custom
Speaker 2: for applications usually like sign up. It might it's very
Speaker 2: different for all of applications, so they expect you to
Speaker 2: implement that on your own. But this authentication zero, for instance,
Speaker 2: it generates all of those parts as well. If you
Speaker 2: are into a fully flashed you just want your own code,
Speaker 2: the code to sit in the repository, but you don't
Speaker 2: want to write a line of code. I think that's
Speaker 2: a better option. If you want to have something custom
Speaker 2: and use just Rails generated stuff, then go with the
Speaker 2: built in Rails one.
Speaker 1: Yeah, I'm working on a generator of my own that
Speaker 1: will generate the views. I don't like the views that
Speaker 1: I got when I ran the rails generator, But yeah,
Speaker 1: I mean just it's it's basically I would like to
Speaker 1: build the tool build things that run on top of
Speaker 1: the built in rails generator because I think it does
Speaker 1: a really good job.
Speaker 3: Yep, I'm curious here.
Speaker 4: I love your insight, Greg, I know it's it does
Speaker 4: like passwords as like the default for the generation. Uh,
Speaker 4: how do you feel about you know, passwords with users?
Speaker 4: Like I know there's a lot of talk around this,
Speaker 4: like do we go password lists pass keys for the
Speaker 4: future for a bit, like you know, where where do
Speaker 4: you see like the industry like coming together or is
Speaker 4: it still kind of like a little bit uncertain.
Speaker 1: Or the oaths that's the other one. Somebody else is
Speaker 1: managing your credentials and SAP or whatever it is. You
Speaker 1: have a token from them and you authenticate them on
Speaker 1: the token.
Speaker 2: Yeah. I on both of those cases, I think I
Speaker 2: might not be the mainstream with my opinion. So for
Speaker 2: pest keys, I love peskys. I use a ubiki for
Speaker 2: two factor authentication. I think it's amazing for that because
Speaker 2: for that you can have multiple options. For instance, I
Speaker 2: have a Ubiki, but I have two laptops, so sometimes
Speaker 2: I don't have my Ubiki with me, and I have
Speaker 2: two Ubi keys, but I keep on as a backup
Speaker 2: at home, so I never really that's not in a laptop.
Speaker 2: That's just if I if my brakes, I can use
Speaker 2: that one. So I have multiple authentication two factor autification
Speaker 2: set up at most services. I can use my phone
Speaker 2: within the app on my phone, or I can use
Speaker 2: the Uiki, which is much more convenient when I'm at home.
Speaker 2: I just touch it and then it's done. But for
Speaker 2: whole authentication, I think there are a bunch of things
Speaker 2: which are not so easily resolved, like what are you
Speaker 2: doing with the logging in on your iPhone and on
Speaker 2: your Windows laptop with the same pestky because you contantly
Speaker 2: transferred between divis. You can if you're on iOS and
Speaker 2: Mac with everything, it's it's amazing, it's fine, it's convenient,
Speaker 2: everything is in the whole ecosystem. But what if you
Speaker 2: have an Entrade phone and the MacBook or it's not
Speaker 2: so easy to transfer your credentials between different services. That's
Speaker 2: my main problem with pastkis. It will be probably solved
Speaker 2: eventually in the future, then I will be all for paskis.
Speaker 2: But since then, I think it's not so easy to
Speaker 2: handle all of those edge cases.
Speaker 1: Yeah. One thing that I'm wondering that along the lines
Speaker 1: of what Valentino's asking though, is that it seems like
Speaker 1: when folks credentials get compromised, it's it is the password, right,
Speaker 1: It's hey, here's a username and a password that'll get
Speaker 1: you into the website. So do you favor more passwordless options?
Speaker 1: I mean, that's what the past key is. But you've
Speaker 1: also got like magic links or you know, hey, here's
Speaker 1: an email and we're going to send you one time
Speaker 1: password or any of that. Like is that any more
Speaker 1: secure or is that just an illusion?
Speaker 2: In my opinion, not at all, because if I get
Speaker 2: access to your email account, I have the keys to
Speaker 2: all of your accounts, right, But usually so it's not
Speaker 2: that clear because also if all of the sites you
Speaker 2: signed up for support a password is set by email,
Speaker 2: then I can also take our right. So I think
Speaker 2: the solution for all of this is multi factor authentication,
Speaker 2: because even with pest keys, what if my laptop gets
Speaker 2: stolen and store in the state when it's open, and
Speaker 2: then they have access to all of my all I have, right,
Speaker 2: Usually this is why it should be something you know
Speaker 2: and something you have access to, because my one password
Speaker 2: shuts it down after five minutes or whatever. If someone
Speaker 2: gets access to my loptop, they can't get access to
Speaker 2: my passwords. They can access to my ubiki because it's
Speaker 2: plugged into the laptop, but they don't have the passwords.
Speaker 2: So I still have two things which they can only
Speaker 2: get one of them, save me the email. When someone's
Speaker 2: exited the email, they can take over your raccon. But
Speaker 2: this is the same if it's only pest words, So
Speaker 2: just pestwords on their own. I don't think they are
Speaker 2: good enough.
Speaker 1: So the other piece of this for me is how
Speaker 1: do I put this. I'm super cheap, and so like
Speaker 1: Riverside for example, right, I could set up an account
Speaker 1: for every single one of the hosts to be able
Speaker 1: to start the podcast, but realistically that's a lot more
Speaker 1: expensive than setting up, you know, a couple of generic
Speaker 1: host accounts. But then you know, how do you set
Speaker 1: up third party authentication for shared accounts or two factor
Speaker 1: authentication for shared accounts? That that's been the rub, right,
Speaker 1: and so I tend to not turn it on and
Speaker 1: then essentially just trust the people that I've shared the
Speaker 1: password out to because I don't have a better way
Speaker 1: to do it.
Speaker 2: You can do that. Actually, so I'm working on something
Speaker 2: with a team where we have the same problem and
Speaker 2: the wave has resolved it. You know, if you set
Speaker 2: up two factor authentication with an authenticator app, it's just
Speaker 2: you just need a seed and it generates it token
Speaker 2: based on that seed. So we have that saved and
Speaker 2: whenever you want to share that to favor with someone,
Speaker 2: he gets the seed and he can have the same
Speaker 2: setup on their phone. And then you have authenticate po
Speaker 2: multiple devices for multiple people so they can still have
Speaker 2: the second factor.
Speaker 1: That makes sense.
Speaker 3: That's really cool.
Speaker 1: That's that's been the piece that I've been missing is Yeah,
Speaker 1: it's like, okay, how do I share the second factor
Speaker 1: of two factor authentication?
Speaker 2: Or you can go down the other way, which I
Speaker 2: don't recommend, but it's quite popular. You use something like
Speaker 2: one password where you can share.
Speaker 1: That's essentially what I've been doing because I've been sharing
Speaker 1: the password out of one password.
Speaker 2: Pro and with dead then it's not too factor because
Speaker 2: you have the password and the second factor at the
Speaker 2: same place. Anybody gets access to that one, they have
Speaker 2: everything they need to look I like to separate these
Speaker 2: the factors from each other.
Speaker 1: Well that's the whole idea. Yeah, and may have preempted
Speaker 1: other questions from Valentino, so I'll let them keep.
Speaker 2: On the topic of outsourcing your authentication. I don't think
Speaker 2: that's a good idea. Actually the Q and A somebody
Speaker 2: asked me about this, and Octa is one of very
Speaker 2: popular service for outsourcinger authentication.
Speaker 1: Octa and zero but at zeros owned by Octa these days.
Speaker 2: So yes, So they had breaches in the past, and
Speaker 2: they just had a breach after my conference talk again,
Speaker 2: not a bridge with a security incident, but they had
Speaker 2: a proper breach a few months before the conference, And I.
Speaker 4: Think, yeah, i' kind of like the approach like single
Speaker 4: sign on took in that. It's like, at least there's
Speaker 4: a rollover approach, right, Like, Okay, if they if you've
Speaker 4: been identified of a breach, like you can invalidate everything
Speaker 4: that's in that, right, But.
Speaker 2: If you're a past word nagin and you have unique
Speaker 2: pestwords everywhere, if you are in a bridge, it doesn't
Speaker 2: really matter because they don't have the old.
Speaker 3: Password, right, That's true.
Speaker 2: And my problem with UKTA is their altitude. I think,
Speaker 2: even though they are a security company, they are more
Speaker 2: money and profit oriented than security oriented. That's what I
Speaker 2: see from their behavior. They might not like that opinion,
Speaker 2: but that's what I see, and I think they they
Speaker 2: care more about sales than actually making a security and
Speaker 2: you can see that from the secretitysies they had in
Speaker 2: the past, because some of them is I don't want
Speaker 2: to be rude, or just because everybody makes mistakes, but
Speaker 2: some of it you wouldn't expect from a security company.
Speaker 1: Yeah, I will say so. When I started building top
Speaker 1: end devs, I was using off zero and I had
Speaker 1: two problems. Well I had more than two problems, but
Speaker 1: a couple of the problems came into if they were down,
Speaker 1: I was down. It was one right because nobody could
Speaker 1: authenticate Y. The other issue that I ran into was
Speaker 1: it was way more complicated than just allowing people to
Speaker 1: have passwords in my own system using device or you know,
Speaker 1: building my own these days, I just rolled my own.
Speaker 1: I used the Rails generator and then I just put
Speaker 1: what I want on top of it and so so
Speaker 1: it was just overkill. And then the last issue was
Speaker 1: I mean literally literally anytime I had any kind of
Speaker 1: problem like it. Yeah, it wasn't just the complications, and
Speaker 1: it wasn't just that I was down when they were down,
Speaker 1: but but there were some other issues within just the
Speaker 1: way that I had things set up, and it was
Speaker 1: easy to fall into those problems and it affected everybody.
Speaker 2: So anyway, and sometimes if there's an issue, you can'try
Speaker 2: solve it because it's out of your hands. It's the
Speaker 2: way you implemented their integration.
Speaker 1: But they do a lot of things for you too,
Speaker 1: so you know, they do some level of authorization. They'll
Speaker 1: handle the third party like Google and Apple and Facebook,
Speaker 1: you know, whatever whoever you want to let people log
Speaker 1: in with gethub like, they do all of that, and
Speaker 1: so you don't have to go and jump through the
Speaker 1: hoops with an omnios right there. There are reasons why
Speaker 1: people go for it. You know, they're probably a little
Speaker 1: bit better at security than you are. But you know,
Speaker 1: as you're pointing out, Greg, yeah, you may not know
Speaker 1: the issues that they actually have because you're outsourcing it
Speaker 1: and trusting them instead of being in your own system
Speaker 1: where you can audit and verify it. So exactly, anyway,
Speaker 1: I see people use it. They seem to like it,
Speaker 1: but I think it's for those bigger apps where you're
Speaker 1: really looking for that enterprise level set of features. For
Speaker 1: the things that I was doing, it just didn't makes sense.
Speaker 2: Yeah. I also think it doesn't make sense for most organizations,
Speaker 2: but probably it does for some. I don't know. But
Speaker 2: even then I wouldn't go with doctor for shure. I
Speaker 2: haven't heard of Old zero, which is probably a good thing.
Speaker 2: Probably they didn't have any bread Cheese.
Speaker 1: Acquired zero like three or four years ago.
Speaker 2: So oh so it's basically the same company.
Speaker 1: Now it's more or less the same company. But for
Speaker 1: me and I think this is what you're saying too,
Speaker 1: is do your due diligence if you're going to pick one,
Speaker 1: and make sure that you know why you're going that
Speaker 1: way as opposed to building yourself.
Speaker 2: Yeah, definitely. And one more thing I wanted to mention
Speaker 2: about the Rails Authentication Generator is the reason I really
Speaker 2: like this one because res has a bunch of helpers
Speaker 2: which people don't know about, like has secured password. All
Speaker 2: of these new secure token generation methods and validation.
Speaker 1: Methods are so nice. Use them for here. So I'm
Speaker 1: going to back up for a second, because I love these,
Speaker 1: so I use them for all kinds of things. Right,
Speaker 1: People people think, oh, I have a secure token generator.
Speaker 1: That's you know, so I'm gonna put it in my cookie.
Speaker 1: Is some kind of authentication key or you know, I'm
Speaker 1: going to use it for this other ath and that
Speaker 1: other ath. But you can generate keys for anything, and
Speaker 1: so I've been using it. I'm trying to get to
Speaker 1: the point where I'm running my own premium podcast feeds,
Speaker 1: and it's like, hey, look, if you donate to the show,
Speaker 1: you'll get you know, ad free stuff, right, and so
Speaker 1: you can generate tokens for that. You can generate anyway.
Speaker 1: I don't mean to derail, but this is a really
Speaker 1: really handy feature. And if you if you need something
Speaker 1: that not guessable, then this makes it really easy to
Speaker 1: do it.
Speaker 2: Yep, and verified. It's just built in. It's just super
Speaker 2: easy everything. Yeah. Yeah, And I think that's why it's good,
Speaker 2: because you generate your authentication system and then you read
Speaker 2: through the code and you learn from it. You just say, oh, yeah,
Speaker 2: what is this helper? Never heard of this? I think
Speaker 2: this is also why it's good to have this. It's
Speaker 2: just traises, awareness of seftain Rails helpers and features which
Speaker 2: people wouldn't know about otherwise probably yep. And then the
Speaker 2: next thing I mentioned the talk is it's not really
Speaker 2: a technical change, but it's an important change. It's Raels
Speaker 2: has a new maintenance policy, which is I need to
Speaker 2: read this because I can't say that tell it from
Speaker 2: the top of my head. So every minor releases we
Speaker 2: receive security fixes for two years after the first ree
Speaker 2: is in its series, which means practically, if one point
Speaker 2: one point zero is really is January first in twenty
Speaker 2: twenty three, if we receive secretary fixes until January first,
Speaker 2: twenty twenty five, after that it will reach its end
Speaker 2: of life. So it's I think the maintenance period became shorter,
Speaker 2: which means that you should everybody should take upgrades seriously
Speaker 2: and don't stay on all versions of Rails because it's
Speaker 2: just it's not going to get secretary updates. They make
Speaker 2: exceptions sometimes, but you shouldn't rely on that. In my opinion,
Speaker 2: you should make sure your apps are up to date.
Speaker 1: Yeah, I think a lot of things have changed on
Speaker 1: that front. Two though, because I've worked on a handful
Speaker 1: of apps for clients where I had to upgrade from
Speaker 1: saying rails four or Rails five, right, and those upgrades
Speaker 1: were often rather painful for one. And the other thing
Speaker 1: is is that, yeah, it's just you know, it was
Speaker 1: kind of a giant thing and you had to take
Speaker 1: it on and you know, the maintenance cycle on things. Anyway, lately,
Speaker 1: with everything pasted about Rails six Rail seven, for sure,
Speaker 1: like the upgrades have not been nearly as bad. And
Speaker 1: so I, you know, you're mentioning the maintenance cycle, and hey,
Speaker 1: this encourages people to upgrade, and you know, maybe you
Speaker 1: have a different window to get security patches and stuff
Speaker 1: like that. But the other side of it is is that,
Speaker 1: like I have a whole bunch of Rail seven two
Speaker 1: apps that I need to get around to upgrading to
Speaker 1: Rails eight, and I've kind of been waiting for like
Speaker 1: a couple of patch versions to come out, right, so
Speaker 1: that whatever issues everybody else is finding, good on you folks,
Speaker 1: and I really appreciate the work you're doing and you know,
Speaker 1: and then I can go pick them up. But yeah,
Speaker 1: I from what I've seen like seven to seven to
Speaker 1: one to seven, two to eight, they really haven't been
Speaker 1: that bad. And so you know it's okay. I'll spend
Speaker 1: a few days on this or a week on this.
Speaker 1: If it's a really big app maybe it takes longer.
Speaker 2: But yeah, yeah, it's much better. I did Trails two
Speaker 2: to three upgrades as well, two point three to three.
Speaker 2: That was a big thing about it. A little bit easier,
Speaker 2: four to five, a little bit easier from five on.
Speaker 2: I think, yeah, it's much easier. It's except when you
Speaker 2: go rails eight, you need to ask yourself the question
Speaker 2: what am I gonna do with the front end stuff?
Speaker 2: Are you gonna keep that pocket or are you killing it?
Speaker 2: Because then it might be a bigger change.
Speaker 1: Yeah. The prop shaft, yeah, prop shaft, prop shaft, and uh,
Speaker 1: you know all the stuff that's there. The way that
Speaker 1: Rails eight and Rail seven two, frankly, in a lot
Speaker 1: of ways handles the front end stuff. It is. It
Speaker 1: is so nice, you know, I don't I don't miss
Speaker 1: what it'sprockets don't miss Webpacker. When I moved off of Webpacker,
Speaker 1: I wanted to throw a party because it was so
Speaker 1: much easier. I mean, the issue with Webpacker a lot
Speaker 1: of people had was just setting it up and knowing
Speaker 1: how to do it, but I found myself having to
Speaker 1: tinker with it a lot, and so prop Shaft I've
Speaker 1: just kind of said it and forget it. It's been
Speaker 1: really cool and the.
Speaker 2: Build step is always like, yes, something faz At the
Speaker 2: built step, it's like I need to deal with this. Yeah,
Speaker 2: it was just slowing things down. I also didn't like.
Speaker 1: The important maps. I love them.
Speaker 4: It's funny you don't you don't realize how stable like
Speaker 4: Rails and Ruby ecosystem has become because I mean going back,
Speaker 4: like you know, upgrades, Like you know, I was thinking
Speaker 4: of my first Raels upgrade. I did like a Rails
Speaker 4: one app that was on Ruby one eighty seven, which
Speaker 4: was like the nightmare Ruby upgrade because there were just
Speaker 4: so many drastic changes, right, and so like I don't
Speaker 4: think people realize like what the early stages of a
Speaker 4: framework or a language are, right like, because like the
Speaker 4: stability that we get now likes just a mind boggling
Speaker 4: right like you know, yes, there'll be some depreciation warnings
Speaker 4: and things like that, or like you know, the big
Speaker 4: changes like are really not that big in like the
Speaker 4: grand scheme of things, right, Like if you look at
Speaker 4: like some of the other libraries out there, you're like,
Speaker 4: you know, the whole like back end could get swapped
Speaker 4: out and you'll be like, well, what do I do
Speaker 4: with all this stuff I built? Like yeah, you know,
Speaker 4: it's like incredibly stable now, so it's it's just wild.
Speaker 1: Yeah. Yeah. And for the record, when Greg was talking
Speaker 1: about upgrading from Rails two to three to Rails three,
Speaker 1: that was when they merged another framework called merbr into Rails,
Speaker 1: and so there were just major major changes. I mean
Speaker 1: a lot of stuff got a lot better, but the
Speaker 1: upgrade was painful.
Speaker 2: Oct record was pretty much completely changed. It was a
Speaker 2: lot of Yeah.
Speaker 4: That's a shout out to, uh to Machondra who like
Speaker 4: maintains the Rails are lts.
Speaker 3: Oh stuff.
Speaker 4: Uh, if you're like honestly, if you're out there stuck
Speaker 4: on a Rails upgrade and it's just like not worth
Speaker 4: it to your business, like just pay the service. Rails
Speaker 4: LTS long term support and it's just like they make
Speaker 4: sure that like yeah, they give you the security patches
Speaker 4: and uh yeah, we use that for a couple of
Speaker 4: clients a long time ago, and it just like it
Speaker 4: works incredible out of the box, like turn key.
Speaker 1: Yeah, we have to get them on and ask them
Speaker 1: how that all goes.
Speaker 3: So long?
Speaker 2: Now, sometimes I'm sure it's very tricky to sow these shoes.
Speaker 2: Sometimes for them, I wouldn't want to be in their shoes.
Speaker 1: Yeah, But the same time, I mean it's got to
Speaker 1: be really because I just went to their page and
Speaker 1: they have LTS versions for RAILS too crazy, and so
Speaker 1: I'm going, boy, what what are you having to fix?
Speaker 2: You know?
Speaker 1: And how deep into the weeds do you have to get?
Speaker 2: Yeah, but from a security perspective, I think it's still
Speaker 2: risky to be on the tour to measure because nobody
Speaker 2: really tests. That's true thions. So there are no security
Speaker 2: patches or security issues made public. There might be some
Speaker 2: non public ones which people might abuse, you just don't
Speaker 2: know about them. So I think it's because, like the
Speaker 2: latest version of RAILS, a lot of companies are using
Speaker 2: to get patrition tests, and sometimes issues are upstreamed from
Speaker 2: the resort to a patration test. They find an issue,
Speaker 2: it turns out, oh, it's actually an issue inside of RAILS,
Speaker 2: so we upstream the patch and fix it for everybody.
Speaker 1: Yeah, that's true, But.
Speaker 2: Those old versions I think are not a good idea
Speaker 2: to use. Even though you get some support.
Speaker 1: Yeah.
Speaker 2: Yeah. And then the next thing I mentioned the talk
Speaker 2: is is a bit of a pretty small change, is
Speaker 2: that CBV and CBC was added to the parameter filter defaults.
Speaker 2: But the reason I wanted to mention that in the
Speaker 2: talk is because a lot of people don't know about
Speaker 2: the real parameter filtering, which is a very handy tool
Speaker 2: to filter out anything sensitive from your logs. Like you know,
Speaker 2: when a request comes in with a password in it,
Speaker 2: you don't want that to show up in your logs,
Speaker 2: or if you store social secretary numbers, you don't want
Speaker 2: them to show up in your logs before you encry them.
Speaker 2: And this feature is just amazing. For anything sensitive which
Speaker 2: you don't want to be in the logs, you can
Speaker 2: just study to your initializer and then it gets excluded.
Speaker 2: These are the things which I also think rares excess
Speaker 2: because a bunch of other frameworks don't really haven't an
Speaker 2: easy solution for this problem. But Rasia is just out
Speaker 2: of the books and for years it's it's amazing.
Speaker 1: Yeah. I did have this bite me in the rear
Speaker 1: end once, but yeah, I agree. The way it bit
Speaker 1: me in the rear end was I had a stripe
Speaker 1: web hook key that for some reason wasn't being set
Speaker 1: and it still showed it as filtered, and so I
Speaker 1: didn't know it was empty until I actually like forced
Speaker 1: it to log it out.
Speaker 2: Ah, I see.
Speaker 1: But yeah, this is definitely a best practice. And if
Speaker 1: you get into like hipA or what's the financial one,
Speaker 1: PCI or any of these, they they they will crucify
Speaker 1: you on this stuff if you're not doing it. And
Speaker 1: and the logs are usually an area of vulnerability that's.
Speaker 2: Overlooked, yep.
Speaker 1: And Rails does it by default for all the common
Speaker 1: sense stuff yep.
Speaker 2: Yeah. And then the second half of my talk was
Speaker 2: these are the new features, which wasn't that many, to
Speaker 2: be honest, but still there are spilled small progresses and
Speaker 2: that's all we need, I think. And the second half
Speaker 2: I wanted to highlight to people why I think somebody
Speaker 2: should choose Rails if they want a if they need
Speaker 2: an application with high security standards. And my main reason
Speaker 2: for that is there is a tool for everything you
Speaker 2: would need in the Rails and Ruby ecosystem, like parameter
Speaker 2: filtering which we just mentioned built into the framework, great
Speaker 2: limiting now built into the framework authentication. You have device
Speaker 2: and a bunch of other things, multifactor authentication, a bunch
Speaker 2: of gems you can choose from. It's super easy to
Speaker 2: implement all of these features or I have a list here.
Speaker 3: Or the other thing, which is scripting stuff.
Speaker 2: Oh yeah, yeah, you don't even need to think about it. Actually,
Speaker 2: cross side scripting you need, but cross sideicquest forgery for instance,
Speaker 2: it's just BILS the framework for I don't even know
Speaker 2: which version, like LS it's forever. Yeah, it's so we
Speaker 2: have a lot of things which you just get read
Speaker 2: it for free and granted it's amazing, and other things
Speaker 2: which are not built into the framework. Like if you're
Speaker 2: talking about compliance, one of the the requirements to be
Speaker 2: soked to or ISZO compliant, is that your developers shouldn't
Speaker 2: access anything in production without you knowing about it. So
Speaker 2: if you have a rogue employee, it's not like they
Speaker 2: can just steal whatever they want. They still usually they can,
Speaker 2: but at least you have an auditlog so you can
Speaker 2: pinpoint who was the the malicious actor and there are
Speaker 2: there is a gem from thirty seven Signals called Audit
Speaker 2: nineteen eighty four and Console nineteen eighty four, which is
Speaker 2: if you install that. Anybody who goes to the RES console,
Speaker 2: they need to authenticate themselves, so they need to say
Speaker 2: who they are and why are they accessing the data,
Speaker 2: and then you have an audit trail. So whenever somebody
Speaker 2: accesses production data, you have an audit trail. One important
Speaker 2: thing to know about this, though, is it's advised to
Speaker 2: store these data in a read only database. Sorry, I'll
Speaker 2: write only database, so they can't. Nobody can update the data.
Speaker 2: They can it only rights, but you can't update otherwise.
Speaker 2: If somebody wants to be really tricky, they can just
Speaker 2: Ruby is very dynamics. They can find a way. I
Speaker 2: found a bunch of ways. But now it's much more
Speaker 2: secure than the initial really was. You can find a
Speaker 2: bunch of ways to treat the system and overrite existing
Speaker 2: log entries. But if you store it in a database
Speaker 2: which is only you you block update commands on the
Speaker 2: database connection, then it's pretty secure and safe.
Speaker 3: When did they change that to ride only? That's really awesome.
Speaker 2: They didn't change it. You need to change that on
Speaker 2: change yourself. Yeah, you can't. You can't build it into
Speaker 2: the GEM because you do it on the database level.
Speaker 2: If you build it into the GEM, then you can.
Speaker 2: You might still find a way to override it. In Ruby,
Speaker 2: because it's a super dynamic language, you can do things
Speaker 2: that you shouldn't even think about. That's how I found
Speaker 2: a bunch of things to over to bypass it. Ah.
Speaker 2: But yeah, that's a really good tool for compliance reasons.
Speaker 2: Also startic CAD analysis. That is breakmen. There are other
Speaker 2: tools dependent vulnerable dependencies. We just mentioned bundle aud it
Speaker 2: depend a boat and probably there are others as well.
Speaker 2: CSP content security policies build into else opery directs OPERI
Speaker 2: direct protection is deffault built into THEIRS nowadays. So you
Speaker 2: have you have for every security requirement or need encryption
Speaker 2: active record encryption. It's really easy to do now. You
Speaker 2: don't even need to think about anything cryptography. It's just
Speaker 2: you set your keys and you are good to go,
Speaker 2: and everything is in gypted in the database.
Speaker 3: The only thing that's missing is secret scanning.
Speaker 2: Secret scanning you mean the repository.
Speaker 3: Like something like trouple hog. That's the best example.
Speaker 2: Uh yeah, Well, but you should do that on the repository,
Speaker 2: and there are services or there are tools for that
Speaker 2: for should even in Ruby. I don't know any from
Speaker 2: the top of my head, but I'm pretty sure that
Speaker 2: there are some.
Speaker 4: How do you feel about like storing encrypted real secrets
Speaker 4: in a repol?
Speaker 2: As long as your master key stores safely, it's a
Speaker 2: very hard to break encryption. It's quantum computing. We might
Speaker 2: get into trouble in a few years, but until then
Speaker 2: we are fine and safe. And then you figure out
Speaker 2: how to have to save that. I'm sure not us,
Speaker 2: but someone who's good with cryptography. Then you figure out
Speaker 2: the way. But I think that's perfectly fine. You just
Speaker 2: need to make sure your master key is safe and secure, right,
Speaker 2: and then it also it simplifies the whole process. You
Speaker 2: can use environment bariables, but then how do you handle
Speaker 2: that during the deployment flow? How are you going to
Speaker 2: pull those from secret storage? It all adds complications and complexity,
Speaker 2: a lot of that.
Speaker 1: I've just been doing what Kamal does, so it just
Speaker 1: sticks it on the container when it runs YEP and.
Speaker 2: Comera as good integration with one past word and others. Actually,
Speaker 2: secret storage is like a bit bucket.
Speaker 1: I haven't used any of that because I'm the only
Speaker 1: one that deploys.
Speaker 2: Yeah, then it's yeah, it's it's super easy. If it's
Speaker 2: only you. If it's a team, it gets a bit
Speaker 2: more complicated, but still it's it's not hard.
Speaker 4: So do you have like a a security checklist that
Speaker 4: you run through for REILS apps, they make sure, oh
Speaker 4: make sure all these things are.
Speaker 2: You know, not really to be honest, when I do
Speaker 2: a penetration test, I have a checklist which I go through,
Speaker 2: but it doesn't really depend on a rail step. I
Speaker 2: have some rare specific things which I know I would
Speaker 2: a real set then I need to check this and that,
Speaker 2: But a lot of it is only in my head, to.
Speaker 4: Be honest, I mean to that point, like you know,
Speaker 4: real is pretty secure out of the box, right, Like
Speaker 4: it's not exactly difficult to you know, break that, but
Speaker 4: like it's not easy either, right.
Speaker 2: Yeah.
Speaker 3: I feel like with the REILS new like it's going to.
Speaker 4: Be pretty hard to like do something insecure until you
Speaker 4: start actually like you know, adding new things.
Speaker 2: Yeah, most of the vulnerabilities I see now it's it's
Speaker 2: used to be excesses and it's still I would say
Speaker 2: that's kind of the second, but the top one nowadays
Speaker 2: is authorization. So because it's super easy to make a
Speaker 2: mistake to forget to authorize some endpoints and then it
Speaker 2: can be accessed by someone who shouldn't have access.
Speaker 1: Right.
Speaker 2: So, but I think if you are talking with a
Speaker 2: basic level of security, make sure your authentication is secure,
Speaker 2: make sure your authorization is secure, and then make sure
Speaker 2: that there are no excessises. And that's pretty much the
Speaker 2: rest like secret injections, really hard to have a secret
Speaker 2: injection issue in reals now because eighty percent of the
Speaker 2: APIs in reels in the octave record are safe and secure.
Speaker 2: And for authorization, what I always command is use a
Speaker 2: wideist approach rather than a blacklist a blacklist because it's
Speaker 2: always better to have someone complain about not having access
Speaker 2: to something they should have access to. They're realizing, oh shit,
Speaker 2: somebody has access to something they shouldn't, right, because then
Speaker 2: it's and you need to report it then to your customers.
Speaker 2: That said that, if you have a it's basically a
Speaker 2: data bridge. If somebody can access things they shouldn't.
Speaker 3: Well, one thing, I'm curious.
Speaker 4: I know we're short on time, but I'm curious to
Speaker 4: get your thoughts on Like one common pattern that reels
Speaker 4: doesn embrace this is this like RESTful resources like targeted
Speaker 4: by IDs and like part of The problem with that
Speaker 4: is just like guessable because they're like equally ordered ideas
Speaker 4: like do you do you feel like reels is like
Speaker 4: overdue for like a new pattern there, or like is
Speaker 4: it not worth the effort.
Speaker 2: To like, it doesn't matter even if it's guessing or
Speaker 2: not guessing. I found authorization issues with the u I
Speaker 2: ds because they are not secure. They can be guessed,
Speaker 2: they can be brute forced, and they can be leaked.
Speaker 2: That's the that's the most common thing that you have
Speaker 2: u I ds and you think, oh, it's safe, we
Speaker 2: don't need authorization, but somebody in your API you leak
Speaker 2: the u I d s and then people can just
Speaker 2: find them.
Speaker 1: And security through obscurity.
Speaker 2: Huh, exactly. You should. You should have autodation. That's why
Speaker 2: actually I think pnumeric ideas are better because then it
Speaker 2: forces you to think about authorization. If you're like, oh,
Speaker 2: it's hard to guess, we don't need authorization, Yeah, down
Speaker 2: the line, you see for sure you have issues.
Speaker 1: Well, the other thing is is that typically you're going
Speaker 1: to see your authorization at the controller level, and so
Speaker 1: if you've got good tests around either end to end
Speaker 1: or controller tests, you should be able to pick up.
Speaker 1: You know, a person has what whatever it is that
Speaker 1: credentials them, right, whether it's a membership or a role
Speaker 1: or something. Right, you should be able to test that
Speaker 1: and say, Okay, I with reasonable confidence running my tests
Speaker 1: every day or you know whatever twice a day or yeah,
Speaker 1: or every time I check in. Right, I can say
Speaker 1: with reasonable confidence people don't have access to stuff they
Speaker 1: shouldn't have access to.
Speaker 2: Yeah, but you can still make mistakes, and you can
Speaker 2: use a feature and then you forgot forget to an
Speaker 2: authorization to that. And like I found an issue recently
Speaker 2: during a parent test where they were doing autolitions. The
Speaker 2: same endpoint could fetch one record or a list of records,
Speaker 2: so they were expecting either an ID or an array
Speaker 2: of IDs, and they did the authorization on the on
Speaker 2: the first item. So what you could do You could
Speaker 2: set the ID to something which the user is authorized
Speaker 2: to have access to, and then you get set the
Speaker 2: ideas in the same request to something they don't have
Speaker 2: access to. And then because it thought, oh, it's only
Speaker 2: requesting one item, but actually it returned all of the
Speaker 2: items because the second parameter, the autoidation check was successful.
Speaker 2: But you could still get access to things which you shouldn't.
Speaker 2: It's easy to make mistake, to be.
Speaker 1: Honest, Yeah, I guess, I guess what I'm saying is
Speaker 1: for kind of your baseline stuff if you're testing it,
Speaker 1: you know, But yeah, you're right if your strategy isn't
Speaker 1: well thought out and your test only tests that your
Speaker 1: strategy works, yep.
Speaker 2: Yeah, this is why I think gems like bundit is
Speaker 2: really useful. Because it bunded, you can turn on a
Speaker 2: feature which we eraise an exception if you don't call
Speaker 2: the authories. I think it's called authorized the method in
Speaker 2: a countra action, So it forces you to have out
Speaker 2: ridition in every end point and if you don't, then
Speaker 2: you might make a mistake and then it will warn you.
Speaker 2: And also it really like you can do a widely
Speaker 2: stopproach easily with that one. So nothing can be accessed
Speaker 2: by anybody, and you explicitly grant access to certain records
Speaker 2: right for certain conditions.
Speaker 1: Yeah, all right, cool, Well, is there anything else you
Speaker 1: want to make sure that people know before we do
Speaker 1: our picks?
Speaker 2: I think that's it. Basically is still a great choice
Speaker 2: for security in my opinion. But still you need to
Speaker 2: be aware all the time and be on the lookout
Speaker 2: because it's easy to make a mistake. Nobody to blame
Speaker 2: for that. We all make mistakes and we should learn
Speaker 2: from them and get better.
Speaker 1: Yeh, all right, well let's go ahead and do some picks. Valentino,
Speaker 1: you got some picks for us?
Speaker 3: Oh yeah.
Speaker 4: So I was at the last New York City Ruby
Speaker 4: AI meet up in a happy hour and demo night,
Speaker 4: which has now been consolidated into a nice Artificial Ruby event.
Speaker 4: So I gave a talk on a project I'm working
Speaker 4: on called ruby Tuner to try and fine tune an
Speaker 4: ll M specifically for Ruby code generation.
Speaker 1: And I.
Speaker 4: Have this whole framework built that wraps Python basically to
Speaker 4: start with the idea of over time moving it away
Speaker 4: from Python as the new Ruby features start to become available.
Speaker 4: And so I showed showcase kind of like the whole
Speaker 4: process and to end of fine tuning a very specific
Speaker 4: contrived example of turning a u r L into markdown
Speaker 4: and then getting.
Speaker 3: A response out of it. So it's a lot of fun.
Speaker 3: There's a new event in March.
Speaker 4: I recommend signing up for at Artificial Movie dot AI
Speaker 4: and check out Ruby sooner and then just like something
Speaker 4: really fun and because I always share something very specifically ai.
Speaker 1: Uh.
Speaker 4: Peter Cooper has been like diving deep uh and he
Speaker 4: runs the Ruby Weekly.
Speaker 1: Uh.
Speaker 3: He shared this really.
Speaker 4: Fun and kind of hilarious prompting strategy for basically creating
Speaker 4: a group of specific authors of software. So he has
Speaker 4: like Paul Graham and Linus Torvald and David Hannamer Hansen
Speaker 4: and like kind of made personas for each of these
Speaker 4: characters and then got them into a prompt to like
Speaker 4: argue over very specific implementation strategy at a very detailed level.
Speaker 2: And then.
Speaker 4: And he shared the prompt that he used for it,
Speaker 4: and like it's it's kind of fun to uh, to
Speaker 4: play with this, and it like brings in kind of
Speaker 4: like the a combination of mixture of agent or a
Speaker 4: mixture of experts as well as like planning execute, like
Speaker 4: combination of those two. It's just like really fun to
Speaker 4: see that kind of stuff of all. And like see
Speaker 4: a panel of judges, judge thinks in a simulated way.
Speaker 3: I recommend checking that out.
Speaker 1: It's just fun. That sounds that sounds so funny. I'm
Speaker 1: gonna go ahead and throw in some picks. So first
Speaker 1: of all, I do a board game pick or a
Speaker 1: card game pick this week. I'm gonna be picking a
Speaker 1: card game. It's called The Gang. It is essentially it's
Speaker 1: Texas Holding Poker. Cooperative Texas Holding Poker. So what you're
Speaker 1: trying to do is you are trying to sorry, I'm
Speaker 1: trying to copy and paste the link and while I talk,
Speaker 1: you're so you're all playing Texas hold them. So you
Speaker 1: have two cards, you flip over the all that stuff
Speaker 1: right that you're normally do, right, So, and then what
Speaker 1: you do is, once you have your cards, you can
Speaker 1: there are tokens out. There's one for each player, right,
Speaker 1: so if you have five players, there's a five star
Speaker 1: token of four star, three star, two star, one star.
Speaker 1: And so what you're trying to do is there's no
Speaker 1: bluffing in this game, because what you're trying to do
Speaker 1: is you're trying to get the tokens to the right people.
Speaker 1: So the five star token is with the person that wins,
Speaker 1: and the four star token is with the person that
Speaker 1: would come in second, right, third, fourth, fifth. We played
Speaker 1: it with three players, so we you know, it was
Speaker 1: just you know, three tokens. So anyway, so you grab
Speaker 1: the token that you think you deserve and then somebody
Speaker 1: may say no, I think I think I have that, right,
Speaker 1: And so usually it's the top one that gets passed
Speaker 1: around them a lot in the bottom one that gets
Speaker 1: passed around a lot. Right. So it's like, you know,
Speaker 1: I look at my cards. I can't remember the pocket cards.
Speaker 1: I think is the term? Right, I have a two
Speaker 1: and a three. I know that I'm you know, I'm
Speaker 1: probably not going to win, right, But as you flip
Speaker 1: over the river, maybe you flip over a two and
Speaker 1: a three, right, So now I have two pair. Now
Speaker 1: I have a good hand, and so you know, then
Speaker 1: I may be more aggressively grabbing the top or next
Speaker 1: to the top, you know, and so and you can't
Speaker 1: talk about what you have, but you know, so somebody has,
Speaker 1: you know, three of a kinding kings, right, they may
Speaker 1: more aggressively take that five star token back when I
Speaker 1: grab it, and but I can take it back from them,
Speaker 1: and then they can take it back from me, and
Speaker 1: so then I may be looking at it and going, well,
Speaker 1: I have two pair, but they're kind of crappy pairs,
Speaker 1: so maybe they do have something better. And then as
Speaker 1: you flip over cards, you every time you flip over cards,
Speaker 1: you put more tokens out, and so you can see
Speaker 1: where people are changing what they want to do. And
Speaker 1: so a lot of times, right you'll flip over a
Speaker 1: ten and some who was kind of not sure where
Speaker 1: they were all of a sudden is really aggressively saying
Speaker 1: I should get the top one. And it means that,
Speaker 1: you know, my hand went from having nothing to having
Speaker 1: a pair or something like that, and so you're kind
Speaker 1: of trying to read the table and figure out what
Speaker 1: it is. And the way you win is you get
Speaker 1: three in a row or not three in a row,
Speaker 1: but you get three correct before you get three incorrect,
Speaker 1: and that's pretty much it. And then there's a deck
Speaker 1: of cards, and we only played with a handful of these,
Speaker 1: but there's a bunch of cards that put restrictions on
Speaker 1: what you can do right, and so maybe it takes
Speaker 1: away a round of tokens where you know you would
Speaker 1: get more information or things like that. So anyway, it
Speaker 1: was a lot of fun. The gang board game Geek
Speaker 1: has it as a weight of one point sixty four,
Speaker 1: so it's pretty approachable for you know, most gamers. I
Speaker 1: think my kids, you know, I don't know if i'd
Speaker 1: play it with my kids. Because I'd have to explain
Speaker 1: poker to them, and mostly it's that I would have to, like,
Speaker 1: you have to explain the statistics and why this hand
Speaker 1: beats that hand and how to figure out right. So anyway,
Speaker 1: that's where it gets complicated, is just knowing which hand
Speaker 1: beach which hand and then recognizing I have a straight
Speaker 1: or I have a flush or I have you know, whatever.
Speaker 1: So anyway, fun fun, fun fun stuff. We played it
Speaker 1: after it was readily apparent that the Eagles were going
Speaker 1: to win the Super Bowl, so we played it for
Speaker 1: like an hour. By the way, go birds anyway, So
Speaker 1: that's my pick there, and then the other pick I
Speaker 1: have is I'm pretty aggressively pulling together Ruby geniuses. I
Speaker 1: have meetups planned starting on the twenty fifth of February.
Speaker 1: We're going to be getting into all kinds of stuff.
Speaker 1: There's going to be a book club at the end
Speaker 1: of March, and we're reading the O'Reilly book on prompt
Speaker 1: engineering for AI, you know, so just diving into a
Speaker 1: whole bunch of stuff. Basically, it's meetups. I'm gonna set
Speaker 1: up a discord channel for each of them, right so
Speaker 1: we can collaborate with that. You get discounts on summits
Speaker 1: that I'm putting together. Right, They're not doing Ruby comp
Speaker 1: this year, so I plan to put on a summit
Speaker 1: about when they would do that, and I have people
Speaker 1: show up and speak at that, you know, So just
Speaker 1: just stuff like that. I'm trying to think because ultimately,
Speaker 1: I guess the other thing is is if you sign
Speaker 1: up by the end of the week, which means that
Speaker 1: I guess people we didn't go live. So anyway, I
Speaker 1: was also offering if you had questions, you could text
Speaker 1: or send me a voice message and I would get
Speaker 1: back to you and you would get that for six months.
Speaker 1: But anyway, so yeah, so it's it's the book club,
Speaker 1: it's the meetups, it's the the collaboration with other people.
Speaker 1: Just the ability to kind of get feedback on what
Speaker 1: you're doing or get help when you need it. These
Speaker 1: are the things that really came through for me when
Speaker 1: I was newer programmer. And what I found is that
Speaker 1: even as a senior developer, I'm craving that kind of
Speaker 1: interaction anyway, and so you know, getting a bunch of
Speaker 1: people in and Okay, what's new, what's going on, things
Speaker 1: like that, and then finally I'm also lining up. Some
Speaker 1: of the meetups are going to be with people that
Speaker 1: are on the show, right, so you know, I've asked
Speaker 1: some of our past guests to do them, and we're
Speaker 1: going to start doing some of those in March or April.
Speaker 1: So the first handful, I just wanted stuff on the
Speaker 1: calendar that people were asking me for that I could teach,
Speaker 1: and that way I didn't have to worry about whether
Speaker 1: or not I could fill those meetups with other presenters.
Speaker 1: But yeah, we're going to have a lot more of
Speaker 1: that because there are a lot of people who know
Speaker 1: a lot more about stuff than I do. So anyway,
Speaker 1: you can go get at rubygeniuses dot com and yeah, Greg,
Speaker 1: what are your picks?
Speaker 2: I have two picks. One is a gem got Pundit,
Speaker 2: which we just mentioned because I think it's really good
Speaker 2: for outright to handle authorization rails app. It's a good
Speaker 2: help and it helps you to solve a bunch of
Speaker 2: issues easily or a bunch of problems. So that's one
Speaker 2: of the picks. And the other pick is a bit
Speaker 2: of a self plug, which is I'm working on a
Speaker 2: course for almost a year about security for rals developers,
Speaker 2: and now I'm close to get it ready and publish it.
Speaker 2: And it's already in on free sale, and once I
Speaker 2: record the video videos fit it's basically the written version
Speaker 2: is pretty much done. I just need to record the
Speaker 2: videos and then I will publish it. And I hope
Speaker 2: it's going to be useful for people to learn more
Speaker 2: about the caveats of security things in rails.
Speaker 1: Cool. Where do people find it?
Speaker 2: Uh? Just go on my website. There is a link
Speaker 2: somewhere on it. Probably I should I should put the
Speaker 2: bonner on it, but you can find it on my website.
Speaker 2: There is a link I think at the top somewhere
Speaker 2: some great.
Speaker 1: All right, cool, we'll put a link in the show
Speaker 1: notes too, and that way people can go and keep
Speaker 1: an eye out for it.
Speaker 2: Great.
Speaker 1: Thank you, Yeah, thanks for coming.
Speaker 2: Thanks for having me. It was fun again.
Speaker 1: Yeah all right, Well we'll go ahead and stop here,
Speaker 1: wrap it up until next time, folks, Max out