Coding Blocks - PagerDuty’s Security Training for Engineers

Episode Date: December 20, 2021

We're taking our time as we discuss PagerDuty's Security Training presentations and what it means to "roll the pepper" while Michael is embarrassed in front of the whole Internet, Franklin Allen Underwood is on a full name basis, and don't talk to Joe about corn.

You're listening to Coding Blocks, episode 174. Subscribe to us on iTunes, Spotify, Stitcher, wherever you like to get your dillies at. That's probably where we're at, I'm sure. Right, Jay-Z? Am I saying it right? Yeah, please. Thank you. Thank you for recognizing.

And, yeah. All right. Visit us at codingblocks.net, where you can find our show notes, very good show notes, examples, discussions, and more. Send your feedbacks, questions, and rants to comments at codingblocks.net. And you want some tweets? We got tweets. Head on over to Twitter at Coding Blocks and we'll send you some tweets. And we also have a webpage, codingblocks.net.

You can find social links and other dillies at the top of the page. With that, I'm Joe Zach. And I'm Michael Outlaw. And listen for this. Here it I'm Joe Zak. And I'm Michael Outlaw. And listen for this. Here it goes. You ready? And I'm Alan Underwood. Sounds just like him, right?

This episode is sponsored by Linode. Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines. I came in third this time. That's interesting. That was, that was odd. Yeah.

I'm assuming that like, uh, Joe had a reason for making you third there. Right. It caught me off guard. I was like, Oh, I just,

well, that's why I decided to have fun with it. I was like, it's not normal. So I was like, okay, that's good. But yeah.

Who's doing the topic intro? Oh, well, I guess, I mean, I was thought we were already doing this, okay, that's good. But yeah. Who's doing the topic intro? Oh, well, I guess. I mean, I was thought we were already doing this, but yeah. So we're going to talk about security. Nice. Did you see how I titled the episode? Did you see how I titled it in the show notes? No.

Okay. Oh, awesome. the episode did you see how i titled it in the show notes no no okay oh so for all the south park fans out there uh like you know obviously we put a little behind the scenes thing right we put our show notes together and kind of follow it together so we can know you know who's where and talking about what uh as we go through the show and which is crazy right because you've heard how long some of these shows run you're like these guys actually have notes to do this yeah and but i i titled this one you will respect my security because if you're thinking about like south park i'm not going to try to do a cartman impersonation my it's not nearly as good as my alan impersonation come on it's the holiday season give the listeners what they want sir

please just back up from the microphone first no hey have you ever heard like everybody has like a cartman impersonation and they all sound awful no have you never noticed that like yeah so no i you got it okay every okay fine Let's all do a Cartman impersonation. How's that? I don't even know what Cartman sounds like. I don't watch South Park. What? It's been like 20 years since I've seen that.

Okay, I think you guys are just setting me up so that I'm the only one that would even try to do it. So forget it. It's done. Howdy ho! That's Mr. Hankey. I thought it was Cartman. That was the last episode I saw. Howdy ho! That was Mr. Hanky. I thought it was Kermit. That was the last episode I saw. Howdy ho!

That was good. That's Mr. Hanky, the Christmas poo. He loves me and I love you. So what about Kermit? Come on, what does he sound like? Why would you guys embarrass me in front of the whole internet? That's the goal they're gonna do it with you everyone okay everybody the only way we're gonna get a lot to do is if we all

do at the same time it's you and your cars your bicycles doing dishes let's all do at the same time that's right one wait he's drinking one two i i can't i can't i can't. I can't. I can't even remember how it would go. Oh my god. Let this all down. Oh, fine. I'll make it awful sound like... Let me think about this. Hold on. I'm trying to even remember what... No, kitty! How about something like this?

No, kitty! That's my papa! That's pretty good. No, that was awful. That was awful. Well, we'll fix it in post. We'll drop in a real one. Yeah, okay. Why didn't you tell me we could have done that from the beginning? I would have done it a long time ago.

That's amazing. Longest show intro ever. Alright, so before we get into the regular show, though, and now that we've done that, we do like to thank those who have taken the time to leave us some reviews. So, um, and iTunes,

are we putting outlaw on the spot again here or. Yeah. Yeah. So there we go. Okay. You got to read it as Cartman. Uh, does he know how to read this so like i don't know that would work uh i i have a hard enough time trying to pronounce these period now i gotta like do

some other voice with it so uh Goofy W. So, yeah. However that would be in Cartman speak. Total Wine. KPBMX. And Viv or Viv. Yes. Very nice.

Excellent. All right. And hey, I also got to remind you that jamuary is coming up the game jam is coming up the sign up page is there so if you want to participate make a game you can work in teams work on your own do whatever you want

you know make a lot of I don't care but you should sign up and do it because it's going to be fun and there's lots of cool games really cool stuff that came out of last year and there's going to be really cool stuff that came out of this year so should sign up and do it cause it's going to be fun. And there's lots of cool games, really cool stuff that came out of last year. And there's gonna be really cool stuff that come out of this year. So go sign up and, uh, just have fun,

especially if this is your first time. Yep. And the link will be in the show notes, but also I believe Joe Zach, I think you had this set up to where if you go to coding blocks.net and click on the events, uh, link at the top,

there's also a thing there as well. Yeah. And you also go to coding box.net slash game jam. And we'll always go to, you know, assuming we have more game jams, I'll always go to the current game jam. So you can sign up or go to coding box.net slash game jam.

Excellent. So I had a thought for you guys a a little bit off topic here related to Securita. But do you think it is bad practice if you introduce code that is only used or only necessary for your unit tests? Is that a bad thing? No more than 5%. Wow. He put a number on it. This is from the math of my chicken.

Could you give me an example of what you're talking about? When you say extra code, what do you mean? Extra code that is not in the test library or in the test methods or anything like that but if you include code that that you need for your tests and that's literally the only thing it's used for so i can give you a concrete example if you want i'm sorry i didn't mean to cut you uh yeah i'm debating whether or not i want the concrete example. I think so. I think if this, this is just coming straight off the cuff.

I think that if the code in your main classes are only ever used by the unit test, then I think that you should refactor the code in a way to where it's being used by both the unit test and whatever's using that. I think now, now if you give me your concrete example, I might change my mind, but that's if,

if the code in the main class is only there for a unit test, then I feel like the, the class is not testable as it should be. So this is okay. Go ahead. Well, I was just gonna say like i can imagine cases where you're like maybe you want to create a new constructor that doesn't require variables that you would generally very you know require maybe it um kind of stubs off some stuff or allows you to pass in uh additional configuration that you have hidden by the class in order to kind

of like override stuff and make testing easier and i'm okay with that sort of stuff as long as it's small i just don't want to see a whole ton of code now i don't have to go like rooting around to find the meat of it that's why i say like something small you know like less than five percent so here here's my situation and you tell me what you think so and this is going to vary by language because like Kotlin developers, for example, you're going to laugh at me. I'm like, you're silly C sharp example. But in my test, what I wanted to do was equality checks. And so I wanted to be able to say like, hey, I have this class. And like, if I do this action that the, the object that's returned back equals

this, right. And the, I could have written in the test harness itself, like code to go through and inspect every individual property and, you know, say like, Hey, does property one equal property one and the other and, you know, et cetera, et cetera, et cetera, et cetera. And instead what I did was on the class itself, I just went ahead and implemented I equatable and did it there inside the class. And my thinking was, well, I don't know if there's ever a need that we will want to do an equality check on this object type outside of the unit test. But if there, if we ever do, then it's already there. Like you could just say this object equal, equal that object and, you know, get it back a Boolean result. Right. And at least for the unit tests, it, you know, definitely works, but there was something dirty about like adding in on an object, right,

the IEquatable interface implementation that's, you know, at the moment not being used by anything else. Gotcha. So, yeah, I would not fail that pull request. You know, that's fine with me. I think you could probably have made it an extension method and just had it live in the test. But if there's more than one test then that gets annoying right so yeah i would say it's fine i would i would allow it yeah honestly for me in that situation you're doing something that's almost a standard used type thing like people will say does this

object equal equal that object so i don't feel like object? So I don't feel like that was on, I don't feel like that was extra code just for a unit test. I think that's actually usable code, even though you may not be using it right now, it's kind of a standard operation that you'll see on objects. So yeah, that, that, that doesn't rub me the wrong way at all. Yeah. I mean the example you gave with the extension method specific to C sharp, you can't implement the interface as an extension method.

So you would be writing your own kind of dirty, you know, equal statement in order to do that. Does that make sense? Or you'd have to do a wrapper class in your test, like something like that. Yeah, your comparable thing, I like that. Yeah. You're, you're a comparable thing. I, I like that. I think that's perfectly fine. That's not like writing a bunch of code, um, like custom code to make something work. Yeah, no. And here's the beauty. Uh, here's a free tip of the week for you. So I think we've talked about writer being like our default go-to for a while now, or maybe we haven't. But if we haven't, hey, shout out to JetBrains and Rider, because that's definitely been like my go-to for any C-sharp kind of work here for the past several, several, several months. And if you implement something like an I equatable, if you just like add it to the

definition of your class, like right away, you get the little squiggle saying like, Hey, you haven't implemented it. And you're like, yeah, duh. I just literally typed it. Of course I haven't implemented it yet, but you can click on the little hammer icon to fix the problem for you in writer. And it'll say like, you know, visual studio would be like, Hey, do you want me to just go ahead and stub out these methods for you?

And it would like add a whole bunch of not, not implemented exceptions into each of the methods of the thing. Well, at least for I equatable, if you do that in writer, it'll prompt you and say, what variables do you want to be taken into consideration as part of the comparison? And you can, it'll bring up every property and you can select from it and then it'll fully implement every one of the methods for you.

Oh, that's nice. That's great. That is nice. Like, and so now we wonder how GitHub, I, uh, uh, what was that we wonder how GitHub AI thing, how that could even be a thing, and this is why. They stole JetBrains code. Right. What is that called?

Jeez. I need to check my email. I probably have access to it now. I can't remember anymore. Copilot or something like that? Copilot, yep. Yeah. And one more thing before we get out of the news um i thought this was pretty awesome so jamie taylor who is a huge friend of the podcast and also in the slack community and all that which by the way if you're not in there you should be because there are just

tons of amazing people in our slack channels um but jam Taylor is a Microsoft MVP now for the first time. So yeah, congratulations. That's awesome. I have a sound effect for that. I should have hit that. Hit it. Hit it. I don't know which one it is off the top of my head.

Like, why'd you have to put me on the spot again? You want me to do Cartman? I should have just kept my mouth shut. Why did I even say anything right um so yeah definitely if if you don't know who jamie is like he he does a couple of podcasts that are awesome he does the dot net core podcast he also does tabs and spaces we'll have a link to those in the show notes as well as to his own website his business website he is a consultant over in the uk so if you need any um coding done and and you're a c sharp.net shop you know give him a holler oh was i on time was i's good. Was my timing good?

Okay. Yeah, Jamie, hit me up about Resident Evil Village. I want to talk to you all about it. First person rules. Oh, this is the Waffling Tailors podcast also, right? Yeah. So. All right.

So let's talk about some Securita. Securita. So this. Do you want to hit record? i just saw that we probably should yeah yeah i don't know what those symbols mean hold on oh yeah sorry hold on allowed to record all right i just let you uh record all right it's gonna do that thing so nice all right hopefully all that is still in the show yep all right you're on again yes yeah okay so this came about this episode came about because of uh some uh slides that we came across. There was a presentation that we stumbled across that PagerDuty gave that was for – they gave two versions of the presentation, but it was for their internal team, and they made

one that was more technical and one that was less technical for related to everything security but being the awesome people that they are they decided to also make a public version of this presentation so we'll have links to all this in in the show notes i haven't found um if they had a video of it because that would be awesome to find but um, um, you know, if you hear this episode, um, you can find the links. And if you ever wanted to, like, you know, if you're like me and you try to explain like to your parents, like, here's why you shouldn't click those links, like, right. Or like, here's what you should look for. Uh, there's some like really good stuff in there and like even the one that was for the non-engineers which i think they called it for everyone then um

you know they did a i thought a very good job of making it um informative yet not, uh, getting too lost in the, in the details of like how the things work or whatnot to where like, it would be easy for people to understand, you know? Very cool. So what we do with things that are easy to understand and not too far in the details, we're going to totally destroy that. Oh yeah. This is like 13 episodes, three hours long. Right. I think there's 12 slides in the deck. So this should be like 18 hours of content. Come back in 2024.

We're still talking about it. Right. Hey, just to stop the show one more time. Sorry. I just realized that we should probably have a content warning because although PagerDuty is a great name for a company and really kind of helps you understand what they do very quickly uh it can uh trigger some unhappy emotions in certain developers uh you know just the name trigger uh sorry the name page duty sends a shiver down my spine i even just say it now like uh i just kind of get a little nauseous a little dizzy the

world starts spinning the thought of having a pager going off at you know three in the morning it's just kind of scary so maybe we should have a little something in front to let people know that we're going to be doing this to them yeah like uh like uh if something was like you know really gross you know and they're like wait before you click on that like right yeah i mean honestly when outlaw suggested the topic he said pager duty and they're like wait before you click on that like right yeah yeah i mean honestly when outlaw suggested the topic he said pager duty and i was like i don't really know that i want to talk about that yeah and so uh you just pass the pager around and it's your turn so no yeah yeah all right so yeah go ahead go ahead blah blah blah blah Blah, blah, blah, blah, blah. Words. All right.

Good. And then Alan speaks. All right. So, so yeah, we're going to learn about this stuff. And really what we're going to talk about is the engineering side of things, the, the technical parts of this, and it's mostly vulnerabilities. If you guys, if anybody's ever listened to our OWASP show that we did, um, almost a decade ago or something. Yeah. It was like a while bit back. It's been a while back. Anybody's ever listened to our OWASP show that we did almost a decade ago?

Episode 7 or something? Yeah, that was like a while back. It's been a while back. This is sort of similar to that in that these are some of the vulnerabilities and things that you need to be aware of as a developer. Oh, so the first one, the first thing that they talk about here that is awesome, and which, by the way, we're going to talk about the vulnerabilities and then also how to um exploit them because that's in all honesty as an engineer knowing about vulnerabilities isn't the same as knowing how they're done right it's it's like driving a

five speed for the first time you can know that there's a clutch at a brake and a gas pedal down there but until you've actually put your feet on those things, you don't know how they work. And so it's probably worth this example, right? Um, it's probably worth going and trying to do some of this stuff yourself. Um, Jay-Z, you actually did something, some goat thing that OWASP had or something. Heck yeah. Web goat. Um, see if I can find that, but it was basically a website that you would stand up that had vulnerabilities. And so your goal was to go in, poke around at this website, find the vulnerabilities, basically do a little write-up on each one, which is really cool.

And yeah, they still have it. Cool. So we'll have a link to that as well. But it's, again, doing some of this stuff will help you out more than just hearing about it. So with that said, one of the things that I thought was awesome that this guy led off with in his slide deck was he mentioned that, you know, some people would be like, well, I'm using a framework. It takes care of all that. Right. And it'd be great if you could just bury your head in the sand like that.

But that's not how it works. Don't be that person. Right. An example of this is, did you guys hear about the recent thing with Grafana? Uh, I saw that Grafana did have one, but I didn't go into the details of what it was, but it was in like the latest eight X versions. Yeah. They have a zero day in there that was pretty nasty. So again, Grafana is an amazing tool, right?

And it does a lot of things for you, allowing you to set up dashboards and charts and all that kind of stuff. But just saying that, oh, this thing does everything for me is kind of blindsiding yourself because when something comes up, you may not know how to deal with it. So it's like, I don't need to sanitize my inputs before I pass it onto my database because I'm sure that the library I'm using, you know,

I'm using Dapper to, to parameterize my queries from C sharp into, uh, Postgres. I'm sure it'll handle all of them, but you know, you could like help yourself out, you know,

and also not trust entirely on it. Right. Yeah. Be aware of what's happening. Right. And, and one of the things that this guy said that was, that made a lot of sense is what, even if you are using a framework and there is a really nasty vulnerability that could adversely affect your business or your personal software, whatever it is that you're using, you may not be able to wait for a patch to come out, right? So that company knows about it. They're going to release one on the third Tuesday of next month.

You may not be able to wait that long. So you might actually have to go patch it yourself as best you can, right? As it relates to security vulnerabilities, though, like the de facto standard, as far as I know of it, is 90 days. Right. The company, if it's responsible disclosure, a security researcher finds it, it's not like out in the wild yet or known to the public or a zero day, then, you know, it gets disclosed. The company generally gets 90 days before the researcher will release the information on how to do it. And usually just knowledge that there is a vulnerability there can often at times be enough for those that might want to take advantage of it to know, oh, if I go looking in this area,

I can find this vulnerability. And, you know, obviously sometimes the security researchers will post more information than maybe they should have or prototypes and examples of it. But yeah, so it, so in terms of the waiting,

it could be depending on, uh, how that, uh, vulnerability is discovered and reported. It could be longer than a month. If you've never looked at one of these before, just like Al said, there's a lot more information on it, but that information is designed to help you understand

what it is so you can, like Alan said, kind of mitigate against it. So if you can block a certain port in order to prevent the attacker, do something else in the meantime until they get an official fix. I also wanted to say that we're not advocating for writing your own stuff just because you know you might get something kind of snuck in on you because the benefit of using tools and open sources that other people find problems and they post it and you get notifications and emails about it rather than just not knowing when there's a problem with your stuff i just meant like in terms of like sanitizing your inputs though like if you have a form and you know, you're only ever expecting a number, then why not just limit the, the field to where it'll only take numbers and save yourself some trouble, right? Like, you know, instead you're going to write something to hope

that you can, you know, catch everything and never have a problem and, you know, then rely on, uh, a library to, to do that parameterization for you when it's like, Hey, you could, you know, then rely on a library to, to do that parameterization for you when it's like, Hey, you could, you know, make it a lot easier on everybody. If you'd like to start it from the beginning with that, right?

Yeah. Client and server. Make sure every step of the way that it's a, that it's sanitized. You don't want to rely on the form requiring a number and not worrying about sanitizing. I did want to call out though, that like you were talking about that,

uh, uh, like a good thing or the best thing or whatever. However you phrased that Alan at the start where with what the author started on this, like how did you not start off with the way he social engineered a manager? I didn't see that one. Really?

It was like slide one. I got to read this because this is amazing. Like he says, no way. This is a quote from, from a security enthusiast manager. No way. I'm giving you a quote after you made fun of me in the quote for the last training. Training was good though. I did see that.

I'm sorry. Yes. Um, I do want to echo what Joe's I'm sorry. Yes. Yes. I do want to echo what Joe Zach said, though. By no means does this mean don't use frameworks. But please don't ever think that that's the takeaway from what we're saying. Just don't be naive and think that the framework is going to handle everything for you. You still need to be responsible for things that you're releasing out into the wild wait what if it's an engine it's even more important than i was calling back to the previous episode never mind

right what's an engine versus a framework versus a library versus a yeah yeah oh okay so here was another thing that i thought was interesting and this is probably good words of advice, is you should never use the excuse for not doing something securely. And, oh, this was just for a hackathon, or this was just for a proof of concept, right? Because half the time, it seems like those things turn into production code. And if you were lazy up front with that stuff, you may have forgotten about it and you don't come back and address it. Right. Or you end up like coding yourself into a corner to where, you know, it becomes really difficult to go back after the fact and add things. And then somebody decides to make it production and won't give you the time. And you're like, well, okay, I guess I'm under the gun because

of a deadline. So, I mean, you liked it as it was, so I'll just put it in. Yeah. And they were talking about things like when they were saying specifically, don't do things that are just kind of wrong. Like one of them was don't disable a firewall to get your stuff done. Right. Cause if you do that, then you're starting off in a position that's not realistic, right? Yeah, and that's the idea of start left. And so from day one, your stuff is good and secure, and you're always keeping it in mind. Man, that is so hard in practice,

especially when it comes to certificates and stuff and authentication between different services and everything. Gosh, it's so hard to get it working just with no security. But everything you say about it is totally right. It's just hard to imagine like a company hackathon. And first thing you're talking about is like service count and privileges. And, you know, it's like, oh, geez. And even if you do get into an environment where you're using certificates, like how often are those just like self-signed certs or some cert that you made up versus like a real cert that can be like truly authenticated and verified yeah and so the solution there is to work for large companies

like google and microsoft and whatever and that have really good tools for generating that stuff and then make it easy to stand it up but i guess that's you know i guess you could argue that like even smaller companies can get that too and set those policies but you only get that if you start with it you know if it's painful if you always wait till the end to throw stuff on, it's always going to be kind of thrown in and tacked on. And so I guess that's the idea. It's like if it's hard for you to generate certs and if it's hard for you to set up authorization on types of services and you have other problems to go after first. Yeah, that's actually a really good point. Another thing that they said, and this is true, and we've actually seen this at several companies we've been with, is don't put things on a public repo.

If it's like a proof of concept or a hackathon or whatever, the reason is, is you may unknowingly be sharing some company secrets or some intellectual property, right? So you have to be careful about that. Not that open sourcing and that kind of stuff is bad. some company secrets or some intellectual property. Right. So you have to be careful about that. Um, not, not the open sourcing and that kind of stuff is bad. You just want to be careful about what you're putting out there. If you're talking about like hackathons, like if your company has a hackathon,

you don't want to start off in like a public repo or something just cause it's like easy to kind of leak something in there without realizing it. Right. Um, Oh, and here's another one. And this one, this one's absolutely true. Never use customer data when you're doing these proof of concepts or hackathons or whatever, because if you mess up and leak any of that information, it can be detrimental to your

company. So, you know, find good fake sets of data to do things. And even, I mean, we've talked about this in the past. Even anonymizing data is usually not even safe enough, right? Yeah. You know, I had a friend, a designer, who said they once saw my picture in a meeting where it was used as sample data. And they didn't know, like, how or what or why. They're just like, hey, that's Joe. And we never get to the bottom of it. I've wondered like what the heck happened there but uh i just thought

it was funny and i think that's something that you don't see as often anymore but back in back in like the 90s early 2000s like oh yeah we use customer data you use live data whenever you could absolutely yeah so i like how he like tries to throw it back like it was oh it was the 90s yeah 90 minutes ago well maybe not 90 minutes ago i wasn't gonna be quite that wow alan sorry yeah so there was there was a slide in here that i wanted to call out like usually when they redact things i don't like you know i kind of skim over them but this one was kind of interesting because of what the story that they were telling so there was a software vulnerability that was discovered

that had actually existed and had been fixed internally but when they went to deploy this thing, there was a missing commit in the code that fixed a vulnerability that they knew about at the company, at the pager duty company. And the problem here is the code worked perfectly fine as was, but without that additional commit, there was a vulnerability in it. And so it's not something that you can necessarily detect with automation tools or anything because everything worked perfectly fine. So their point was even, even when you're doing your best to try and make things perfect,

you're still going to have vulnerabilities and problems in your code, right? So you have to be very defensive about it and do your best. But in this case, it was just an accident, right? Like it, what do you do, man? Like you're going to run across situations like that. And, you know, um, so one thing I remember reading many, many times is like, because of this, you'll see emphasized in a lot of places that detection and reaction to security events is so much more important than prevention because you can't prevent everything. There's going to be mistakes. There's going to be things you don't know about. But you need to be able to detect and react to everything.

Yeah, that's pretty awesome. And as a matter of fact, I think they called it out in there. I think it took them three hours to fix and patch the problem. So that whole reaction thing that you're talking about, they had in place and they did it quickly. And that is super important. But just know, I mean, no code's perfect, right? Like every line of code you write,

there's a potential for it being exploited somewhere, except for outlaws. Well, I mean, let's a potential for it being exploited somewhere, except for Outlaws. Well, I mean, let's go back to my unit test conversation. I'm going to make sure it's good. That's awesome. All right. So into some of the real stuff, some of the things that are sort of OWASP-y, right? Like the first vulnerability they talk about is SQL injection.

And we've talked about this in the past. Um, Oh, look, somebody who's got a note in here. Yeah. I was going to say, um,

so the, the just here is that basically these slides kind of, if you've got that introduction section and they go through a list of like, uh, different types of vulnerabilities and kind of talks about the most common uh you know types and cases and and things that you'll see like out in kind of the real world and so uh what i did is i added a few notes of basically tying stuff to a wasp and we're not going to go through all there's uh hundreds of slides i don't even know how many there are but we're going to go through a couple of the vulnerabilities uh for you right now and um

like alan mentioned the first one they talked about is SQL injection. And so I went and looked at OWASP and OWASP actually just updated their top 10 list. And we talked about this back in episode four. So I'll give you just a real quick run on, run out on what OWASP is. OWASP is like an open source community, basically. I don't know what you call it, like a council group of people that got together and they study vulnerabilities and security incidents. And every couple of years, they update a list that aims to track the most common and most deadly, most dangerous, most severe problems, and they rank them top 10. And what's interesting and why they stick to 10 specifically every year is they say

that these 10 types of problems are so much more common than everything else that everything else kind of doesn't even matter. Though, you know, it kind of encompasses everything. You know, if you take a look at it, you'll see that it's not pretty wide ranging, but it really just covers the basics. And it's over and over and over and over and over and over again. You see with the security incidents, the problems that end up getting exploited are usually very basic.

It's not the, you know, 32 point curve encryption that gets cracked. It's the, you know, our back problem. It's the accidental port left open that should have been it's the uh sql injection intact and so um yeah so that's what owasp does in a publisher list and so to tie it all back to where we started uh 30 minutes ago owasp has a generic injection uh vulnerability that they use that basically tracks to the SQL injection we're talking about here. And I wanted to call that out that number one, it's more general. It's not just talking about SQL.

There's other types of injection. But what I found most interesting is that injection for many, many years was the number one problem that they found in their case studies. And in 2021, it actually moved down to number three and i did just a real quick kind of glance at like why you know what people had to say about it and what what it was basically the tools have improved over the years and so now people are using more libraries and frameworks than ever and it makes it harder to do that and so you know the new people coming into programming over the last five years may have never even done things the old way. All they've ever known is like object relational mappers or using other tools or all the articles they see are doing things the right way.

And so this problem has actually gotten much better. And so it's down from number one in 2017, which is the last time they published, to number three now. That's interesting. Yeah, you mentioned the ORMs. It's funny. So the SQL injection is no longer a problem there. Now performance is. That's what people would say, right?

Right. All right, so that's really cool. I like the idea that they changed it from SQL injection to injection, right? Because now there's a lot of other things that do take in values and dynamically change what's being executed. Yeah, not just databases. It could be like sometimes you'll see a file path or something that will get an image, and you can change the path and get a file, you know, and stuff like that.

Yep. So basically what he just said is kind of the gist of SQL injection, right? Essentially, you are manipulating a query at runtime with whatever the input was from some user or some system or whatever, right? And what this means is if you deal with databases, you should definitely be aware of this. What that means is you are directly modifying the query

by patching a string in or some input in from some external source, right? And the example that they give in here is kind of the one that you'll typically see in SQL injection one-on-one, which is, um, you know, a user login form. And hopefully, hopefully you don't have anything set up like this in your own database where you've got a username and a password and clear text. If you do, you should go Googling right now for how to fix that. But they'd have something like where password equal and then in this case, they had dollar sign provided password. Well, if they were just substituting that text into the SQL query, then somebody could do something like put a closing tick

and then or one equal one. And basically what that would do is it would modify the query and basically say, Hey, just make it act like I put in the right password no matter what. That's where the password is blank or one equal one or one equals one. You would expect that the password is never going to be blank, but that or one equal one is just going to cause the query to always return true. Yep. And so that's like, that is the one example that they probably use the most.

And the thing is, for years and years, that attack was pretty easy to do and pretty common to do as well, right? Like it wasn't, you could go to any number of sites out there and pretty common to do as well right like it wasn't you could go to any number of sites out there and do this two of them so um you know it sounds like things have gotten better which is good yeah literally every programming book you would look up like how do you do a log and uh how do you log in and it would show you the example that does it in like the worst possible way yeah but i wanted to throw in there too um so parameterization is the way you fix it we'll talk about that in a sec um but you can't parameterize everything so that's a

big problem when you're constructing you know if you're trying to construct raw sql strings and you say you want to change the table name out dynamically or maybe you want to do an and or dynamically sometimes it can be tempting to have that stuff passed in from the ui and that's stuff that you can't parameterize. And so there are other techniques for mitigating that, which is basically using lookup values where you take the input from the UI and then go look up the string that you want to use rather than just trusting when they pass you.

You look like you were going to say something out loud. He basically wrapped it up with the lookup. Because I was going to say you outlaw no he basically wrapped it up with the lookup because i was going to say like you could get around it by uh you know having like a case statement for example in your in your code where like before you create your sql statement you could be like hey if the user passed in this then this is what it's going to be or that or that or that and if it's none of that then maybe just throw an exception. Yeah. Basically never, ever, ever use the raw input as is to modify the query directly.

If you need to go look up something elsewhere, fine. If you need a case statement, fine, but never, ever, ever use external input to drive that kind of stuff. You know,

I was going to say like, also, stuff you know um well i was gonna say like also i kind of prefer to avoid manually crafting sequel on the fly as much as possible though because that's where it feels like you definitely run the risk and even if you do everything right right because you're already in this like let's call it maybe like an anti-pattern of how to use of how to interact with the database what you're setting it up for is for like the next person who come behind who comes behind you who might not be as educated as you as like knowing the like hey i should be aware of SQL injection because it might just be an intern and this is their first job right and they they were given some bug and you know

they're like oh hey i can follow along what you did and i know enough to where i can be dangerous and i can go fix this bug and then they might see this bad pattern or anti-pattern let's call it and then introduce something really bad as a result so like So I kind of don't even like the idea of trying to construct SQL in your app layer. Yeah, absolutely. Now, what I was going to say is I'm going to try to avoid constantly jumping in saying, but also this or what if that? Because if you've ever hung out with a true security-minded person or someone who works in security all the time.

I mean, they are just miserable to be around. So, I'm sorry if you work in security and you don't already know this somehow. Or maybe you're married to someone who works in security. They're difficult people to be around. And they're happy. They love doing this to people. But it's hard to be around them because there's just so many ways that they can get you. And so it can be really rough. And there's so many different examples where things have gone just like comically wrong in the history of like technology and the world.

And so it's, you know, it's fun when they're on your side, maybe. But mostly it's not. And so, yeah. So I'm going to try and not be that person today for the rest of the recording so i'm gonna try and do my best so that's awesome all right so oh there's there's a a thing that you may or may not have heard about it's little bobby tables uh we're gonna have a link in the show notes i'm not going to try to describe it but it's something that you'll want to go look up it's it's a little comical if if you've never heard of it um and then let's see what else we got so the user should never do that let's see so we talked about or joe zach touched on it

you want to parameterize these queries or you realize we were on full names here alan underwood yeah there we go. That's right. We throw his weight around. You've done that a couple times, and I'm like, it just keeps getting weird. I'm like, why is he doing that? Yeah. So I usually say, Jay-Z, I don't know what's going on.

It's late. I'm tired. Working too many hours is what's going on. Sorry to derail. Yeah, sorry. I'll be more mindful of that. So you should either use prepared statements or parameterized values when you're doing this, right? Like this is the way that most databases handle these type of things so that if an input comes in, it doesn't modify the existing query. It's truly just a plugged in value for the query that's going to run.

So that's what you want to do. You get another side effect of that too, though, because oftentimes those, uh, those queries will perform faster because they're prepared because of the prepared statement, because the query optimizer already knows that like,

Oh, well this is only ever going to be an integer. Like it can go ahead and uh pre-optimize that query so that when it gets used a second and third and fifth time it knows how to deal with it better right because the run the execution mode didn't change at all you're just changing the value that's going in for the thing and what's interesting is if you look through these slides that they have there and again i highly recommend it um people with like pretty good sql knowledge can do some scary stuff if there is a sql vulnerability an injection vulnerability there because you might say oh well he was just looking up the user's first name. Okay. That's all great and all,

but if somebody actually knows how to manipulate this stuff, they could do some sort of crazy set of union statements or whatever they could do some insert into some selects, like fill up a whole other table with information that they want to be able to get in a following statement. Right? So I mean, the three of us have worked with SQL enough to where we can do some really dangerous stuff with it, whether we're trying to or not. So just know that having a vulnerability doesn't just impact that query that you wrote. It could impact the absolute rest of your database, right? And even other databases on the same server, depending on how security set up for that thing.

All right. So the next thing that they had were some, some different, um, injection approaches that people will take. There's one called blind injection. So the ones that we were just talking about before where like somebody goes in and sees a login form they decided they want to try and sql inject that so they do it interactively right there's another way of doing this where they call it blind and there's there's a couple of different ways of doing it there's a boolean based attack which they say takes time but the way that they do these things is somebody will write a script and have it throw an error if something shows up true. And the example that they gave was, you know, some, somebody writes some sort of malicious script that says, Hey, if the database name starts with an a throw an error,

um, if it starts with a B throw an error, et cetera. And so what you're doing is you're iterative iteratively trying to find out more and more information about the database. And you don't really care if it takes time because you've done it in an automated way. So that's one thing that hackers may do. Another one is a time-based approach. Now, what they do here is they actually leverage the same Boolean thing, except they do it over time so that those attacks won't be detected, right? Because you could totally see in the log somewhere if somebody keeps blasting your database server with, hey, did it start with A, B, C, D, E, right? As opposed to

if it does its thing, waits a minute, runs it again, waits five minutes, runs it again. That's totally different, right? And hackers can be patient because if they're not found out, they could be in there doing stuff for months. Years. And slowly getting information. Years. Yeah, years. Right. True. There have definitely been reported instances of them being in environments for years. So that's not an unheard of thing. Yeah, it's insane. And hackers can be patient, right? Because if they are, the payoff in the end could be absolutely gargantuan. So, you know, they don't mind.

I mean, if you look at the way, just like a quick tangent about that, though, but if you look at the way that whole thing has evolved from like the last, you know, since the 80ies or whatever, you know, for a while there, it was just like disruption. It was like, just, let's see if we can break things. Right. And, and so like there was a quick bang is blown up. Right. But now it's more like, well, okay, now that I've like, I can get in there like, well, what else can I glean from it?

So I want to trickle data out slowly, slowly, slowly so that you never see it. So the time-based one seems a lot more unlikely to be caught because, okay, so something took an extra 10 seconds that you didn't even know was running anyway. It's like, whatever right you know yeah i mean it's crazy what they do and so what they say is well you know a lot of people's approach and this isn't uncommon for especially new people coming into a technology right like if you're new to SQL or something like that, oh, well, we'll just escape

the double quotes and the single quotes. And we'll put together a regex that looks for the nasty things like drop or, you know, or create statements or something like that. The problem is there's no way you can possibly know all the potential combinations of things that people can do. And the SQL language changes, what, yearly at least? So there's new keywords that come in. There's new things that you can do. So there's no possible way that you trying to reject your way to cleaning up this stuff is going to be effective. But Alan, I can just write a regular expression to validate that the email is an email.

Oh man. We, I think we've shared that thing before, right? Yeah. Never, ever try that. Never,

ever try that. It's just, just use a library that's already done it for you. That's been tested a billion times and is in the wild rather than trying to like recreate your own or just write your own and the wackos that have weirdo email addresses are used to having problems with it because that's what everybody does but i disagree with that though by the way like tangent uh tangent alert this is only the first time in the episode because do you know you know like we've talked about with Google, how you can do with Gmail,

you can do like the plus to create like a automatic, um, you know, additional emails that you can then create folders or rules on and whatnot if you wanted to. So you could have like, um, Jane Smith plus,

uh, pager duty at, uh at gmail.com. And you know, that could be a legit thing. Well, I have an account where I used something like that and it legitimately worked for months until they decided to put out a update to their website. And now they choke on it.

Every time I try to log in they're like no that can't be valid like there's nothing here there's nothing to see here that's what you're trying to hack the system that's yeah exactly as soon as i saw i was like oh i know what happened here yep yep i stopped even using it for the most part because i'd venture to say half of the websites still don't work properly with a with a totally valid email address yeah that's what i mean it's like just write your own because the people who have pluses in their email addresses like they've already hit this thing like five times today so they're used to it it's fine it's like back in the day when uh when you're making websites you're like well we need to have a no script tag for people who turn off javascript like no you don't because the people who're not

running javascript already know that nothing works and so you don't you don't have to work the entire web doesn't work if javascript's disabled yeah we don't care about those people anymore sorry yeah exactly i agree um so maybe maybe if you had a team of people working on this all the time maybe maybe you could overcome some of these things but why don't use the parameter huh like talk to like newer programmers whatever and it's like well i could just replace the this with that and it's like well you can but what about this situation well i can get around that by doing this you're like okay well well what if they serialize it or pass it in x for double encoded and like well i could get around just stop just parameterize it like right yeah do the lookup table whatever cockamamie stuff you're coming

up with just don't whenever you find yourself saying like well then i could just in security like take a step back here's a here's a here's one for you uh have you heard about the recent uh unicode um bug against the compilers no it this went against like pretty much i think it was like a wide variety of compilers compilers like most every compiler you're aware of right uh where right? Uh, where they're like, like reading something, uh, you know, things like Unicode where you're like typing out the characters and like how

they're going to be presented and how you're going to read it. It's just another interpreted kind of language, right? So Unicode is another interpreted thing. So like as Americans, we just assume that everything is left to right in the way that we read, right? But for those who read right to left, there's Unicode instructions that could say like, hey, this block of code is going to be read right to left.

Well, some clever hackers, I believe in the UK, or I should say, I believe they were more accurate. It would be more accurate to refer to them as security researchers, had this idea of like, hey, I wonder if I can put in a pull request into a repo that looks totally 100% legit. Like if you read that, even with the most scrutiny that you could possibly put on it, you'd be like, yep, looks good to me. And you would approve that PR. But yet when the compiler would get to it, it would reread things because those right to left instructions would change where, you know, it would, the order that it would process the text in the file. And so as a result,

they could put together something totally malicious that you had never even intended. And sure enough, they validated that it worked and they put the, um, um, you know, put, put their research out there and found like, you know, reported on all the different compilers that it worked against. And so I say all that because you're like, Oh, where are you going with this? Who would have ever thought? They're like, oh, no, I can totally scrub this input. I can replace this with that.

Are you really going to look for right to left versus left to right instructions in the Unicode? Like, no, you're not. Don't lie to me and say that you would. Oh, no, I totally thought about that situation. No, you didn't. No, you're not. Don't lie to me and say that you would. Oh, no, I totally thought about that situation. No, you didn't. No, you didn't. I was thinking about it before you even said it.

No, you didn't. So literally the top of hacker news right now is a remote control execution flaw with log4j2. And what's funny about it is it's an injection attack where you can inject uh some serialized java objects and then assuming that the the object is available in the class path the logging framework will deserialize that into an object and so what they're doing is they're injecting classes for like known you know java classes that kind of normal stuff that are likely available it gets serialized and does malicious stuff and basically exfiltrates either data or back you know back doors back to the hackers letting them run arbitrary code and so it's

this funny thing we're like who would have thought that a logging framework would just by logging data be able to ultimately end up running arbitrary code. It's crazy what can be done. Yeah. Again, just know that code's vulnerable, right? That's all there is to it. It's scary. So we mentioned with the SQL injection, just use parameterized queries or prepared statements.

That's really what it's all about. We said the quicker blah. All right, so that's all good. There were some nice links that they had in those slides that we'll have in the resources we like, so definitely go check those out

if you want to learn a little bit more about SQL injection and how to prevent it, how to try it. This episode is, oh, that's all right. I'm not there, but that's fine. You can do what you want. This episode is sponsored by Linode. Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines. Develop, deploy, and scale your modern applications faster and easier. Whether you're developing a personal project or managing larger workloads, you deserve simple, affordable, and accessible cloud computing solutions.

You can get started on Linode today with $100 in free credit for listeners of CodingBlocks. You can find all the details at linode.com slash coding blocks. Linode has data centers around the world with the same simple and consistent pricing regardless of the location. So, you know, we've talked about WebGoat before. It's a website that's got known vulnerabilities that you can stand up and get into. Wouldn't it be fun if you just do that up on a Linode? You can get $100 free credit by entering the code, coding blocks on Linode.com. And you can stand it up on a remote server and see what you can do. I think that sounds pretty cool.

Also, something I've always wanted to do is stand up a Jenkins. I just thought it'd be cool to have like all my projects building whenever I make a change. And, you know, having the test run and having the team being deployed out there. I don't want that stuff running on my desktop. I'm running Halo. So, yeah, Linode's perfect for that. I feel like you're trying to trigger me, right? Like why would Jenkins be the thing that you would go to with it? There's so many better uses of Linode. If you go to Jenkins, I mean, yes, you absolutely, you can go to it. So, you know,

if you're, you know, if you want, I know Jenkins, you know, Jenkins developers play, why does Michael always hating on Jenkins? I'm not, I don't really hate on jenkins but uh i will say this though when you do create your and you will create your uh linode account and you go in there and you create your first instance here's one super cool thing like we've all used platforms where you create a vm and then you're like okay well i don't know like what's it? Like, not with Linode, they have a simple summary. You can see exactly like, what's this instance doing CPU wise, a disk IO network IO, you know, Hey, maybe you want to know, like what kind of IPs V6 traffic am I getting versus my V4 traffic? You can see that too. You can easily set thresholds in there in the settings and you can see, you know, configure your backups. It's a super simple dashboard to

configure and maintain your images with Linode. Get started today. You can choose the data center nearest to you. You also receive 24 by 7 by 365 human support with no tiers or handoffs, regardless of your plan size. You can choose shared and dedicated multiple compute instances, or you can use your a hundred dollars in credit on S3 compatible object storage, managed Kubernetes and more. If it runs on Linux,

it runs on Linode. Visit linode.com slash coding blocks and click on the creative free account button to get started. Again, that's linode.com slash coding blocks and click on the create a free account button to get started. Again, that's linode.com slash coding blocks. L-I-N-O-D-E dot com slash coding blocks. Okay, well, you know where we're going with this, so get ready. All right? You've been warned.

Hello, dear listener it's that time again where I ask if you wouldn't mind and would be gracious enough to leave us a review we would greatly appreciate it you can find some helpful links at www.codingblocks.net slash review

I love that you www.codingblocks.net slash review. I love it. You finally got on board. It's fun, isn't it? No. All right. We got some surveys. Yep. So with that, we head into

my favorite portion of the episode. Survey says... Alright. So, a few episodes back, we asked, how do you prefer to get on the network? And your choices were wireless.

I can't be tethered by cables. Or wired. I need all the bandwidth and low latency I can get. All right. So this is 174. So Jay-Z is up. I'm sorry, Mr. Joe Zach.

Uh, we're being so formal tonight. Uh, you are up first, uh, wireless, 90%, 90% wireless. All right. Wow right wow alan underwood what say you moon

uh wireless a dollar please wow you're going a hundred percent no no no no one i'm going the price is right yeah i'm the price is right one dollar guy no well because it would depend on like what you know like when they would spin the wheel, right? Like that maxed out at $1. That's where my brain went. No, no. This is a showcase showdown. I'm going to go $1.

Yeah, there are so many people that have like no idea what we're talking about, right? You realize that? Like, I don't know. Is the price is right still on the air? It is. It is. Yeah. All right.

Drew Carey. Yeah, Jim Carey. Or not Drew Carey. Sorry. Yeah. Not Jim Carey. That would be an interesting show though. All right. yeah all right drew carey yeah jim carey or not drew carey sorry yeah not jim carey that would be an interesting show though all right so uh i i feel like alan's cheating the system though but uh okay fine whatever so be it i'm gonna have to come up with like one answer questions

for you guys from now on or you're only guessing like the percentage or something uh so uh uh joseph zachary says the third says wireless with 90 percent and uh franklin allen underwood says wireless with 1%. And if you get that reference, we can talk about that later. Oh, I do. I do. He becomes president. I'm not going to give you anything away.

He does. And you're both wrong. Why would you pick wireless? Of course it's wired convenience what year is this convenience think of who the audience is like we're not we're we're like uh you know people that care about the equipment we're using we're like in this day in day out we want the best we want no latency we want the maximum speed we can get you know so yeah sure wireless when we're out on the go but if i'm if i'm not my preferred way to get on the network is going to

be wired in so check this i've actually got a little bit of an argument to this now latency you can't you can't argue that right like the the wired your latency is the lowest. However, the speed of wireless devices has overtaken your typical consumer. Ah, there you go. There's the words. Typical consumer grade hardware that you can buy. Now, if you got the coin to go buy you some 10 gigabit switches and stuff, you know, please pardon me for speaking out of turn but for the rest of us regular people who don't have a few thousand dollars laying around just to put a nice switch

in your house wireless um they aren't expensive are they uh yeah i think i think those 10 gig ones you're still spending a couple grand wait well that's a one gig uh no here's those 10 gig ones, you're still spending a couple grand. Wait, that's a one gig. No, here's a 10 gig multi-port for 270 net gear. Wait, are you saying 10 gig total or it has 10 gig ports on it? It says, I'll read the description to you. 10 port, 10G multi-gigabit switch managed eight times multi-gig one time 10 gig and one by 10 gig sfp plus ports okay interesting then you got to buy all the network cards for your devices that will even support this stuff so my point is it is actually cheaper and wireless can deliver faster speeds than your standard home network switches at this point so yeah just saying like wireless is faster unless you're talking about latency if you're

talking about low latency on on typical hardware yeah i i i didn't think about it but i was just thinking i have like 15 devices on my desk they're all wireless and like no way i want to plug all those in right yeah yeah my computer though it's plugged in yeah exactly right yeah i mean the the problem that i have with like the whole speed argument there that you have is that it's also like, well, I don't know. Like this has always been the argument with like the bandwidth, you know, the way ISPs handle bandwidth and whatnot.

And it's just like with latency versus top speed, it's like, okay, who cares what your top speed is? If it takes you a year to get there, totally. I want to get off the starting line. I want to get down. Yeah. I want to get down the know i want to get down the field fast you know like i i don't care about the

you know i i will obviously i want a fast uh you know connection too but but you know fast as in latency and uh you know i'm i'm fine with having a lot of bandwidth as well so outlaw said it here he's good with one millisecond ping and only one megabyte throughput. That's what we heard. I mean, I can get those megabits really fast and be like super, super fast. I'd have them the fastest. And maybe

it would make up for it in like how fast I'd get them. I mean, I do get it though. I do get it. I would prefer wired if it was available, but nowadays I do get it though. I do get it. I would prefer wire wired if it was available, but nowadays I'm, I'm a convenience guy. Oh man, I can't get into this argument. I just can't. Like I have, like, I don't care if it's the work computer or a personal computer or an Xbox. Like if it has an RJ 45 capability, I'm plugging something into that port.

Like it could be a smart TV that I'm never going to use the functionality of plugged in. So if you ever want to hack my network, there you go. All right. So, uh, how about this? How about like a shift gears for a moment?

And instead I ask you this, why did the burglar hang his mugshot on the wall? Crooked. Nothing. Cook. I like where your head's at. I like where your head's at. I like where your head's at. I don't know.

To prove that he was framed. Okay. That's good. Dad jokes has just been crushing it. Maybe we can have some good ones. So, you know, God,

give it, God, give him credit. All right. So for this episode survey, we ask, you know, cause we got,

we have the holidays coming up. Everybody wants to take a little bit of time off, a little R&R, a little PTO to relax, reboot the engines. I don't know how long your operating system takes to reboot. It takes a little bit longer as you get up there. Not at my 21 age, forget about it. I'm out all night drinking and then up the first thing in the morning, ready to go back to work.

But, you know, not that I would recommend or condone that for you at all. So, you know, all that aside. So we ask, how much personal time off do you take on average each year? And your choices are a week or less. It's awful, but without me and the company won't survive or two weeks. It's like, I just joined the company America.

Cause it seems like that's a, like a traditional thing here, you know, but you talked to people from other countries and it seems like it's not there. Right. And you're like more than a little jealous. All right. Or three weeks.

It's a nice. Got to think of Borat when you think it's a nice. Right. I don't think Cartman would have done that one either. So, but, you know, say it in Cartman speaking, it'll be fine. Or four weeks, an entire month. This must be what it's like to be European.

Cause it's always the Europeans to get so much more vacation than Americans. It seems like, and you're always like, why do I still live here? Or more than four weeks i wouldn't say i was missing work those are fantastic it's nice i totally was thinking of borat when I wrote that too. It's a nod. All right. So back into the meat of it.

We are on vulnerability number two. All right. I'm sorry. I know that wasn't supposed to be a punchline but it's like right as you said that I looked at the recording clock and I'm like well we've been talking that long we only got through one we really are going to take some time on this

pager duty I told you man that went over better than I thought alright I told you, man. Woo! That went over better than I thought. All right. So this one is on storing passwords. So, Jay-Z, you want to take us with this? Yeah, I went and looked to see what OWASP had for this,

and they kind of have a couple that you can kind of figure out. They have, like, security misconfiguration stuff. I think the closest thing that really made sense to kind of tie this to was just cryptographic failures, which they have as moving up from number three to number two. And it's anytime you have a situation where basically you've got

cryptography in play, but you're not doing it right. You're not doing it good enough, I should say. That makes sense. And it right you're not doing it uh good enough i should say that makes sense and that's number two so saying of all the vulnerabilities that they've looked at the last couple years this is the second biggest cause of problems and i wouldn't be surprised because more and more companies now are storing sensitive information right like everybody wants your email everybody wants all your stuff right Right. So, yeah, that's not surprising. The first thing never, ever, ever, ever, ever store passwords in plain text. Don't. There's no excuse. Don't do it.

So that leads to the next thing. Like if you've ever looked into the right way to do passwords, typically you'll hear this thing called hashing, right? And that's good. So that's, that's all you need, right? Well, kind of until you hear of this thing called rainbow tables. And this is really interesting. Um, if you, if you listen to anybody that talks about hackers and whatnot, they'll have this entire database of these rainbow tables. And basically all it is is passwords that have been hashed with different algorithms, right?

So let's say that your password is 1, 2, 3, 4, 5. They'll have this dictionary of what that value would be hashed in an MD five and hashed in a Shaw one and hashed in a whatever, right? It's just these huge lookup tables. And by using these rainbow tables, they can reverse engineer these hashes pretty quickly, right? Like they could chew through an entire database worth in almost no time. So that's not quite good enough. It's like, it's super annoying that when you go to a website, if they ever give you a length restriction on the password or they're like,

uh, or if they come back and tell you that you, you know, you didn't enter enough credential, enough entropy, you know, or, or enough symbols or whatever.

Like if they do it, if it goes round trip and comes back, then a lot of times it's like, huh? Especially on the length one. Then you're like, I don't think they're doing it right. Because when you say length,

you mean if they say you can't have one more than 20 characters, right? Right. Right. If they say like, Hey, the maximum length of the password can't have one more than 20 characters, right? Right, right. If they say like, hey, the maximum length of the password can only be 20 characters and that's too long, then immediately my mind goes, oh, that's a red flag. They're not doing it right. Right, absolutely. I agree.

Because if they were at a minimum hashing it, then they wouldn't care. Because what the hash allows you to do, for those that don't know, is that it's a one-way direction function. So if your password is monkey123 and you hash it, it'll create some garbage-looking string and it'll be reproducible. So you could rerun the hash for monkey123 and generate the same thing. And so what that allows the website to do is they can store that garbage looking string in the database and they don't really need to know what your actual password was because when you type in monkey123 again, they'll rehash it and they'll go, yep, that hash matches the hash that we had stored for you.

So you're good to go. You can, you are now authenticated and can get in. But to Alan's point about only doing the hashing is that now Joseph Zachary comes in as, you know, a hacker extraordinaire and he gets a copy of that database, right? Well, he already has this rainbow table that he's computed every different, uh, hashing algorithm for one, two monkey, one, two, three, or maybe he didn't even compete in himself. It could just be values that he got from another, uh, website that he's already cracked into and stolen their information from, but, you know, or, or like

he got it from somebody else's efforts to it had already done that thing. And then like people keep spreading them around and building on top of one another. And he can go and query this other website to get that hash out and then compare it to all the known hashes that he has and, uh, see if it's one of those. And if it is, then he's like, oh, well, then I know it's monkey123. Yeah, and that's the whole thing is we're trying to protect your user's password so that someone can't download the database, figure out someone's password

and go log into your site and do stuff as them. And so if you're hashing, you're already kind of protecting your customers pretty well by making it so they can't just take that hash and immediately unhash it and get the original password. But the rainbow tables let them do is like run common passwords or passwords from other data sets and say like, is this one? Is this one? Is this one? Without actually trying to go

log in because they can just try once they figure out your hashing algorithm, they've got your salt there, they can take it and figure out. So, okay what this uh user one two three uh they're using the three thirty thousandth most common password and it's uh you know rainbow 64 or whatever and so then they can take it and go do it and so uh these rainbow tables really speed up the processes so they can try a lot of things really quickly so if you're using uh you know hashing out a rhythm that's um not so great Maybe it doesn't have a great spread or a great distribution, or it's too fast to run. Then it can be really easy to figure out what those passwords are. And once they figure out for one user,

they can move on to the next and they just chew through it. And once they kind of figure kind of get that stuff going, they're able to effectively figure out passwords really quickly for a large number of your users. Yep. And I want to back up to what Outlaw said about the length restriction. So the red flag that he mentioned is if a website says, hey, your password can be, it needs to be greater than so many characters, but it can't be

more than something else that can't be more as the red flag because a hashed value is usually a fixed number of characters right the greater than so many characters isn't a bad thing because on the opposite end of the spectrum the more characters you have in a password the more entropy there is and the more difficult it is to crack by doing a brute force attack. So a red flag is not, Hey, you need to have eight characters or more. The red flag is, Hey, you can't have any more than 20. So I just wanted to clarify that if you were ever looking at something, trying to figure out what that was talking about. So there is a solution to this whole thing of hashing monkey one, two, three, always giving you back the same thing and then being able to

look it up with a table. And it's what's called using a salt. So all assault is, is a random set of characters that you add on to the end of whatever the password was that was provided. And then you hash that. So let's say the password was monkey one, two, three, and then you have some sort of random string that just says cat, right? Like C A T whatever. So you'd have monkey one, two, three, and then cat at the end of it, you hash that entire thing. And then that's what you store as the hashed password. Now, the key point here is that salt is stored right next to the password in, in your dataset, right? Like if, if it's in a database, the record on the table, you'd have, you wouldn't have monkey one, two,

three, but you'd have cat as your salt. You'd have the hashed value of monkey one, two, three plus cat. And then that'd be it. Now, a really important thing here is, and these are two things that are, that are super important to keep in mind. You don't need to store the salt encrypted or anything. It doesn't matter. Its whole purpose is to modify the original text. What is important is that that same salt not be anywhere else in your data set. Yeah. I was going to add that it would be really important that it's a random salt that's used because one thing that we didn a random salt that's used. Yes. Because one thing that we didn't mention with that hashing algorithm was that

with the monkey one, two, three, literally all you'd have to do is just add a space at the end of it, for example, and you would produce a different hash. So it's not even, it doesn't even matter like the length of the salt necessarily.

It's just the fact that you're adding something unique to each individual password that's being passed in so that it would generate a unique hash. And to Alan's point about why it doesn't matter how you store that, even if you got a copy of that database, you know what the end result of the hash is and you know what the random salt was that was used but you don't know what was what it was appended to to generate that random hash right so the whole point is if if you were to hash monkey one two three with a standard md5 or something let's just

say it came out abc just for simplicity's sake that rainbow table look up, you could look up, Hey, what's ABC. And, and they'd come back and say, Hey, monkey one, two, three is your password, right? The whole point, the only point of using assault is when you add those random characters onto the end of your password, even if every single user's password in that database was monkey one, two, three, if they all had different salts, every one of the hashes in that database was monkey one two three if they all had different salts every one of the hashes in that database would be different so yeah its sole purpose is to make it to where you cannot reverse engineer it with rainbow tables that is the reason you use salts there there was another part of this discussion that led up to this where he was just talking about like just plain hashing and while like even if you didn't have the rainbow tables to look up and be fancy about

it, that if you just saw like, uh, Alan, his username, his hash, Michael, his hash and Joe and his hash.

And, you know, you saw that like, well, that's odd. Like Michael and Joe have the same hash. And if, if there were, um,

like password hints or, you know, related to it, that you might be able to figure out from the password hint, what the, uh, what the password might be. And then you could try it on yourself to see like, Hey, let me see if I can generate this hash in, Oh, I did generate the same hash. Oh, well that's the password. And so like, you know, my password hint might be something like, uh, you know, my, my favorite scary movie. And, uh, Joe's might be like, you know, I love, I love that they have pumpkin spice latte at this time of year. And then you might be able to figure out like, Oh, well, this is something to do with like Halloween or October or, you know, something in the fall, like you would already have some context clues. So they also talked about in there, like, you know, for in the answer, to fill in garbage.

Don't give them real information because you might think you're making it easier for you to read that off to somebody, but it's actually giving away like information that could be useful. Even, even if it had nothing to do with like, Oh, well I know that Joe, now I know that Joe likes pumpkin spice latte and like, I'm going to use that to target him. Like it doesn't have to be anything like that.

It could just be like literally trying to, to go through the rest of the hashes and fit and make sense of stuff. So they talked about like, you know, using garbage for all of that information, which, you know information, which I don't know about you guys, but I just used the generate. I'll generate it like it's a password, like just random gibberish, and then that's what my answer is. But they gave an example where I think it was like United or Southwest Airlines or something like that, Like one of the airlines where they had changed their website in an effort to make it more secure.

And they actually made it worse because they gave you a, um, the security questions. And what was worse was that they, uh, gave you limited answers. So you couldn't even type in the answer. And they said,

they said the irony of it is, is that, uh, there was like maybe 10 questions and 10 – no, it was like one question, 10 answers. No, it was like 10 questions, 10 answers, something like that to where it was like it would work out to be a total of 100 possible choices. And before, they had a four digit pen. So their effort to make this thing more secure, like actually reduce the number of possibilities from a thousand to 10 to a hundred. That's ridiculous. Yeah.

There's that inventing your own security for you. You think like, well, why should I have to use this time? Let's just have them drop down and be much easier. Like, well, there's a reason why other sites don't do it.

Yeah. Don't do it. Yeah, don't do it. So the next part of this, and I had to say this, is using a pepper. Would you say using a pepper or using pepper? I don't know. Using a salt sounded fine, but using a pepper sounded weird. Now you're pushing it. Yeah, I think so.

Well, salt sounds stranger to me than a pepper because you can have a singular pepper because you can think like a jalapeno or something like that. You know, a bell pepper, a green pepper. I don't think of pepper like that when I'm thinking salt and pepper. Well, yeah, but you – I think it's real good. A salt? Right. Yeah, now you really are. Wow, I didn't realize we were going to sing.

I'm roller skating now. Yeah. Now you really are. Oh, I didn't realize we were going to sing. Yeah. I'm Royce Keaton now. Yeah. Backwards. Is this a couple's dance? That's amazing. All right. So, so all the pepper is, is really the same thing as the salt. It does the same thing. The big difference is it is stored not in the same place that the salts and the password hashes are.

It is typically stored on a server, maybe in a file, maybe a memory somewhere. But it's used exactly the same. So you take your password, you append the salt to it, and then you append the pepper to it at the end, and then you hash them. And all this does is make it to where if a hacker does get a hold of a database and they somehow figure out a way to reverse engineer some of the hashes, even with the salts, now they don't know what the pepper is. And so it's going to be extremely difficult for them to try and reverse out those passwords. I want to like simplify that explanation of the pepper though, is just think of it as like a global salt.

That's exactly what it is. Yeah. It's one, it's one thing. It's not going to be, it's not going to change per password, but it's not stored with everything else. So for example,

if you use vault, for example, maybe, maybe you have it in vault so that it's completely separate from your database where your users are. And you still have the database with the passwords, the password hashes in the salt. And so that if a hacker got that, he hopefully doesn't also have the pepper from the vault. And so he, he, it won't be immediately obvious. And that's the thing is that from looking at the hash, you have no idea that three things

were combined, the user's password, the user's salt, and then a site-wide global pepper. You can't tell that at all that it was. So you think, okay, I've got the database. I got enough. Now I'm going to go run this against my rainbow tables. Oh man, that's weird. I'm not coming back with any results well let me start uh you know going through a dictionary attack of all the you know things that i know of and i'll start seeing what i can come up with and yet you still never can figure it out right you know like that's that's the beauty of the pepper now and now the downside to the pepper downside to the pepper is if it is compromised for some reason it can be really

difficult as the owner of the system to roll that right meaning like if you're rolling passwords or you're rolling keys or whatever that are usually using for encryption or something rolling the pepper um that means you may have to go back in and update all the passwords, or you may have to keep every version of the pepper around so that the next time it goes to be used, that you can take it and then re re pepper and hash the password. So there is some additional overhead, but it does add another layer of protection that could be really nice. Yeah.

It's really not even a matter of like, you know, the bad thing about it being, if it, if the pepper got out, it's just a matter of when it becomes time to roll the pepper because you might decide to roll the pepper just because like, Hey, every 30 days we're going to roll it. Or, you know, anytime we have an employee from this team, leave the company, we're going to roll the pepper or, you know, whatever, which, you know, I mean, did you ever think that you would grow up to have a job where you might talk about rolling the pepper so you know you're welcome but yeah so i mean that that's the real thing it's not necessarily

about like what the reason is to have to do the action it's just that you have to do the action yep now i was uh reading up on why, you know, you mentioned salts should be random. So I was reading, like, why couldn't I just use the user ID or a timestamp, whatever? And there's some pretty lengthy papers on why you shouldn't, but it basically was down to you can still generate rainbow tables, just you have to generate more of them.

It's pretty interesting, though, just the different strategies that people use. And they also say you should roll the salt whenever you change the password. Yes. Makes sense. Should already had the, you know, salt.

They don't want to be, yeah, whatever. And one thing we didn't mention too, is that another side benefit of having salt is that if two users have the same password, you can't tell by looking at the password. Good point.

So in my Michael and Joe example from before of having the same hash, you wouldn't be able to tell that if we, uh, ha each had a different salt added to it. Yep. That's the whole point. You cannot create the same hash with, with a different salt on there.

Um, all right. So with all these salt and peppers and all that, we're good, right? No. Um, if,

if only it were that easy. So basically what they say is, all right, so now you've fixed the problem. They can't use a rainbow table, but if a hacker actually has the salt and pepper, then they can just try and brute force things. Right? So basically if they have a dictionary of, of passwords that have been used, which there are lots of these things that are available out there and on the web, in the dark web, where you can download dictionaries of passwords. And then they can just run it through and append those salts and peppers and try different hashing algorithms and see if they get any hits. Right. So they can still brute force it. Well, I mean, this would be a good opportunity.

Oh, shoot, I can't remember. There's Have I Been Pwned, which the guy is from Australia, I believe. Troy Hunt. Yeah. Trey or Troy? Troy. Troy. Okay, Troy Hunt.

That's basically what that is. Like every time you hear about one of these major outages, not outages, I'm sorry, one of these major breaches that a company might undergo where like passwords got out, like just know that people are maintaining a copy of all of that information. And then that way, if they go to, you know,

they find, they find your username and password on, uh, say like an amazon.com. And then they're like, Hey, uh, I wonder if he used the same credentials at target.com or walmart.com or whatever. And you know, they'll try it there. And if you did, then, okay, they can get into you. They can impersonate you there too. But what's, what can also happen too, is that they can just see like, Hey, do the hashes match? It doesn't even have to be the same user, right? It could be any other user, but they can say like, Oh, Hey, I see that over here, I have this, um, Walmart breach, you know, uh, leaked data hey, I see that over here I have this Walmart breach leaked data. And I know that this password was monkey123.

And that was the hash for it. And now I'm over at yourwebsite.com. And I see this other hash that's the same. I know that it's monkey123. Yep. Yeah. So these dictionaries exist, right? Like there are large ones out there. and they can just brute force this stuff. So, so just the salt and the pepper alone aren't good enough with the hashing. And they talk about the reason why it's not good enough. And it's because if you were using something like an MD five or a Shaw one hash, and there's probably a dozen or more others. The problem is they're too fast.

Those hashing algorithms were made to be fast. So you could do like a check on a file, right? Like MD5 was historically made to where you put something together, you MD5 hash it, and then you can compare it against your own MD5 hash of it to see if you downloaded the right thing, like an untampered with one, right? So those things are fast. And the problem is computers are getting faster and faster every day. So you don't want something that's that fast. So the solution is actually called key stretching is what they call it. And I want to say security. Now, Steve Gibson actually did,

did a, a talk up on this when he was, when he was covering the last pass and how last pass works, he went into some of this, but essentially all the key stretches is hashing something repetitively. So if instead of doing a single hash of a password, plus your salt and pepper, you might do a hundred thousand iterations of hashing it. So you hash it the first time you get the output of that. Then you hash it again, you get the output of that hash again, et cetera,

a hundred thousand times. Right. And the whole point of doing that key stretching is you are slowing down the process of getting the output of that hash. And you might think that sounds awful, right? You're like, why would I want to slow my user down to where they have to wait 10 seconds for the authentication mechanism to work? And the reality is that user, they're probably not going to care that 10 seconds. But guess who not going to care like that 10 seconds, but guess who is going to care that hacker that already has a hundred

thousand accounts. And he's trying to brute force those a hundred thousand through a billion different or more iterations. Those 10 seconds can add up to be a lengthy amount of time that if he was paying like compute time in like a, an AWS or something to, to do that computation, that starts to become real money out of his wallet that he might not want to incur. Right. So, so if you looked at just the math and the time on this, that, that hundred thousand iterations of that thing might've made it to where hashing that password takes a second, right? So if they'd only done one pass, it would have been one 100th of a second

to have hashed that password. Now it takes a whole second. What that means is a hacker who is trying to brute force this, they can do one brute force attempt per second, right? On a hundred thousand hashes. So let's say that you have one password. You might have to brute force that thing 10,000 times to even get the hit, right? So now you're at 10,000 seconds instead of a fraction of a second to do that same amount of work. So that is the reason why this key stretching is important. And that's, that's what's used right now to basically slow down computers more or less. Um,

there's also other algorithms too that are specifically made, uh, around, around – I mean the intent of the algorithm is to be – to slow things down so that it's not fast. So there's like Bcrypt and Scrypt that are – I think they're called like memory hard. No. Am I saying it wrong? They're down here. Yeah, we'll get to that in one moment. Oh, sorry. One moment. So here's the thing. hard no am i saying they're down here yeah we'll get to that in one moment oh sorry moment so

here's the thing the this whole doing a hundred thousand this sounds better right like this all sounds amazing and this is he's stepping through it and he does a really good job of this the problem is your computer today is way faster than the computer of a year ago, right? And similarly, the year before that. So the problem is 100,000 hashes right now might take a second. Next year, that same 100,000 hashes might be a fourth of a second, right? So what they said then that you need to step into

is what's called adaptive hashing, which is basically the same concept we had before, except now you need to increase the number of iterations based off the fact that hardware has gotten faster. And what they ended up doing is saying, there's really a cost algorithm that you need to put to these things to where you basically look at the algorithm and you say, Hey, how many characters were in the password? How much would it cost in a year to hack this password? And with an MD five, it was dirt cheap, right? Like even, even with a very long entropy password and MD five, you could

hack with very, with, with just regular hardware for fairly cheap. Getting into what Outlaw was just talking about, you have bcrypt, scrypt, and pbkdf2 are these ones. They essentially have this adaptive hashing. Well, I don't think they have adaptive hashing. They have this iterative hashing plus salting built into the algorithms. And so they are made to make it difficult for computers to be able to hack these things backwards. So where I want to say in that diagram, and it's worth going and looking at that diagram, I want to say that the MD5s were like a buck for like a super long password.

It depends. It depends on the length of the password. So this is why for your own personal use, the length of the password or the entropy of it matters, right? Yeah. So a six-letter password, it was estimated that with an MD five hash,

you know, you could crack that for less than a dollar. It could even be B crypt or, uh, you know, a PD, PD, I can never say this. PB,

KDF to that. Yeah. Those PB, K, DF, uh, or, or S crypt, depending on the system, it could, it could crack it for less than a dollar.

Now, if you get into 80 character passwords, for example, then, uh, you know, things got insane. Cause it was like for an MD five. Whoa. know things got insane because it was like for an md5 whoa but it's well i was gonna say instead of going to the 80 let's jump to the eight characters because we used that earlier like some websites will say hey you need to have eight characters and here's why okay if you did if you did the md5 it's still less than a buck to crack it over a year if you you jump up into this PBKDF2 implementation and it's five seconds to do this particular one, that same eight character password would cost somebody $920,000 using that. If you use... Oh, wait, no. Eight characters, that's important distinction here.

Eight characters, not letters. Characters, right. Because the difference there being is that if you only said, hey, your password can only be lowercase letters, then there's 26 possibilities. If you say, well, your password can be only upper or lowercase letters, then there's 52 possibilities. If you say it can be upper, lower in numbers, then there's 52 possibilities if you say it can be upper lower in numbers then there's uh 62 possible characters but if you said also symbols then it's like what 96 possible within printable characters so you what happens there is from a brute force perspective like you're you keep um lengthening like the possibilities that each character can be. Because these are...

You could repeat the same character multiple times, right? So I always get permutation and combinations mixed up, but I believe it would be... Combination? No. Dang it, I always get those two mixed up. Because a combination lock should technically be called a permutation lock. And that's what always throws me off, right? So permutation you can't have. a combination lock is technically should technically be called a permutation lock and that's what always throws me off right so permutation you can't you're on mute oh oh is he talking oh yeah he was agreeing yeah yeah permutations have been no dupes yeah so so so like combination your password is technically a combination to where like every letter could be

the same thing if you wanted to but i mean mean, not that you would want to. I'm definitely not advocating for that. But like if I gave you, if I told you that your password could only be numbers, then you know that every position of that character, of that password only has 10 possible choices. So it'd be really simple for you to like brute force that. So the cost of the eight letters versus eight characters matters here because- Oh, I didn't even see the letters yeah if it's eight

letters even with the pbk df2 function it's only 29 to crack that password right in five seconds versus yeah when you include when you increase the character space to include all the printable characters, you know, upper, lower number and symbols, then that's where it becomes a $920,000. Right? So it went from $29 with just the alphabet to $920,000. If you open it up to the character set.

Now here's, here's the crazy part is they said, now there's two different sections in here as well. One where they're doing it for basically roughly 100 milliseconds, meaning how many hashes they do to hit like 100 milliseconds. The jump from that to where they do it for about three to five seconds is massive. So if they do the B crypt one for about a hundred milliseconds on eight characters, it costs you about $130,000 worth of hardware to do that, to go from a hundred milliseconds to three seconds using the same B crypt algorithm goes from $130,000 in hardware to $4.3 million in hardware.

So it takes 30 times as long, but for your end user to do a login, are they going to care about three seconds? Maybe not. And if it protects them, then maybe that's fine. But their whole point in even doing this cost table was essentially like, hey, this is something that you need to be aware of

and you need to revisit because these costs are going to change over time as hardware gets faster. So go ahead. Well, I was going to say, I didn't mean to cut you off. No, that was it. You were talking about the security now came up before and Steve Gibson referred to this whole thing

about how many how many characters are in your possible password um you know whether it be just numbers or numbers plus letters or plus lower letters or numbers letter lower letters and upper letters etc etc he referred to that as the haystack right of you know like you know and how and how big is your haystack well i think technically he referred to like the entropy as the haystack, right. Of, you know, like, you know, and how, and how big is your haystack? Well, I think technically he referred to like the entropy as the haystack. So I might be, uh, I might be stating that wrong, but at any rate, um, he has a, he has a page up and I'll, I'll, we'll have links to all of this stuff in the show notes, but, um, where he's talking about like,

well, how big is your haystack? Because like, you know, if you were to think about trying to brute force a password, right. You know, let alone if you had it salted and peppered and whatnot. But if you were to just, you know, try to brute force a password with some of these different algorithms, then he has like, okay, well, here's like how long it would take to crack these different passwords depending on the length of the. So you can see like how the entropy of your password matters because, um, you know, that's fine for all these eight character ones. But if you go to 80 character passwords, then it costs a lot more. And even with the MD five hash, if you were to hash an 80 character password and you try to brute force what that could be, uh, you know, 80 characters that could have 96, I think it's 96 total characters, then it was one and a half trillion dollars to try to brute force that password. That's crazy. So, you know, for your own personal security, then definitely do that. And also, by the way, like I've been meaning to call this out too, because we keep talking about

the one that I can't pronounce, the PBKDF2. Can anybody off the top of your head name what those letters stand for? No idea. Password based key derivation function. Oh, two. Yeah, I can remember that. Well, version two.

Totally. So it's important to call out the BCrypt, the Scrypt and that pbkdf2 were all made specifically for hashing passwords right where md5 and sha1 were not these were so that's why they're really good to use if you are trying to hash things and make them good. They also said that the salting and key stretching are built into those. That's why they are good at what they do.

I think that we're through with vulnerability number two. Did it. It shouldn't be funny, but it really is. I'm sorry. I'm sorry. I gave you so many tangents.

All right. So we'll have plenty of resources in the resources we like section for this. So we've talked about a bunch of different URLs. This one from PagerDuty, obviously it'll be up there. There will be another link for you, um, for you to pass along to your family called for everyone. And, you know, huge thank you to, to pager duty for, uh, putting this type of stuff out there. I love when, like we talk about these big companies that put, um, information out there to where, you know, everybody else can benefit from like,

you know, whether it be like their engineering blogs or in this case, uh, you know, a security blog. And, and this is like from 2018. So this is, you know, a few years old, but, uh, still really good information and definitely easy for you to pass along to family and friends and whatnot that aren't in this industry that, um, they can understand some of this. So, you know, huge thanks to, for them to put that out there. And with that, we'll head into Alan's favorite portion of the show. It's the tip of the week.

Yeah. All right. So this one I haven't even done, but we had somebody ask, like they, they needed to send out like a, almost like a campaign type email from Gmail and they wanted to do it to individual people one off. But they didn't want to have to go and create a new email and, you know, be like, hi, Michael, you know, and then their blob attacks.

And hi, Joe, their blob attacks. You can actually do a mail merge in Gmail. So I have a link in here. You can basically use a google doc or a spreadsheet to have your list of people and whatnot and you can have it automatically send emails out from those people so if you have like a you know christmas is coming up if you have like a christmas list that you want to send things out to and personalize it a little bit you could totally do this so pretty interesting didn't know it existed there. I remember mail merge from word

back in the day. And, uh, yeah, so this has been taken online. Um, pretty cool. And then check this out, uh, because I was looking for a more developer centric tip. I went on to our Slack channel at Cody blocks.net slash Slack and looked at our tips and tricks channel over there. And Jamie, the guy that we mentioned at the top of the show, who, who is now an MVP, um, he left this tip out there.

That is actually really cool. This is called Docker slim. We'll have a link in the show notes here, but the whole point of this is optimize your experience with containers, make your containers better, smaller, more secure, and do less to get there. It's a free and open source way to, I guess,

make your containers better. I've never looked at this, but. Yeah, I was just reading about it. I don't quite understand how it works, but it actually runs on your containers and it goes through and removes things that you don't need. I don't know how it knows you don't need it it's like a minification of your your your image like tree shaking and and minification all at once is what it sounds like what it sounds like yeah so i haven't tried it you know so disclaimer i haven't tried

it but if this does what it says it's supposed to that's pretty awesome so definitely go check that out and thank you jamie for the tip yeah that looks yeah so it's a combination of static and dynamic analysis so yeah it's just like you, that's really cool. That's amazing. All right. All right. Well, hey, I got a tip, too, because the game jam is coming up. So I wanted to give you a game-related tip. Did you know that Unity has an asset store? Yes.

Unity, the company, also publishes assets on the asset store if you go to their asset store and search for unity technologies or just you know unity uh you'll find the assets that they have for sale and almost all of them are free and really good they've got a bunch of static uh starter assets so basically um standard materials so if things like look like bricks or like metal or like grass or whatever um they've got things for terrain. They've got whole games too. So if you want to start with FPS, if you want to start with a Mario Kart-esque type of game, like a Lego game, you can take it and jump off from there. They've also got controllers, which is really cool.

So if you want to have the ability to control a first-person view or a third- thing so you can see like a skeleton running around then they've got all that stuff up there and almost all of it is free and the things that aren't free are kind of interesting too so like they'll give you a fps game and you can go and buy like interesting guns or you know like uh just behaviors that you can kind of add to those games and they're all you know just like a couple dollars but almost everything is free but it's just kind of fun to go in there and look around. So that's one tip. And I've got another one, which is and thanks to Alex from Gaming Fix for turning me on to While True Learn.

Now, While True Learn is a video game about coding. And it starts out with a frustrated programmer walking away from the keyboard and his cat uh fixing a problem and he wants to know how the heck the cat did it and he wants to communicate with the cat and so he starts researching machine learning and the game is basically a bunch of puzzles that you uh work through by kind of dragging like ifs and other kind of like libraries and tools around but at the end of this idea is that you're learning uh not just how to code but how to code machine learning so it walks you through different uh algorithms um has you building up like decision trees and uh neural networks and so you're basically dragging in these tools as you learn

about them and kind of wiring them up together so you're not typing code it is visual but yeah it's cool the idea is that you're learning machine learning and using the techniques and the kind of things that you do in a fun and engaging way and there's like a narrative there about learning how to talk to your cat and stuff which is pretty cool so if you just click through on the like the steam page we'll have a link here you can just kind of see the kind of stuff that you're doing and it's just really cool and really visual and neat and fun it's like 12 right now if you uh missed it was free briefly on the epic store but uh it looks like a lot of fun and we have to buy that yeah yeah sounds really cool add to the wish list because you know it's that time of year to this uh all right well

for mine for first i had a question so back in episode i don't remember which number it is and i probably should have been better prepared to have that number off the top of my head but it was something like episode number 163 um we talked about talked about like, uh, one of the things that I'd, I'd brought up were like different terminal tricks from an article from code magazine. And there was this one that like I've used ever since where we had talked about how in like a Mac OS and whatnot, you could say something like, um, let's say you wanted to, or on Linux, you wanted to, um, CD into Var logs, Apache, right? Well, if, if it was unique enough, then you could just type in CD slash V slash L slash a tab. it would you know there might be multiple v's or there might be multiple vls but that last a would be distinct enough that it'd be like oh i know that he means

for log logs apache and so it would tab completion into that and you know way you go and i've used that ever since but i tried to share that tip with a friend. And at least on the Mac, he didn't have Oh My Z Shell installed. And it wouldn't work. Now, have you guys been using that tip? I have. Yep. But you have Oh My Z Shell?

I do. Yep. Well, then you're worthless to me. Like, why wouldn't you? Not sure. Well, I was just curious to see, like, because now I'm, like, asking myself, oh, you know, I should have done it while during the show. Because I was curious to know, like, well, wait a minute.

Was it like an Ubuntu thing where it works fine under Ubuntu, but not under, um, you know, Mac by default, unless you have a, was he show? So at any rate, so I thought I'd at least call that out as like a, you know, uh, um, public service announcement that like, Hey, uh, you know, if you're on Mac and you're frustrated that that didn't work, maybe it's an OMIZ shell thing. And then I just never realized that was there in which case, uh, you know, Hey, that's super amazing. And, uh, you know, I didn't even realize I was getting that for free from OMI Z shell. So if I are, you know, everything I've ever said bad about OMI Z shell, I take back because I use that, uh,

shortcut all the time. Okay. So, uh, with that though, there was another one and this one is super cool. You're going to love this, but now in full disclosure, this is much like, uh, Allen's, uh, Docker slim. I haven't used that, uh, use this one, but what's super cool about this one is that this was one of the developers on our Slack community that shared this, that wrote this. So this is called, you know how there's a terminal for everything, right? And you know my love of Git. So he created, I don't know how you pronounce this, either you'd say Git, erm, or GI term. But basically take the word, you know, the Git as we know and love and concatenate that with term as in terminal, but you'll only have one t, right? So I'll have a link to the GitHub repo for this, but this is a terminal, a command line

terminal for git where it'll visualize the subway lanes for, or the, you know, for the, for the branching and whatnot. And yeah, it looks super amazing. And so I thought I would share that with the rest of the community in case,

you know, for those that aren't on the Slack channel, which by the way, I mean, really after it's 174 episodes, you're not on the Slack channel yet. Like why, you know, don the Slack channel yet. Like why? You know, don't, don't be saying antisocial.

I promise we won't bite. Well, maybe Joe, but Alan and I are usually pretty. All right. So, uh, yeah. Um, how about this? Uh, before we, one last one. What has ears but cannot hear? Corn.

Yes. A field of corn. Okay, well. Corn single. He got it. He got more money. He got it. I mean, the fact is, yeah, that would be single.

What has ear? Yeah. That's right. I didn't ask that question. It's true. All right. You don't say corns. You say corn.

That's right. A field of corn. I think Joe's on something there. I don't know. You don't say I've got corns unless you've got corns, and that different i was expecting you to go with like children of the corn oh but yeah you made it worse so uh all right what how about with that said we now head into joe's favorite portion of the show it's the end of the show uh with that uh you know,

like I said before, if you haven't already subscribed to us, maybe a friend or, you know, gave you a link or something to listen to us. You can find us on iTunes or Spotify, Stitcher, wherever you like to find your favorite podcasts.

And if you haven't already, as I asked before, ever so politely, you could find some helpful links to leave us a review at www.codingblocks.net slash review. Yep. And while you're up at codingblocks.net,

make sure you check out the show notes. They really are amazing. They have lots of links and all kinds of other stuff in them and the surveys. Like the surveys are probably the primary reason

to go up there. We have some discussions, all that kind of stuff. You can send your feedback, questions, and rants to our Slack channel somewhere. And I'm sure somebody will respond. Yes. Yeah. If you want some tweets,

we got them over at Twitter at coding blocks, or you can head over to cutting box and find all our dillies at the top of the page.