Troy Hunt: [00:00:00] It has never been faster and easier to stand stuff up on the cloud and screw it up.

This is the golden era.

But I think a lot of this is just the entire cloud discussion itself. Are we willing to let go of control of things that we used to manage ourselves and delegate it to another party?

It's not all roses, there are upsides, there are downsides, but I think on balance in most use cases these days, letting go of everything from the hosting through to the key management is a positive thing.

But I guess the paradox there is that the more data you're able to give the LLM, the better job It can do with interpreting it. That's right. The more data you give the LLM, the greater the privacy risk

Scott Helme: training is as far left as you can go in the development life cycle. And the further left in the development life cycle, we go to introduce security knowledge, the better.

And literally in people's brains is the leftmost point on any development life cycle diagram.

Ashish Rajan: Hello, welcome to another episode of Cloud Security Podcast and today I have Troy and Scott. Welcome. Welcome to the show. I don't know how to start the intro, so instead of me butchering your intro, would you be kind enough to share a bit [00:01:00] about yourself to the audience first

Scott Helme: okay, yeah, sure. My name is Scott Helme. I generally go by security researcher. I I blog online a lot. I founded securityheaders.com, Report URI. I do conference speaking. I've just done two days of workshopping. , teaching developers about how to secure web applications. And between all of those things, I think, security researcher is the kind of aggregate job title.

Ashish Rajan: Awesome. Thank you. And Troy?

Troy Hunt: Troy Hunt. Some stuff the same as Scott. I just done the keynote here at NDC Oslo today. Security? I run workshops with Scott and I started haveibeenpwned. I think haveibeenpwned is probably the thing that has defined me.

Ashish Rajan: Awesome. Thank you. And maybe to start off the conversation the importance of password these days, a lot of people were saying, Oh, password has been solved. We all use MFA. It's at least what the enterprise would think. What is the current state of password management and how would you guys describe it? Cause haveibeenpwned has been there, I think you were saying. on your keynote over a decade. Yeah. Like, why is there a need for this still?

Troy Hunt: I guess haveibeenpwned is larger than just passwords alone. [00:02:00] Someone in the audience asked the question, I said, what about biometric data? I said if there's a data breach that has biometric data, that's not going in there, but I'm going to put the email addresses in there, and then I'm going to put metadata that says biometrics.

Yeah, whether we still use passwords, or whether it all rolls to pass keys, or we do, everything via U2F or something like that. We're still going to have data breaches that expose other attributes. And I think the auth component is parallel to that.

Scott Helme: So you said they're like MFA is quite common in the enterprise. Like what I guess what is? It's quite common as a metric, like I still feel it perhaps isn't

Ashish Rajan: like regulatory bodies would have it, like banks would have it. And most enterprise, I think these days the word enterprise is a bit muddy because people think that, Oh, big tech companies is an enterprise to a large extent they are, but at the same time they are like a small startup trying to grow really fast.

So I think when I say enterprise, I'm referring more to the regulatory bodies, the banks of the world, and the governments of the world. They definitely have hard arsed on the whole, yes, MFA everywhere. Even if you hate your life, that's okay. MFA first, but you don't die before MFA.

Scott Helme: [00:03:00] Okay, yeah, that makes more sense.

I think it like ties into the password thing. We were having this conversation a couple of days ago where, do you even need good passwords if you have MFA? And no one should take that as advice. Please don't put this in the caption. Sorry, cut that, take that out.

Troy Hunt: We had two FA and you've just taken us back to one and a half FA.

Because it's like a half strength password.

Scott Helme: But it's like the password is no longer the key the strong component, like generally speaking, the password is no longer the strong component in the mixture of those two things. In my experience, I would be more comfortable having a, like sometimes you go to websites, I try to use my password manager and they're like, Oh, this was too long or you had too many special accounts and you just one, two, three, four, five, six, seven, eight, whatever.

Yeah. And if you have two FA on there, like you're still achieving like a really robust level of security.

Troy Hunt: Even when you say like the second factor is the more robust part. I guess it depends on what we're talking about as well. Are we talking about the SMS? Oh yeah. Because we're saying MFA in such a generic context. But even today, there are discussions around what about OTPs? Should you [00:04:00] synchronize them via a password manager or not? So we, sometimes that makes sense, but other times I want to use a security key. And maybe the most objective way of looking at it is that we have multiple different ways of implementing the second factor depending on everything from the usability to the impact, to the sensitivity of the service, you might have different ones for different places.

Ashish Rajan: To add another layer to this as well, for the cloud security folks who often hear about data breaches and they would have conversations about the fact that hey, passwords are not just the only things that are compromised in breaches. There are access keys, Azure secrets, and so there's a lot more broader context to it as well. Is there some opinion over there as well as to whether that's increasing or that's starting to show up more? Have you guys started seeing some kind of pattern there as well?

Troy Hunt: Yeah, don't do that.

Ashish Rajan: Yeah, don't put it on the internet.

Scott Helme: I think the issue we have is if we were to just look at the absolute number of breaches, I guess it lacks the context of, how many organizations are there with the data and how much data is there, so it's like the absolute number of breaches might go up.[00:05:00]

If the scope of potential breach is doubled, but the number of breaches only went up a small amount, then you could make the argument we're doing better. But I feel like a lot of the time we like the scope of what is the total risk surface. Like what is the actual potential and what are we seeing of the potential?

Troy Hunt: That's the thing, it's like we're expanding so quickly. We're not getting less services, we're not getting less people on the internet, we're not getting less devices. Not only that, but they're getting easier to access. They're getting cheaper. There's a lot of new people coming in. It has never been faster and easier to stand stuff up on the cloud and screw it up.

This is the golden era.

Ashish Rajan: Yeah. Let's make the less friction to put your password on the internet and just paste it and put it in GitHub. Please don't do that. I just say it lightly. They said Oh, Scott, Ashish, and Troy in the interview said you should put your password on the internet. No, we didn't say that.

The layer where at least for me, it gets interesting is that like Azure and other cloud providers they try and make it easy for you to have encryption, like the stronger encryption for your password by default. [00:06:00] But there will be choices made where, Oh, let's make everything which is inside the organization non TLS.

Let's make passwords unencrypted because when is Ashish in the wildest dreams gonna ever get to that network is like the probability that most people talk about. Is that still, as much as I feel I'm aging myself as I say this, like sounds like a very 90s concept or a 2000s concept.

Do you guys see that when you have conversation in training or otherwise as well? Is there like a pattern there as well?

Scott Helme: Yep, and it still exists. Alongside the Hack Yourself First workshop, which is application security and hacking that I do with Troy, I also do, my only other training course is a TLS training course.

Oh, so we do like the practical deployment of TLS with proper configuration, key management, certificate management. The amount of people that still draw a distinction between internal and external network is enormous. And, my view is network. Yeah. If it's being transmitted over the network, then you're going to have the TLS configuration that we agree on.

And that will vary based on your own criteria. But it's not, there [00:07:00] is no, oh, it's internal network, we'll just send this HTTP it's network equals TLS required.

Ashish Rajan: What's the friction? Going back to what Troy was saying, that nowadays we live in a world of everything should be easily accessible, why is there a friction for people to still go down the path of, oh, I just want non TLS and unencrypted traffic on the internal side.

Is there a reason for friction still existing there?

Scott Helme: Ignorance there is that component of it, yeah. There's also a lot of historic misunderstandings. One of the things that I get a lot in the TLS course is debunking traditional tropes against TLS. Oh, it's difficult to set up, it's costly, it impacts performance, key management uses.

Is this still having a discussion? Yeah, and quite literally in every single iteration of the delivery of the course. Sometimes I do it to public audiences with people from many companies. Sometimes I go internal and deliver it to people from one company. And it's still the same kind of concerns being brought up.

And a lot of them are no longer true. But they spent so long being established, it's hard to break that being the common understanding.

Ashish Rajan: The reason I ask that is because we do some Cloud [00:08:00] Security training, and the number of times it comes up, and sometimes cost is put as a factor as well. They will say, Like financial or CPU?

Yeah, no, so financial more. Yeah, because they'll say I already pay for a certificate server, I have to push that in the cloud, or there's an incentive for, say, Amazon to have my TLS, but I want to own the key for it. There's a nuance you go through, it's But it's amazing because you guys talk about passwords and getting data breaches and all of that as well.

The love people have to hold on to their key. How important is it? And I understand regulatory and all of that, but in the general context, how important is someone to really own the key in these days? And I haven't had a chance to discuss this anyone, so this is probably the first time talking about this.

Do you guys feel in the conversations you have, as a company, where we are in the world, where we're giving up a lot of controls to cloud and other places, of mostly infrastructure. Now they're asking us to do encryption as well. Is there value in store the holding or the encryption on our side?

Scott Helme: It's a weird one because like I host my application in DigitalOcean. Yeah, and they run our VPS's [00:09:00] so we obviously process all of our data in memory on those devices but then it feels like saying oh I don't want them to have my like private key for my certificate, my encryption keys, because they might be able to like decrypt my data.

But they sit on the end anyway. Yeah. Anyway, so really, you have to weigh that up and think what problem are you actually solving? If there is a circumstance there where there is some benefit, then sure, but generally when I see people suggest things like that, they're not adding anything by making that process more complex by trying to withhold the key from the service that's going to see the data anyway.

Troy Hunt: And further to that, what compromises are you making if you do your own key management? I was just thinking the most obvious example is a service like Cloudflare where it is, pardon the pun, but it's turnkey, right? It's you go and you add your DNS records and you get transiting through Cloudflare, by default, if you go in there and you configure everything by checking all the boxes, they'll do the key management.

They certainly do the key management for haveibeenpwned and everything else I have in there. If I took that on board, how are you gonna do it better? Yeah. Yeah. How am I gonna do it better? And then what problem does it solve given that by their very nature they sit in the middle of the traffic anyway.

Yeah. . Yeah. Where TLS is [00:10:00] terminated before they re:TLS it back to the origin service. To your point, if there's regulatory requirements, then it's, we often see regulatory requirements, which aren't always the most sensible, but you're stuck with it. That's, and you have to do it. End a discussion next problem.

But I think for the most part these days, yeah. I don't know if we get a lot of benefit, and we definitely see some downsides doing your own key management.

Ashish Rajan: Yeah, and to your point about, are you willing as a business to spend the extra economical cost behind it to do better than, say, a large enterprise has been doing it for thousands of other companies, which if it goes down, then potentially the Internet is going to stop kind of scenario.

Where's the trade off, and I don't know what the right answer is, but to your point, do you guys don't see, practical sense to an extent?

Troy Hunt: But I think a lot of this is just the entire cloud discussion itself. Are we willing to let go of control of things that we used to manage ourselves and delegate it to another party?

It's not all roses, there are upsides, there are downsides, but I think on balance in most use cases these days, letting go of everything from the hosting through to the key management is a positive thing.

Ashish Rajan: Yeah, [00:11:00] and would you say, now with the whole AI conversation coming up, as a natural transition from talking about, hey, I want to encrypt my data and encrypt my keys and all that, to now people are trying to build their own LLM models, they're all trying to build their own. Hey, I wanna be able to create models which are really helpful. My gen, my own version of ChatGPT in my own organization or whatever they wanna do it. And I'm sure there's a perfectly practical reason for it making business sense.

Does the conversation about data breaches, has that extended onto that as well or is that not a thing at the moment? 'cause I know it's still very in this one year ago, it feels like a long time right now in the ChatGPT World , but do we feel that, are we at that point on those conversations where data breaches and the GenAI, because I think OpenAI did have a data breach as well, memory, yeah, they had a hack or something.

Troy Hunt: I think they had some credential stuffing against them. Breach, not breach, different argument. Yeah, exactly, yes. But I think the thing that immediately comes to mind when you talk about people building their own LLMs part of it is because you get for example, developers in an organization taking a big chunk [00:12:00] of their proprietary code, dropping it in ChatGPT and going, how can I make this better?

You've just sent all of that to another party. How many cases, and I can't pick the name off the top of my head, but there's been multiple cases lately where organizations have been pinged for doing just that. You're literally taking internal information and by virtue of cloud based AI, sending it off to some other third party. So I get why an organization may want to provide facilities like that to avoid That sort of problem.

Ashish Rajan: I think apparently a lot of people are trying to put data in it to make better business decisions where it's coming from, like the idea of how do we scale out the data scientist requirements kind of thing, where we have a mountain of data, we want to make an LLM model out of it so that we can make better decisions and make better decisions.

I think the example and shout out to Daniel Miesler, who's been doing a great job with this. Him and I were having a conversation about imagine it's like an AI assistant for your business, where as a CEO, you walk in every morning and go, all right how are we looking financially today? Things that CEO would ask.

How are we looking from a cost perspective? Are we still on the right course? Instead of [00:13:00] asking 25 people different questions and they come up with a report, this thing would come back in maybe, I don't know, five seconds or hopefully less than a minute. So that is a very interesting future as much of a Tron future it is like and I think we're far from it Yeah, but that's what the industry wants to go to it.

So that to me was fascinating

Troy Hunt: But I guess the paradox there is that the more data you're able to give the LLM, the better job It can do with interpreting it. That's right. The more data you give the LLM, the greater the privacy risk

Ashish Rajan: Yeah, I think even like third party as well, right? Because I think one of the first conversations we had with people is around the fact that say I use, I don't know, Salesforce or whatever, I don't know if Salesforce is doing it, but imagine Salesforce is a very common sales software, they could be claiming that we use LLM.

What are they using LLM on? Are they using LLM on how to improve the internal process or how to make it better for the client? Yeah. I don't know. Like the discussion is out there. Yes. . So I think that , so that to me brings to the point about the whole encryption thing and own the key. Going back to it, [00:14:00] is there best practices for enterprise that you guys normally feel they should be, adhering to when they think about passwords, data, things like that? Or even encrypted TLS for that matter as well?

Scott Helme: I tend not to make a differentiation, like really, obviously outside of their regulatory obligations. Yeah. I think most of the advice for me remains similar regardless of the scale of the organization really because you know a lot of the time.

We're still trying to boil it down to almost the basic best practices You know we're not at a point where? We can push into some like really like technical thorough advice and then be super stringent. I feel so much of the time we're still consistently having to push you know what I would term the basics yeah, like we've got to get the basics right and build a solid foundation before we build on top of it and not to sound like too defeatist, but this is still where I spend a lot of my time and energy and focus.

At that level, the advice doesn't really change across industries. The basics are pretty consistent for me.

Troy Hunt: I think that the really important point Scott made is, I don't think there is a [00:15:00] differentiation between enterprise and anything else when we talk about things like password storage. To give you an example, I used to work for Pfizer.

As I just helped, everyone knows who Pfizer is now before no one knew. And I used to have to say, do you know what Viagra is? That's what we make. I didn't make that.

Ashish Rajan: I was going to say were you involved in that? So security software for Viagra.

Troy Hunt: But when, when we were there, if you think, and this goes back, what, nine years ago now that left, but even then, it's if you're going to store passwords, what are we going to do?

Are we going to be encrypted for argument sake? Now, if I was to go and build the smallest little non production trivial website sort of thing and it'd be like, how are we going to store passwords? You'd be cryptic. Like it, it would be the same thing. Perhaps the only decision that you might make differently in enterprises, maybe you delegate to a third party, like as your Azure active directory services or something.

You guys do all the management of it, but for a lot of decisions like that, or do we have TLS or do we use a free certificate authority instead of giving one of the big corporates kazoos into dollars? It's the same answer for every. Organization because it's [00:16:00] still the same mathematics and the same mechanics.

Ashish Rajan: Yeah, would it be different for a small to medium sized business or a startup? Same for them as well.

Troy Hunt: I think so take the password discussion. All right Today I was talking about websites that included things like a furry website If you want to build a website for furries, how are you going to store passwords bcrypt?

If you want to build a medium sized e commerce website, how are you going to store passwords, bcrypt if you're Pfizer and you're building a clinical trial system, how are you going to store passwords? It's the same answer every time.

Ashish Rajan: But would you say the most of the friction for people comes in from the fact that they think it's going to be expensive or or is the knowledge not generally available enough?

That's why it doesn't happen? Like, why is it?

Scott Helme: My blog is still heavily trafficked. We still sell out training courses. I still talk on these topics consistently and they're well received. And one of the things that strikes me, I've just done the two day hack yourself first workshop. And we're talking through like basic security constructs in some of the modules because it is aimed more at a beginner to intermediate level.

Like one of the fun things that I like to do at the end of the modules is okay, so who knew [00:17:00] about this like defense mechanism before today? And there's 30 people in the room and four of them are like I've heard of it before. And I was like, okay, so why has nobody deployed this?

And it's because nobody knew it existed. Talking about things like same side cookies, for example. Super basic protection from a really realistic threat. And people are like, wow, I didn't know that existed.

Troy Hunt: And how much does it cost you to implement

Scott Helme: it?

Troy Hunt: It's it's so But this is fascinating, there's like content security policies as well.

It's this is not an expensive firewall appliance, this is something that's built in natively to the browser with really broad support. Yeah. You need to configure it and get it right, but the only difference between those people and the people that aren't using it is just education.

Scott Helme: It's so common to see just people like, wow, I didn't know you could do this.

It's like we've got the standards body producing all these standards and the browser vendors implementing them and things like that. And then the developers building systems. And there's just like this huge void in the middle. And I'm there trying to yell between sides of this void.

Troy Hunt: Don't yell too loud, we want to stay in business.

Ashish Rajan: No, [00:18:00] that's why he's losing his voice now. Yeah. Yelling too much. I'm literally yelling at him too much.

To your point, maybe it's a good time to introduce then, what are some of the top, I don't know, three or four, maybe five that you think that, people who are listening to this, if they check any of the applications that you're hosting.

Are there any top five that you can throw at them to go, Hey, have you, just have a look at this. And then come back to me and sign up for my training or something.

Scott Helme: Password storage? Yeah there's so many easy wins out there as well. I think one of the other big takeaways from Hack Yourself First and doing this so many times now is, I think people think they're gonna have to spend a lot of money to get security right or put a lot of effort in.

And generally we can hit the 90 10 rule pretty solidly, right? It's you can get 90 percent of the gains, of the benefits, with quite literally 10 percent of the effort that people thought that they would have to put in. They've not started the 10 percent because they're off put by this idea that it's going to be really expensive, it's going to require significant amounts of effort.

And it often isn't the case.

Troy Hunt: I know we have a vested interest because [00:19:00] we run training, but time and time again, like the best ROI is just teaching people to do things better because you learn at once and you apply it again and again on every project. And that's before you even get to the discussion of if you don't know how to do this properly and you have an incident, what will the cost of that be?

That's a bit of a long bow to draw, but the ROI training is just extraordinary.

Scott Helme: You can't beat it, there's no, like training is as far left as you can go in the development life cycle. And the further left in the development life cycle, we go to introduce security knowledge, the better.

And literally in people's brains is the leftmost point on any development life cycle diagram.

Ashish Rajan: Yeah. There's no ChatGPT there. Yeah. But would you say, so what are the top five that you would, password storage one recommended? Because I guess imagine most applications these days are hosted on Cloud or about to be hosted in cloud. So browser still is more important because the application is still hosted on that space.

Scott Helme: So security headers. And really, it's the funny thing is, it's so what is security headers? It's an education tool.

Ashish Rajan: So Actually, what is security headers for people?

I don't, that's how people know about security headers.

Scott Helme: Security headers was this fun little [00:20:00] tool that I built gosh, in I think 2014 or 15. And you can go there, type in your URL for your website, and we'll scan it and look at the kind of basic security. configuration features that we have available. So there are certain HTTP response headers that configure security controls in browsers.

And obviously the vast majority of people don't have any of these security controls configured. So we'll point that out and be like hey, okay, you can turn on, ABC and this is what they do and these are the benefits. And it's fun, like you get a little grade from like an A plus down to an F and it's green or red and I gamified a bit because if someone scans their website and they get a D, the first thing is like Screw this guy, I want an A.

It's now we're gonna go improve our security just to stick it to Scott, and I'm like, I win. Many people view it as like a security assessment tool or something like that, and it's not. It's an education tool, with a little bit of fun on top, to try and basically encourage people to read up on things that they didn't know about, obviously, which is why they don't have them and they got a grade D.

It's not a security assessment tool, it's a, it's an education tool disguised and the [00:21:00] gamification helps people want to you know, improve their security. Not because they want to improve their security, because they want the A+ But I'm fine with that. I'm like let's go.

Ashish Rajan: The funniest part with that is all the, so in case we enterprise people don't know about it, those are the emails that they get from people.

Hey, I noticed you don't have enough security headers. If you pay me money, I would fix your security headers. I'm like, what?

Troy Hunt: That's a big bounty. Yeah.

Scott Helme: Yep. It's either that or SPF records. They're the only two things that I ever get. That's pretty much it.

Ashish Rajan: Anything else that you would add to the list? Like you have security headers, password storage, any like low hanging fruit that people can basically

Scott Helme: Security dot text.

Oh yeah. You've got to have. As you literally talked about this in the keynote, we've done another big disclosure this last week. You're never gonna get everything right on your own. And when somebody else spots that you haven't done something right, there has to be a reasonably low friction way for people to get in touch with you now.

I'm sure loads of organizations and people are familiar with bug bounties. Not everyone's gonna have them, they're not for everyone. Like this one that I found, gosh I actually found it last year, in November. [00:22:00] And, we've desperately been trying to reach out to the company. I've raised support tickets, emails, customer services.

We've like LinkedIn DMed and Twitter DMed everybody that we can find that says I work at this company and just got nowhere. And it was like two days ago when you tweeted it now, so Trey was like okay, we'll rebroadcast this loud now, because we've tried everything. Yeah, we've literally exhausted anything we can think of.

Short of saying, which we joked about the other week, I was like, I wonder if we know anybody in New York that could just knock on my door. And I was like, when you're at that point, I'm like, okay, we've exhausted all possibilities now.

Troy Hunt: I wonder if that actually happened. Is that why they actually answered?

Because literally it was Monday, so I'm going to send the tweet at like primetime New York time, but also when the West Coast is up, because there might be people there, and eventually someone is just going to go and grab someone.

Ashish Rajan: Some investor is going to look at this and go,

Scott Helme: Yeah, could be. But hopefully, so the idea of a security. txt file, if people are unfamiliar, is it's just a tiny little text file and we have these directories on websites that are like standardized and you can put like various config files and text [00:23:00] files and things in there and one of them is called security. txt and it's if somebody finds an issue with your site and they want to contact you, you can literally just put a security contact in this tiny little text file and then if, something really bad happens and you get a phone call from Scott or Troy we know where we can go to get your contact details to speak to the right person.

And they're still super underutilized. Security researchers exist, responsible disclosure exists, and people still treat you as the enemy with, some notification about things.

Troy Hunt: In their defense, it's because there's so many idiots that pop up and go found security vulnerability. Bug bounty, please.

Yeah. And then you say SPF. Yeah. But this is, again, the paradox we deal with. This is where I think bug bounties have got a good role to play because I'm sympathetic to organizations that do get an influx of reports that it is frivolous. Because they've got to somehow separate that.

Also, a bunch of people that are reporting serious stuff, like today, I spoke in the keynote about someone trying to report a really serious incident in Grindr a few years ago. And this was like full account takeover. Massively bad. And they had so much trouble getting it through, but I was reading their [00:24:00] message again before I did the keynote.

And, like some of the English is a bit broken, some of it looks like it could be a little bit scammy. I get the situation. But then I also get why people get to the point where it's I'm so frustrated this company isn't paying attention, I'm just going to exploit the thing, dump all the data, and give it to Troy, and then I'll get their attention.

Yeah. Which is not what we want. This is not the desired outcome.

Scott Helme: It's a tricky one, like my opening email now, like I have a bit of a template for responsible disclosure and I have other people, also you mentioned today other people will come to me, but I don't have a public profile, nobody knows who I am, can you get in touch with this company?

And my kind of like template for responsible disclosure is not like, to blow my own trumpet, but it's oh look, like here's the link to me on all of the BBC shows and the news and please don't sue me. Yeah. And I'm linking to all of the things to try and prove my kind of pleasant intentions kind of thing and be like, look, I've been on the TV.

I'm not some crazy. I don't need your money. I just want you to listen, please. And also don't sue me.

Ashish Rajan: Oh, because the other one started with hey, are you going to pay me money? So I can actually solve all the security problems. Yeah, but to your point I love the perspective. The security [00:25:00] disclosure program is at the really easy low hanging fruit irrespective of application, cloud, hosting, whatever.

Password storage was also mentioned. I think you guys called out the security headers as well. It's a top three. Yeah, they can people can walk away and then cost no money. They can just do it themselves as well. Perfect.

Scott Helme: Same with TLS, right? Use encryption more. Use better encryption. Doesn't cost more money to use newer protocols, newer cipher suites.

You can get certificates for free from multiple places. Now it's not like Syncrypt anymore where you get free certificates. Another common misconception. Now you've got like Bypass which is actually Norwegian. They're based here in Norway. We've got like Google Trust Services. So Google now have their own public CA that you can just get free certificates from.

Oh, and, yeah, we've got like SSL. com, we've got 0SSL. So it's, There are now multiple places where you can simply go and obtain free certificates to deploy good encryption.

Troy Hunt: And still multiple places where to charge you a fortune. Yes.

Scott Helme: There's lots of those. That's a scam.

I see the twist on that. What are we paying for certificates for now? Support? I'll do the support bit. You go get free certificates and then pay me for [00:26:00] support. I'll do that part.

Ashish Rajan: Oh yeah, because, I guess maybe that's a good point as well.

There are trade offs for going for a free cert. Nothing.

Scott Helme: From a pure security standpoint, nothing.

Ashish Rajan: Even for renewals? Because you know how a lot of people talk about auto renewals, that, oh, I can only renew for one year, I have to keep renewing it every year.

Scott Helme: And this is one of the things that we teach in my TLS courses.

Once you automate, do you care how frequently you have to renew? If you're fully automated and I said to you, you now have to renew every seven days, would you be bothered? Exactly right. From the con job more frequently.

Ashish Rajan: That's like a direct debit happening in real life

Troy Hunt: Part of the education piece as well, I don't think a lot of people thought this through, is if you've got a one year renewal, and your certificate gets compromised on like day one, Yeah.

How long is that certificate valid for?

Ashish Rajan: Three sixty four days.

Troy Hunt: If you've got a three month certificate, and you get compromised on day one, how long is it valid for?

Ashish Rajan: Yeah. And to add to another layer to that as well, The rotations, the cert rotation. Many people don't even have the process defined for it as well.

How do we rotate the password? Oh, it's like next year problem. And then there's like exercise once a year, everyone's Oh, okay, we need to get to meet Scott, Troy, everyone's getting on the call right now.

Scott Helme: And then that person has left the department, [00:27:00] and that person has left the company, and then the certificate expires and the website breaks.

Troy Hunt: If it's important and repeatable.

Ashish Rajan: I guess the bottom line of the episode is Automate TLS, put security headers, password storage, and maybe check out haveibeenpwned.com with email as well. The last section, the non technical section is fun questions. Three fun questions, not too many.

First one being, what do you spend most time on when you're not trying to solve all the password problems and TLS problems in the world?

Troy Hunt: As in terms of something for myself?

Ashish Rajan: Yeah, could be non professional,

Scott Helme: could be professional.

Troy Hunt: Most definitely non professional. Ah probably playing tennis

Ashish Rajan: good point. What about yourself, man?

Scott Helme: Cars. Cars? Cars so I've got, I've been into cars forever. I modify my car. I just bought a new race car. I'm racing in it. Championship this year. Oh, wow. Yeah, we go to watch the Formula One. Yeah, motorsport is definitely my thing. Fair enough.

Oh, yeah,

Troy Hunt: me too.

Ashish Rajan: Cars. Yeah okay, cars and tennis. Second question being what is something that you're proud of that is not on your social media? I made a child [00:28:00] that you're proud of?

Troy Hunt: I made two children. He's got the AirPods in.

Scott Helme: Yeah, I think for me, like being successful, but not you skipped over your child.

Oh, I can't just copy your answer. Being like my goal when I set out was not to build companies that would be profitable that he was to build things that would be helpful. And I really enjoy that like seeing the success of some of these projects. Security Headers doesn't make any money. It's it's literally a free thing.

Crawler ninja doesn't make any money. But when you build something and people get value from it, I'm like, yeah, that's what I was trying to do. And I don't talk about that a lot because it seems sometimes a bit like self ingratiating, it's like I draw a lot of satisfaction from that awesome

Ashish Rajan: and what's your favorite cuisine or restaurant that you can share?

Scott Helme: Oh, we're going today. Oh Actually going we're gonna have the same answer.

Ashish Rajan: Oh It's for your favorite restaurant is in Norway. Yes. Yeah,

Scott Helme: and its not Norwegian

Troy Hunt: The one we go back to most regularly so way down south barbecue in Oslo and like we've done a lot of shows. You've been to Texas, haven't you? Yeah, we've done a lot of Texas, a lot of barbecue around the world.

Scott Helme: And yeah, [00:29:00] that is just consistently the best. What?

Ashish Rajan: Better than the southern Oh yeah.

Scott Helme: I've been, I've done Like the Formula One recently in Austin, Texas, and yeah, we hit a few barbecue joints there, and I was like, they're on par, don't get me wrong, but like here in Norway, which is really odd, they've managed to replicate it, and it's just so bizarre.

Ashish Rajan: You need to name drop this place. Way down south, WDS. It's literally what it's called, Way Down South.

Scott Helme: Way Down South, yeah. Their tagline is, Put some South in your mouth.

Ashish Rajan: That's a lot of the questions that I had, which I think will be valuable. But, where can people find you guys on the internet? Where can they find about training?

You can just type in, haveibeenpwd.com

Scott Helme: troyhunt.com, scotthelm.co.uk, securitheaders.com reportui.com, crawler.ninja Google us, we're on Google. I think they have my data.

Ashish Rajan: Thank you so much for coming on the show. I really appreciate you guys hanging out and sharing the best practices for, hopefully, people using the low hanging fruit so we can make the world a little bit better.

Fingers crossed. Thanks, man. Thank you so much. Thank you, everyone.

‍