Do you run any code that listens on an open port on the internet?
This could be a website, a RESTful web service, or GASP even, a database endpoint.
Troy Hunt, a renowned security expert, likes to say that you're doing free penetration testing for that product right there.
Join Troy and me on this episode of Talk Python to Me.
We discuss lessons learned from running the vulnerability monitoring website Have I Been Pwned,
as well as other lessons for developers to keep your code safe while providing public services.
This is episode 136, recorded October 26, 2017.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via at Talk Python.
This episode has been sponsored by Rollbar and GoCD.
Thank them both for supporting the podcast by checking out what they're offering during their segments.
Troy, welcome to Talk Python.
Hey, thank you very much for having me.
Yeah, it's really great to have you on as a guest.
I've respected the work you've done in the security space immensely, and I'm looking forward to sharing what you've learned about software security and developers with the audience.
Cool. Awesome. Let's do it.
Yeah, let's do it.
Now, before we get into all the details, let's start with how you got into programming in the first place.
What's your story?
That's a good question.
So I was a little bit anti-computer when I was a kid, probably up until about teenage years.
And I was actually very frustrated by my friends who'd be inside on the computer.
I'm like, come on, man.
I want to go outside and play football or something like that.
What are you nerds doing?
And then I guess I got into it by, I moved overseas when I was a kid.
So this was when I was almost 14.
My family moved to the Netherlands.
And it's kind of cold over there.
And like you get into it.
A lot of dark evenings.
The sun goes down to what, like 2.30?
Yeah, well, this is a little later, man.
No, just kidding.
Yeah, yeah.
But it gets, it's pretty dark in the winter there, right?
It is.
I mean, for folks in the UK, it's basically like the UK.
But, well, I won't say something derogatory about the UK.
You can read my Twitter feed for that.
No, we love them, honestly.
So anyway, there's a lot of time spent indoors.
And I just started getting involved.
I think I must have started doing a bit of basic back then.
So this would have been sort of early 90s as well.
And I think really for me, though, so I was doing a bunch of sort of PC-related stuff in
my teenage years and doing part-time jobs at PC repair stores and that sort of thing.
But the thing that really hooked me was seeing the web.
So I started using the web in 95 when I started uni.
And it was just like, wow, this is awesome.
This is amazing.
I want to build stuff for this.
And really, that was the start of modern day life as I know it in terms of what I do.
That's awesome.
Yeah, I had the same experience.
I was a sophomore or junior at university when the Mozilla?
What was the first before Netscape?
Before Netscape?
Yeah.
Something very real.
Mosaic.
Oh, Mosaic.
Yeah.
Yes.
When Mosaic came out.
And I was just like, oh, my gosh.
Like, the entire world opened up.
It was such an amazing time.
And it seemed like it's funny because technology was so much more limited.
And what you can do on the web now is way more impressive.
But the world seemed so open back then, right?
Yeah, yeah.
I don't want to reminisce in so far as, oh, so awesome, McMahon.
Because frankly, it's so awesome now.
And it's really a lot more awesome by any reasonable measure.
Yeah, for sure.
But it was just an exciting time where we're sort of seeing stuff that didn't even resemble
the things that we'd done before.
Yeah, I had the same feel.
And that was awesome.
So now, what do you do day to day?
More stuff on the web?
More stuff with security?
Yeah.
So look, it's a bit of both.
It's funny.
In fact, I've been thinking the last couple of days because I've had, I don't want to say
downtime, but I haven't been rushing somewhere.
And I was sort of going, what am I going to do today?
Like, I'm entirely independent, so I can do pretty much whatever I want.
And that consists of sort of several main things.
So I still do a lot of traveling and speaking at conferences.
I'm trying to do less of the traveling just because of how much I've been away.
But I'm still doing a lot of that.
I'm still doing a lot of workshops.
I was down interstate last week doing a workshop.
I think I've probably done this same workshop.
I must have done it 25 times this year.
25 two-day events.
The workshop is Hack Yourself First.
So I usually go into, say last week it was into a large financial institution and then
another online retailer.
And I'll go in there for two days and I'll sit down with usually developers, but also regularly
project management or managers, QA people, DBA, security folks, and go, okay, let's spend
two days figuring out the mechanics of things like SQL injection and cross-site scripting.
Here's how they work.
Here's what you do to be resilient to them.
And it's very, very sort of hands-on, active sort of stuff.
And it's just like, it's a huge amount of fun for everyone because we get to go in and break
stuff in ways that they've never been able to before.
And everyone leaves with this sort of new appreciation of the mechanics of how these
attacks work.
And they end up building better software for it, which is a good win.
Yeah, it's definitely a great win.
And I think sometimes you just have to see these things in action to really appreciate how your
security and the code you're writing is not actually secure.
I mean, even something as sort of old school as SQL injection attacks, like when you first
start writing SQL strings, you're like, well, I need to put the variable here.
So plus, plus quote thing, you know, how could that be wrong?
Right?
It just works.
But I think totally seeing it go, oh my gosh, do we do that?
Because if we do that, I just see how horrible this is going to be.
That's it.
It's the hands-on, you know.
It's like the light bulb moments when people do that.
And SQL injection is a great example because, you know, like you said, it's something that's
been around for a long time.
And we sort of think of this as an old thing.
It's still number one in the OWASP top 10 most critical web app security risks.
You know, it's still up there, even in their 2017 revised edition, it's still number one.
And when I do the workshop and I demonstrate SQL injection, I show things like there's a blog post
I refer to written by a guy who's trying to teach people how to do password resets in
ASP.net.
And literally within the one screen, he's got good, resilient, parameterized SQL statements.
And we're looking at this going, is this okay?
Yeah, yeah, it's okay.
Because you've got parameterization.
And then like the next line, there's an update statement.
And it's just like inline concatenated SQL with untrusted data that you can totally own.
And then he connects to the database with a privileged account.
And it's like, yep, good night.
Like the whole thing's over.
And there's still material, new material out there teaching people that.
And here's another fun one.
You can go and do, and be careful with this, folks, if you go and do this.
You can go to Google and do a Google Doc search.
So one of these sort of searches that turn up things that aren't really meant to be there.
And you can do a search for inurl.php?id equals.
And I think about the first half a dozen results have got an integer somewhere in a query string.
You load the page up.
You put an apostrophe on the end of it.
And bang, there's an internal SQL exception.
So very, very high likelihood of having a SQL injection risk.
And this sort of stuff is just absolutely rampant.
Yeah, that's really scary.
Why do you think it still is a problem?
I mean, it's 2017.
We've got ORMs and ODMs that generally protect us against these things.
We've got an XKCD, Little Bobby Table.
I know.
If that doesn't teach people the lesson, I don't know what will.
We've had it for years.
I got him on a T-shirt, actually.
I used to wear it at conferences.
People love it.
Oh, that's wonderful.
I'll have to put a link to that in the show notes.
So why does this all happen?
I think there are multiple factors.
So, you know, I just gave one example.
People are still creating training material that's vulnerable.
And in fact, one of the reasons why I show this blog post is that I actually left the
guy a really nice comment.
And I literally said, here's some friendly feedback.
And being very constructive, I gave him this feedback.
It's just like the comment sitting there.
The guy's never replied.
And then after that, there's been a whole bunch of people that have chimed in and said,
thank you.
This is very useful.
And I'm going, didn't you just read like the big, long, friendly comment from the Australian
guy saying like, this is really just full of holes.
Don't do this.
So we see this propagate over and over and over again.
And ultimately, so many of these risks just fundamentally boil down to the people building the software
and not being familiar with how something like SQL injection works.
And that is just purely a competency issue.
Yeah.
I guess that part of it is like you kind of hinted at the copy and paste stack overflow
type of thing.
Although I suspect it would take a pretty good beating on stack overflow.
But you know, this copy and paste sort of thing.
And we have so, our technology and languages and libraries we use changes so quickly that
people are, I think a lot of people are just scrambling to keep up to make things work,
much less be secure.
So that the copy and paste thing is funny.
In January last year, I was running the workshop we just spoke about in Norway.
And part of this workshop, there's a module on looking at mobile APIs.
And one of the guys in my workshop says, all right, look, I want to look at the way the
app for my Nissan Leaf, or in the US you'd say Nissan, the car.
So the way my car.
Yeah.
So, okay.
How does my app talk to my car?
Because he could control features of the car from the app.
Now, this is not something we have a problem with in Australia, but apparently in some parts
of the world, it is so cold, you've got to turn your car on before you get in the car,
you know, like turn the heating on.
And this is one of the things I have to do in Norway because it's so freaking cold there.
So he's like, all right, pulls out his app and he's figuring it out.
And what he discovers is that the only thing that the app needs to know about the car is
the car's VIN number.
Now, for folks who may not be familiar with what a VIN number is, first of all, this was
being used like an API key.
It was a secret.
Second of all, it was printed in the windscreen of every car.
So you could literally walk past a car and it had its API key in the windscreen.
And it was worse than that too, because they're innumerable.
So you can just take the, in this case, I think we could take about the last five digits and
just keep randomizing numbers and finding different cars.
And based on what he found in the space of literally sort of single digit minutes, we
discovered that you could control our climate control features of the car.
You could pull back trip history, battery status, all sorts of things.
It was just crazy.
Shouldn't have happened.
That's crazy.
And if there's any vulnerabilities, you can, you're like, you can own the car basically,
right?
Because you're talking to it.
Yeah, God knows.
You know what I mean?
And when we say you're talking to the car, let's be clear.
You're talking to, you're basically talking to a web server and not a web server in a car.
We can come back to the things people put web servers in later.
You're talking to a web server on the web running an API.
And then that goes back end over some proprietary GSM network or something to the vehicle itself.
So there is a proxy in between.
Yeah, that's not too bad then, I guess.
Well, so here's where it kind of went worse.
I disclosed it to Nissan and we had chats on the phone and, you know, they were like, yeah,
we probably should fix this.
Yes, you probably should fix this.
And then time goes by and they're not fixing it.
And eventually we get to like a month after disclosure and they've stopped replying to messages
and nothing's happening.
So I write about it and then suddenly they decide it's important.
So they take the whole thing offline.
And it's offline for about six weeks and eventually it comes back online and they've got a new app and everything.
The funny thing about the app, and this is the relevancy to Stack Overflow and code reuse,
is that down the bottom of one of the screens there's this really odd text.
And the text is something like,
the spirit of Stack Overflow is developers helping developers.
And this isn't an app for your car.
And we're looking at this going, what are you doing?
Why would you put that in there?
And then, of course, we found the Stack Overflow post where they've literally copied and pasted the text from the Stack Overflow post without understanding what it does.
Put it in the app that controls features of your car.
That's incredible.
Honestly, folks, if you Google for this, Google like,
Nissan Stack Overflow code reuse, and it's just like, this is insane.
How does this happen?
I mean, how does this happen at all, let alone in a car or software to control a car?
Yeah, I feel like the companies that have these types of IoT-like things that are really valuable, you know, not a light bulb, but cars and humans travel in them at high dangerous speeds.
They should really be careful about this, right?
Yeah, they probably should.
They probably should.
Maybe you should send them an email about that or a bunch.
Yeah, well, afterwards, they were like, if you find any other stuff, please do send us an email.
I sent you an email.
We had phone conversations.
You were endorsed.
What happened?
Anyway.
Wow.
So, do you know if any of these car companies run bug bounty type things?
Yeah, no, Tesla does.
In fact, Tesla runs a bug bounty through Bug Crowd.
Bug Crowd is a bug bounty as a service platform started by a mate of mine who's done extremely well moving over to the U.S. and getting funded and doing wonderful things.
And bug bounties are becoming absolutely massive now.
It's great to see him doing well, but it's great to see this being a big thing in the industry now as well.
Yeah, I totally think it's a very positive thing.
I suspect most people listening to know what bug bounties are, but maybe just define it for everyone.
Yeah, so a bug bounty is effectively acknowledging that maybe the right way to put this is everyone who has anything online is continually getting free penetration tests.
So, there are always people out there probing away at your things.
And a bug bounty is a means of saying to people, look, if you find vulnerabilities in our software, if you find things that could be dangerous, like SQL injection, submit them here.
And there's usually a formal process.
You know, this is the email address to send it to.
This is the information we need.
Here's how to encrypt your communications.
And then, depending on the vulnerability, you may be incentivized.
So, you may actually get anything from a T-shirt to a large amount of money.
And this is a really neat way of recognizing that we do have flaws in software.
This is the nature of building software.
And that if someone finds it, it is actually worth something.
And the sort of value proposition of the bug bounty is that it incentivizes people to report these things responsibly and allows the organization to handle them and fix them before someone actually goes and exploits nasty things.
And obviously, there's some incentivization for that in a monetary sense.
And these are becoming really big.
So, you know, we mentioned Tesla.
The Pentagon has run a bug bounty.
Like, these are going really, really mainstream.
And there's a lot more to it than just some random hackers sitting in a basement on the other side of the world trying to break into your things as well.
They can be very, very carefully managed programs with well-selected testers.
Yeah.
Like, the Pentagon one, you had to kind of interview and be approved to be part of it.
It wasn't just, now everybody go forth and attack the site, right?
You couldn't be Australian either or anything else that wasn't American, as I understand it.
That's unfortunate.
Well, you know, like, it's the freaking Pentagon.
Like, I kind of get that.
And frankly, just the fact that they ran that and it became such a more mainstream thing that entered into people's psyches in places it just wasn't before, I think is a very positive thing.
Yeah, I totally agree.
It's a positive thing.
And this money can be pretty large.
Like you said, it could be a t-shirt, but it could be $100,000.
And this incentive has been there recently.
Like, if there's not a bug bounty, there's probably some other bad actor who's willing to pay $50,000 for a good O-Day, right?
That's the thing.
And then we sort of get into this interesting space of who is competing for the dollars of the bugs.
And look, some people will argue that there are still actors out there that will pay a lot more than what the organizations with the potential vulnerability will.
But then at least you sort of get to have a little bit of weight on the other side of the scales in a monetary sense.
And of course, from a legal and an ethical perspective as well, there's always the incentive to try and report things through the formal channels and get money.
But yeah, look, there'll always be nefarious parties willing to pay for this stuff as well.
Yeah, at least now there's some option to monetize that and make it part of your living and do the right thing.
Exactly.
Yeah.
This portion of Talk Python to Me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Relying on users to report errors, digging through log files, trying to debug issues, or getting millions of alerts just flooding your inbox and ruining your day.
With Rollbar's full-stack error monitoring, you get the context, insight, and control you need to find and fix bugs faster.
Adding Rollbar to your Python app is as easy as pip install Rollbar.
You can start tracking production errors and deployments in eight minutes or less.
Are you considering self-hosting tools for security or compliance reasons?
Then you should really check out Rollbar's compliant SaaS option.
Get advanced security features and meet compliance without the hassle of self-hosting, including HIPAA, ISO 27001, Privacy Shield, and more.
They'd love to give you a demo.
Give Rollbar a try today.
Go to talkpython.fm/Rollbar and check them out.
Speaking of looking at breaches and disclosure, you're running a pretty amazing website called Have I Been Pwned that has really grown in terms of awareness for when these breaches happen, right?
Tell everyone about Have I Been Pwned.
Yeah.
Well, Have I Been Pwned has been running almost for four years now.
I've got to think about a birthday thing to do, actually, because it will be, I think, late November, early December will be the four-year anniversary.
And I started that after the Adobe data breach.
So Adobe was about 150 million records from memory.
And at that time, I'd been doing some analysis across sort of different data breaches, you know, looking for patterns.
Are people using the same password?
Well, guess what?
Yeah, they are.
Are people appearing in multiple different incidents, you know, like the same person?
And I was sort of seeing stuff.
I thought, like, I find this really interesting.
I reckon other people would find it interesting if they could see where they are exposed as well and particularly see things like, you know, you're exposed in these multiple places.
So that was sort of the genesis for the project.
And I built that out with my 100 and I think it was a total of about 155 million records.
So it was basically just about all Adobe when I launched it.
And I was like, wow, this is massive.
And I was actually, I built it all out on Microsoft's Azure platform as well.
And I really wanted to spend time using Azure in anger.
So, you know, how can I do something that actually uses a lot of storage?
And how can I use things like the table storage construct instead of relational databases to save money and make it go faster and all the rest of it?
And that was sort of a bit of a hobby project too.
And now sort of fast forward to nearly four years later and there's 4.8 billion accounts in there, which I still find to be a bit of an unfathomable number.
That's really incredible.
Incredible.
That's more than half the population of the earth.
I mean, I realize it's not one-to-one person to account, but still, that's staggering.
It is crazy.
And there's just sort of all sorts of metrics about the project that just exceeded any sort of form of expectation.
So that's one of them.
The visitor stats, an average day is somewhere between 50,000 and 70,000 people come to the site.
A big day is seven figures.
So I think I had about 2.8 million in one day the other day.
What was the driving factor behind that?
That's a good question because there's always a trigger, right?
So it's to sort of deviate from that baseline by an order of multiples.
In that case, there was this spam bot.
So it was called the online spam bot.
And a security researcher in France discovered this spam bot where, unfortunately, or fortunately, depending on your perspective, whoever was running the spam bot didn't do a great job of actually securing their data and left 711 million email addresses exposed.
So he managed to grab all this data and sent it over to me.
And I went, OK, well, let's load 711 million records in here.
It's not a breach in the traditional sense, but it is data about individuals redistributed over the Internet.
Let's load this.
And of course, a huge number of people were then interested in it.
And that sort of made a lot of news headlines.
And this is the thing that really drives the traffic.
It's news headlines because every time there's a data breach, I see a spike because it's on CNN or the BBC or something that faces the masses and not just the tech audiences.
So it's sort of really interesting to see how broadly appealing the project has been.
Yeah, I think it's a great service.
And I've gotten probably five or six emails from your service saying you've appeared in some breach or other.
Usually it doesn't freak me out too much because I use one password and my passwords are 40 characters long and they're unique per site.
So I hear a lot from people saying they hate getting email from me.
So I apologize to everyone that's had an email from me.
Don't hate the messenger, right?
Come on.
Well, exactly, right?
Yeah, cool.
So the one that really stands out to me that you were pretty well highlighted in, it actually had some interesting ethical components to it, was the Addison Mashley one.
Just make it look like you don't know the name.
That is a great defense.
Well done.
Thank you.
I've heard of it.
Honestly, darling, I've never heard of this site before.
I have no idea why my email address is.
So this is like an adult friend finder, let's have an affair type of thing.
And it got hacked.
Because not just people's passwords and possibly reused passwords were leaked, but just the fact that you even existed on the account was a pretty bad data breach.
You had to even be a little careful about letting people know or searching for that data, right?
Yeah, well, look, I mean, Ashley Madison, just for context for everyone.
So this was a data breach that happened in July 2015.
And hackers said, hackers, we still don't know who it was, said, look, we've got the Ashley Madison data.
These guys, we don't agree with their business model.
And OK, many people took an ethical stance on the whole context of this is not like a dating site.
It's not like an outright adult site.
It is literally their whole MO was helping people have affairs.
You know, their strapline used to be life is short, have an affair.
So they were, I guess, trying to mainstream adultery.
And obviously, a lot of people took issue with that ethically.
So whoever it was that got their data, said, look, we got the data.
These guys have been bad.
We don't like the business model.
If they don't shut down in the next month, we're going to dump the data publicly.
And this was kind of interesting on many levels.
I mean, we do see threats like this, but often we see threats that are more financially motivated.
We will see threats that say, you know, give us Bitcoin or we'll dump your data publicly.
But in this case, they just obviously took an ethical dislike.
And it was kind of interesting as well, because part of the original reasoning was what Ashley Madison did.
And this is a this was a real dick movie in anyone's books is they said, look, you know, you sign up to this website.
If you want to remove your data, you've got to pay for this full delete service.
And from memory, it was about $19 to delete your data.
So what would happen is there were a lot of people and I had I had literally hundreds of conversations with people on the site afterwards.
And I was learning there are a lot of people who'd maybe have a couple too many red wines one night and go, hey, this might be fun and sign up and then, you know, this wasn't a good idea.
And then they'd forget about it.
There are a lot of people in there who were single.
There are a lot of people who look again, regardless of your ethical position on it, were consenting adults.
And they decided they wanted to use the site.
And then if they wanted to get off there, they're having to pay money, which is just it's just a reprehensible move.
But obviously, they thought they could monetize that.
But anyway, one of the things the hacker said, as I said, when you pay for your full delete, you're not actually getting deleted.
And what we discovered after we actually saw the data is paying the money would null out your record in the membership table.
And then there would be a payment record with a foreign key back to the membership table.
And the payment record would have your personal data on it.
So it's like, yes, we removed you from the database.
By the way, you just created a payment record.
And the payment record has your personal info on it.
So they took an ethical dislike to it.
And in a way, it was kind of fortunate the way it panned out and that we had a month's notice between saying we're going to dump this and it actually happening.
And I had time to think about how would I handle this and have I been pwned.
Because it turned out to be more than 30 million records.
So it was a very large breach.
And I kind of went, look, this is going to be valuable data if it does turn up.
And I want to make it searchable.
But by the same token, this is the sort of thing where I don't want to be the vector through which, let's say, a rightly jealous wife discovers that her husband has been on the site.
And incidentally, this was a very, very heavily male-dominated service, which probably comes as no surprise to anyone.
And the women that were on there, a huge number of them signed up from IP address 127.0.0.1, which is a little bit suspicious.
That is a tiny bit suspicious, yes.
Yes.
And actually, this is one of the things we learned, right?
They're actually FEM bots, you know.
So I always think Austin Powers, every time I hear FEM bots.
I don't know if it was exactly like that.
However, you've got these accounts on there, which are effectively bots, which are trying to engage with men.
Because the more you can engage with them, the more you can get them to pay and all sorts of shady stuff.
So anyway, eventually the data does get dumped.
And by virtue of having had time to think about it, I had decided that I'd introduce the concept of a sensitive breach.
And a sensitive breach means the data still goes in Have I Been Pwned?
But you can't publicly, anonymously search for someone else.
So you've got to actually subscribe to the notification service, which is free.
But the reason I use that mechanism is because that sends you a verification email with a unique link.
You click the unique link, and then it says, okay, now I know that you control this email address.
We'll show you everything.
So the public ones and the sensitive ones.
Pretty legit way to handle it.
Definitely the way the website handled the breach didn't sound like it went well.
Let's talk about one more breach before we move on to some developer topics.
One that you did write about was Disqus, the comment section, which actually is at the bottom of your show page, right at talkpython.fm/136.
I suspect you could find Disqus right there.
And you said that these guys, while something happened in terms of a data breach, they handled it right.
Yeah, and you know, it's at the bottom of my blog as well.
And it's also my data in the Disqus data breach.
So I think that the macro picture here is that when data breaches happen, there's a real broad range of reactions from organizations involved.
And they range from, on the one hand, being extremely difficult to get in touch with, sometimes denying it, often downplaying the severity, sometimes covering it up, like knowing there was a breach, but not telling people because they're worried about reputation damage.
And doing all the sorts of crappy things that you might expect an organization at the receiving end of one of these things might do.
And then on the other hand, there's sort of like, this is exactly the way to handle it.
And Disqus was very much on that right-hand side.
And there's really only a couple of organizations I've dealt with that have been down there.
And the things that Disqus did really well, one of them is the speed.
So everyone would have seen Equifax in the news only last month.
And Equifax took about five weeks after learning of the data breach to advise everyone.
They needed to sell their stock.
Well, geez.
Allegedly.
Well, they did sell stock.
Allegedly because of the breach.
You've got to be careful.
Right, right, right, right.
People get very litigious in America.
I know this.
Yes, that's right.
Actually, I've heard this.
Fortunately, I don't know this through personal experience.
But the thing with Disqus is that I got in touch with them.
And actually, just to be clear as well, the context we've discussed is someone popped up and gave me seven different data breaches.
And they're things that I had never seen anywhere before.
It was things like Reverb Nation, Kickstarter, Bitly.
And all of these three had previously disclosed where they'd said, hey, we've been hacked, never seen any data for it.
And then suddenly they all turn up in this one place and they're all legit.
And then one of them as well was this Disqus one.
And I'm trying to find references to a data breach.
I can't find anything.
And there's 17 million email addresses in there.
So fortunately, I had a contact there, someone I'd been chatting to only a couple of months earlier on another topic.
And I was like, I think I have your data and you probably should know about this.
And from the point where I sent that first email to when they had made a public statement and had already reset impacted passwords as well, I think it was 23 hours and 43 minutes.
It was just under a day.
And it's like, okay.
That's awesome.
That is awesome.
Like you guys have turned this around less than a day.
And when I spoke to them, so we jumped on the phone as well and had a good chat.
They were sort of really, I mean, obviously they weren't happy about the situation.
No one's going to be.
But they sort of understood that this is the reality of operating online today where these things do happen very regularly.
They prepared communications, which was transparent, candid, honest.
They worked with the media as well.
So one of the things I was sort of impressing on them is I think it's really important to engage with the media because there's going to be stories on this.
And you can either ensure that those stories are representing your point of view and your version of events or you can say, look, we're too busy or we don't respond to the media and you can let them form their own opinions.
So they just did all of that right.
And the only negative feedback I saw out of any of this was people saying, well, how come it took you four years?
Because apparently it actually happened in late 2013.
Well, they didn't know.
And we still don't know.
Well, I haven't seen any press as to how it happened or why it took this long to know.
But I guess based on the hand that they were dealt a couple of weeks ago, the way they handled it was just exemplary.
One of the things that's always kind of in the back of my mind, I've run a number of websites, have a couple of servers, some backend servers.
I talk to those servers.
You know, how would I know if I've been hacked?
Well, as we've just seen, you may not.
And this is sort of part of the problem.
We've got to remember as well that the discuss situation is far from being exceptional.
So just off the top of my head last year was LinkedIn, Dropbox, MySpace, Last.fm, Tumblr, many others that were in similar boats where they had had breaches years ago and were only just discovering it.
And incidentally, that big stash of data that had Bitly and Kickstarter and all the other ones in it, there was another one.
I'm thinking very carefully before I say these words because two of them haven't been disclosed yet.
But there was another one which was a service called We Heart It, which seems a little bit like Pinterest.
That was in there.
And there were two others which were still waiting.
One of them should be sending their message out any moment now, which is millions of accounts again.
And then a final one, which I'm still trying to get in touch with some people.
Not everyone replies to an email when you say, hey, you've been breached.
They might pretend it went to spam and just go dark, right?
Yeah.
Well, they won't be able to once I've published the data and have I been pwned.
But I'd really like to give them the opportunity to control the messaging themselves first.
But what we've got to remember with all these cases is they happened years ago, very often with entirely different people in the organization as well.
Very often with different infrastructure, different code bases.
Very often you're not even going to have logs that go back, say, four years.
You know, do you really keep web server logs that long?
A lot of organizations don't.
So it can be enormously difficult to know when an incident has actually happened.
And I guess your point about how do you know, one of the things that sort of continues to strike me is that there are all of these incidents that have already happened that we don't know about as the public.
And then a subset of those, probably a very large subset, where the organization themselves doesn't know about it as well or don't know about it.
So we're yet to see so much stuff actually come out of the woodwork that we just haven't even begun to conceive of yet.
Yeah, that's kind of daunting.
It's sobering, isn't it?
Yeah, sure.
So it sounds to me like a lot of the time this becomes something that we're aware of because the data is discovered.
You're like, oh my gosh, these accounts are all coming from this one place.
There might be people that use like their email address, like my email address plus LinkedIn at gmail.com.
And you're like, well, I only use the plus LinkedIn at LinkedIn and it's out in this paste bin or something, right?
Well, when people do that, so when they use that sort of aliasing pattern where they have this sort of plus after the alias or when they have their own domain and they create custom aliases for every service.
Right.
LinkedIn at my domain.
Yeah.
Yeah, right.
That does actually help.
In fact, one of the ones I'm going through a disclosure with now, and this is sort of the last out of the seven that was in the stash I just spoke about.
It wasn't immediately clear where all the data was from.
It's labeled one service, but I was actually checking with have I been pwned subscribers saying, hey, look, you're in here.
Have you used this service?
And a bunch of them were saying, you know, no, I've got no idea what it is.
And it was only when I started going through looking at things like the aliases on email addresses where it's like, oh, okay, I can actually see this other thing now.
And I was able to kind of join the dots and go, okay, well, I can see that this is actually from multiple different sources.
I think it's actually from two different sources.
It does seem like at least a little bit of a breadcrumb.
I don't do it that often, but sometimes I do.
Yeah.
No, it can be really useful for that.
The other thing that I hear people saying is I say, look, I use this aliasing pattern because then I can see when my data is, say, sold or redistributed or something like that.
I can see where the source was.
The problem then, of course, is what are you going to do about it?
Like we know that this happens.
And if you go back to the organization and say, hey, I signed up on your service and I signed up with my name plus your service name at gmail.com.
And I've just seen I've just gotten spam trying to sell me Viagra.
Okay, now what?
You know, like there's not really anything that's actionable.
Yeah, I've heard that.
And actually, I've been on both sides of that story, not with stuff that I'm doing these days, but previous project.
And, you know, how much weight should you put in that?
Like on one hand, I feel like, yeah, okay, if somebody really got all the data out of the database, they would have those things that they could email people.
But it seems like that's a weird thing to do is just spam folks.
On the other hand, if somebody breaks into that person's email and just harvests every email they see and just start sending to it,
maybe it's their account that got broken into and just happened to be they kind of loop back.
Well, you know, this is also one of the great mysteries, right?
Where there are so many different ways that these things can go down.
And very, very often, you just simply can't get to the bottom of it.
I mean, people say to me all the time, like, I'm getting spam.
Where's it come from?
I don't know.
It's like you put your email address out all over the place.
It could be from anywhere.
Yeah, that's right.
Get a good spam filter and just buck it up, I guess.
Exactly.
This portion of TalkPath in a Me is brought to you by GoCD from ThoughtWorks.
These are the people that literally invented continuous integration.
They have a great open source on-prem CDCI server called GoCD.
But rather than tell you about the server this week, I want to share a course they created for people who are new to continuous integration.
Check out their course called Continuous Delivery 101 from GoCD at gocd.org slash 101.
This video series covers the history of continuous delivery, concepts, best practices, how to get started, and popular tools.
You'll gain a holistic view of continuous delivery and a deeper understanding and an appreciation of the critical concepts.
Be sure to try their course at gocd.org slash 101 and let them know that you appreciate their sponsorship of Talk Python.
Speak to the web developers out there.
What lessons have you learned from running Have I Been Pwned that you'd like to share with that audience?
There are a lot of things, you know, speaking or sort of thinking about it from a pure dev perspective.
Going back to what I was saying earlier, one of the main reasons I wanted to do this is because I really wanted to do something in anger on Azure.
And I've had a heap of fun, to be honest, building this service out on Azure and sort of experiencing the whole cloud scale thing and commoditized pricing and all the other sort of promises of the cloud.
And there's a heap of learning out of that, both good and bad.
I mean, some of the good stuff has been things like the ability to have auto scale, you know, so actually provision more infrastructure on evidence of exceeding existing infrastructure resources is fantastic.
And I've spoken many times at events about how to run a project like this on a coffee budget.
So how do I run a service with 4.8 billion records and sometimes millions of visitors a day for what you'd spend on coffee?
And I don't always manage to do that, but I usually get pretty close.
And things like really managing your scale very carefully have been great.
Things like choosing the right data storage constructs for your use case have been great as well.
So particularly in sort of the Microsoft-y world, there's been this traditional view of you're going to store data, you've got to have a SQL database.
And a SQL database is a behemoth of a thing, right?
I mean, it is a big, big thing.
And it's expensive and it's...
Especially with four point something billion records.
Well, hey, look, if I got to that point, if I was actually trying to put that data in a relational database like SQL Server, I mean, the cost would just be astronomical.
But it would also be really unnecessary because the patterns with which the data is used just don't predispose it to needing a relational database.
So one of the best things I ever did was to use Azure's table storage, which is basically just a key value pair.
And I just petitioned it in a way that worked really well.
So those 4.8 billion records are in there.
You can create a petition and then a row key.
So my petition keys are the domain.
So say gmail.com.
And then the row key is the alias.
And what that allowed me to do is do super, super, super fast lookups.
Because when you're searching, you're literally searching by domain and alias.
So a very specific petition and a very specific row key.
And it also made it really easy to do entire domain wide reports because I just pulled the entire petition.
So that works awesomely.
And that is still the single best decision I've ever made, I'd say, in terms of the architecture.
So for those 4.8 billion records that on disk is some tens of gigabytes, they actually don't have good reporting about actual size.
And it always scales infinitely.
So it is platform as a service.
I've never reached any scale capacity on the storage tier.
And it usually returns records within sort of a single digit millisecond range.
And that cost me about $40 a month.
Awesome.
Yeah, which is just like, how cool is this?
It just rocks.
One of the other really, really big things I've learned is I started using Cloudflare for Have I Been Pwned about a year ago.
And look, I've been using them on things like my blog and a couple of other little projects.
And it was kind of cool for that in that you get HTTPS for free and a few other little sort of bits and pieces that make things like my blog run a lot better.
But it made a massive difference to Have I Been Pwned.
And I originally did it because I was getting DDoSed and that sort of, that wasn't fun.
And Cloudflare put a stop to that.
But then it became really, really awesome because you have things like a firewall that you can control programmatically.
So one of the reasons I put it in place was the API I have, I introduced a rate limit because I was seeing some fairly nefarious behavior to it.
And I went, oh, look, I'll just put a rate limit in.
And if you exceed the rate limit, I'll return a 429 too many requests and say you can retry after two seconds.
And they'll see that and they'll stop.
But no, they don't.
They just kept hammering it.
And one of the pennies that dropped was that when you expose that sort of origin server to the world, you have to deal with everything there.
So you have to deal with every incoming request on that same infrastructure, which is actually trying to reserve legitimate requests.
And when you put a service like Cloudflare in front, suddenly you have this other layer in front where you can start to programmatically exclude nasty stuff and actually free up the underlying resources to do the things they're meant to do.
So I've got some great rate limiting implementations.
I've got a really neat model I've written about before using Azure Functions where even when I see behavior that's slightly nefarious on the website itself, I just drop in a JavaScript challenge rule on the Cloudflare edge node so that if you go to the site, it just makes sure you're in a browser and you can't automate it with an API.
And then you basically get a 24-hour timeout and then you can try again.
So it's been awesome for that.
That has also been super awesome for reducing my cost because I cached the bejesus out of this thing.
So Cloudflare has got 118 edge nodes as of today around the world and everything from the front page to the FAQs to every single image in JavaScript file and CSS file is served from those edge nodes.
So the actual traffic that comes through to the site is usually just API requests and a couple of other dynamic things.
So it's really, really dramatically reduced my costs and the frequency with which I need to scale my infrastructure.
Oh, that's really cool.
And Cloudflare is actually in the news recently this week, a couple weeks ago, for announcing basically unlimited DDoS production.
So yeah, that's cool.
It's the world we live in today, isn't it?
And look, that was sort of their traditional thing, right?
Like they made their name out of DDoS protection.
But they do so much more now because they can sit on the wire and intercept that traffic.
And that spins some people out as well.
And if you are listening to this and you get spun out by it, I've got a blog post about security absolutism.
So if you Google my name, security absolutism, you sort of see me try and put things in perspective.
But it means you can do stuff like all these websites that are now going HTTPS because they're being sort of forced down this route.
You can go HTTPS for free via Cloudflare within about five minutes.
And not only that, but they can also do things like add an HSTS header because when you can intercept the traffic, you can add headers.
They can rewrite HTTP references to HTTPS.
They can 301 all of your insecure requests over to secure requests.
And they can do all of this stuff because they're sitting there controlling the traffic.
And that just makes a huge amount of sense for many, many good reasons.
Yeah, that's cool.
And you don't have to worry about it.
Yeah, yeah.
It's like literally a turnkey thing.
Yeah, that's cool.
Yeah, I don't use it, but I've considered adding it.
And it seems like it might be a good idea.
I should be quiet.
Somebody might try to attack my...
No, you know what?
And it is like a five-minute job too.
And people go, yeah, but you can just go to Let's Encrypt and get a certificate.
And they're right.
And Let's Encrypt is absolutely awesome.
But it is just certificates.
And there is so much more that you can do with a reverse proxy like Cloudflare.
Like once you actually use it in anger on a large-scale site, you go, wow, how would I ever not?
You know?
Right.
And even if it's a small site or a static blog or something, it still makes an enormous amount of sense because of stuff like the caching.
Cool.
Yeah, it definitely sounds like it's worth checking out.
So one thing I wanted to talk to you about is WannaCry, which was a real sad thing that sort of was a ransomware thing that went around just encrypting all the things.
And it took out a bunch of places.
The most notable one, I guess, was the National Health Service in the UK.
That's right.
But it also took out things like Maersk, FedEx, a bunch of places, right?
WannaCry seems to me like a real lesson in just being vigilant and patching all of your stuff and keeping it up to date.
But there's tons of things that were way out of date.
What do you think some of the lessons are from WannaCry?
Well, just one thing on that, actually.
The Maersk one was NotPetya.
So NotPetya came, I think it was about a month or six weeks after WannaCry.
It wasn't that long.
Right, right.
There were similar times.
Yeah, it was similar.
But, yeah, yeah, there's similar times.
And look, it's still ransomware.
Look, you don't want either.
All right?
The thing that was really interesting about WannaCry is the sort of sequence of events leading up to that.
Without having the exact dates in front of me, from memory, WannaCry hit us in May.
And back in March, we had seen Microsoft say, look, there are some critical patches.
You really should take these critical patches.
And they didn't really elaborate why they knew they were so important or so timely.
But, you know, maybe you should just really just do this right now.
Exactly.
And then a month later, we saw this sort of shadow brokers dump.
So this collective that has collected themselves a bunch of zero days.
And one of the vulnerabilities in there was this eternal blue vulnerability which exploited SMB.
Which we'd normally use for sort of connecting and file systems and sharing information across them.
And the problem there was that you could remotely connect to a machine with a vulnerable SMB implementation and have remote code exec on it, which is really nasty stuff.
And, okay, now we're saying, all right, so a month ago, Microsoft said patch your things.
Now we know why it was important.
And then another whole month went by.
And then WannaCry hit.
So by the time someone got hit with WannaCry that was exploiting Eternal Blue, two months ago, they knew it was a big thing.
A month ago, we knew why it was a big thing.
And now you still haven't patched your things.
And really, the lesson out of this was around patching.
And this was just such a sort of, I guess, poignant example of why it was so important.
Because this was devastating.
I mean, it hit particularly the NHS.
But it hit everything from German trains through to other services and other parts of Europe in particular really, really hard.
And what sort of stunned me is after that, a lot of the stuff I was writing and talking to people about was this whole patching cycle where there were still people going, I disable Windows updates.
And there's literally tutorials out there.
How to disable Windows updates because maybe you'll get a bad one.
And I would have people sort of justifying turning it off.
They're like, well, I don't like it because sometimes you go down, you got to shut down your PC and it says you've got to wait while updates install.
And once I was about to get on an airplane and I couldn't close my laptop.
That's your reason.
But actually, my favorite one was a bunch of people would say, I keep installing all these stupid updates.
I've never even had a virus.
Yeah, but that's why you haven't because you install the updates.
You know, it's certainly an important part of it.
So to have that happen and then have NotPetya occur just after that, which again was exploiting a number of exploits.
But one of them was an unpatched or rather a patched vulnerability, which people had left unpatched and then got exploited.
Right.
If they didn't learn from the first two times around, they should have really learned from WannaCry.
I know.
Exactly.
Anyway.
Yeah.
The reason I bring this up is not to just talk about these crazy viruses and patching.
But I think there's a real tension in organizations and the larger the organization, the greater the dissolution of responsibility in this is to say like, look, there's this system that's running our invoices.
Nobody knows how really to upgrade it.
And nobody wants to be the one to take the responsibility of patching it because if it goes down, their weekend is toast.
We're just going to leave it.
Not my problem.
Someone else's problem.
Right.
How do you think we address that?
Look, it's a good observation.
And we've got to be fair here that we don't sort of overly trivialize the complexity that can be involved in actually patching these things.
I mean, think about the NHS for a moment and think about what hospitals run and some of the systems they have.
Think about an MRI machine.
You know, imagine actually trying to patch that thing.
And look, there's a bunch of them probably sitting out there still running Windows XP.
You know, you don't just like whack in the DVD and upgrade to Windows 10.
This is not a simple process.
So I'm sympathetic to that.
And I suspect that what happened in cases like the NHS is there's budget constraints.
In fact, we know there's going to be budget constraints in a hospital.
There's budget constraints.
The IT managers had to make a call between where that budget gets spent, what's patched when, how much money they allocate into different areas.
And it would have been a very hard problem.
And large enterprises are not exactly just running Windows update automatically across everything either.
I mean, these things are tested and rolled out through standard operating environments.
And they're a big thing.
And I think, to be honest, like the bigger picture here is that when there is a high friction of updates, it makes the uptake very difficult.
I mean, one of the things that Apple's done really well is they've made it such a low friction process.
You know, like, hey, iOS 11 landed the other day.
A thing popped up on my screen and I said yes.
And I never had to worry that it wouldn't work.
And if it didn't work, I would have restored from iCloud while I went out and, you know, kicked the ball with the kids or something.
And I'd come back inside and I'd be done.
So, yeah, that's really the model that we'd love to move towards where these things are low friction and automated.
And unfortunately, that's just not the reality with a lot of systems today.
Yeah, absolutely.
The more complicated they get, like it could be like a library that's compiled into your code that you've got to upgrade.
For example, with the Equifax one, right?
Yeah, the struts in Equifax.
That's right.
And like they had to like recompile and, you know, who knows what got deprecated, what had to have been changed.
Granted, that doesn't excuse them.
They really messed that up.
But still, it's not that.
It's a little bit hard trying to throw Equifax a bone.
But look, I mean, that is something where it's like, okay, let's just be objective about it.
I can see where when it struts and you have to like go and recompile some pretty serious stuff as well.
It comes back to that point about the friction.
And when there is this high friction of change, well, yeah, it's going to be hard to get this stuff done in a timely manner.
Yeah, absolutely.
Absolutely.
So we don't have a lot of time left.
Let's talk a little bit about IoT.
You wrote an interesting blog post.
I think it's a blog post called,
What It Would Look Like If We Put Warnings on IoT Devices Like We Do on Cigarette Packs.
Tell us about that.
Yeah, yeah.
That was fun.
So the sort of premise of this is a lot of IoT stuff's got some pretty crazy vulnerabilities in it.
Now, one of the ones I saw a couple of years ago is that there's these kids' tablets.
So imagine if Fisher Price made an iPad.
This is sort of my vision of it.
So it's plasticky and colorful and all this sort of thing.
And these were made by a company called VTech, Hong Kong-based toy maker.
And VTech had a vulnerability that someone exploited, sucked out millions of parents' and children's data.
And the kids' data included things like their names, their birthdates, their genders, their photos, foreign keys to the parents with the parents' physical addresses as well.
So it was like from a stalker perspective, it was kind of the worst possible thing you can imagine.
I know, it was like super, super creepy.
And, you know, like this was really bad news.
And someone did break into their systems, but they had some shockingly bad aspects of their security there.
I mean, stuff like, I wrote a blog post at the time.
You would log in.
And when you log in via, they had a little flash emulator for the tablets.
Okay, there's another hint.
Some things are going to be wrong.
So there's a little flash emulator.
It calls an API.
The API returns a JSON response, which contains the actual SQL query executed in the database.
And it's just really, really weird stuff like that.
And it wouldn't surprise me at all if it was just classic SQL injection that the guy got in with.
Anyway, they had a bad time out of it.
And they were in the news only a couple of weeks ago because a class action against them didn't succeed, which frankly, I agree with.
I think people trying to mount a class action against a company where the data was exposed but contained.
It was never spread.
It was never abused.
It was just a bit of a money grab.
I think the regulators should be pinging them.
That's a different story.
But anyway, so they're in the news.
And this one story pointed out that their terms and conditions today effectively say you could get hacked.
Someone could get your data.
That's your problem, not ours.
I kind of replied to them or quote tweeted them and said, look, how about you put this on the front of the pack?
And it was a little bit tongue in cheek, right?
Because if you put that in the front of the pack, no one's going to buy your freaking tablet.
And I was thinking about it later.
I was like, it's almost like it's a dangerous good, you know.
And in Australia, what we do with dangerous goods like cigarettes is we put great big warning signs on the front of the packs.
And they're very graphic.
And they tell you how bad stuff can be when it goes wrong.
This can kill you in slow and horrible ways.
Let us list them.
I know.
And they're super, super graphic in Australia as well.
So I thought, all right, well, look, why don't we do this with IoT?
We'll literally just put these things on the front of these IoT devices like we would a cigarette pack.
So I just did this blog post with a bunch of mock-ups of what would it look like.
And it's, you know, there's sort of warnings on everything from the VTech tablets to teddy bears to automated dog feeders.
And that was a rather popular post.
Yes.
Warning.
You acknowledge and agree that your child's intimate voice recordings may be placed in an unsecure Amazon S3 bucket.
Oh, cloud pencil.
Oh, my God.
Oh, yeah.
That's pretty funny.
I think it makes a good point.
And I guess maybe just a final thought on IoT.
Like, do you think things are going to get better?
Or is it just going to continue to be a bunch of unpatched badness?
No, of course they're not going to get better.
I mean, there's just nothing that predisposes it to getting better.
When you look at the factors that are driving the growth of IoT, you know, we want to be first to market.
We want to put internet in things that were never meant to have internet.
And if you want to know what I mean by that, just Google WeVibe and we'll leave it at that.
So there are all sorts of things.
Wait, wait, wait.
Do that in an incognito window.
Look, you know what?
You'll find news stories on it.
And let's touch on that in a mature, responsible adult fashion.
So these are toys for adults and they are internet connected.
And what I find fascinating from this in a very kind of mature way is that this is digitizing data we never had before.
So it actually stored usage data.
And whilst these devices have been around for eons, that the concept of actually recording the use, everything from the modes that was used into the times of day, reference to the identity using it, we never had that before.
And now we have this new class of data, which is enormously sensitive by virtue of the fact that we've internet connected the things.
And the reason you'll find them in the news is that they recently got fined up to $10,000 per owner of the device because they were collecting this data without consent.
And you can imagine for the owners of them, I mean, that must be absolutely gut-wrenching to think that this sort of data about them now exists on a server somewhere.
Definitely.
It's quite troubling.
Yeah.
So I don't know.
I think you're probably right.
I think that there's going to be a lot of trouble with these types of things.
Just the incentive to keep things updated is not very good.
I did recently get an electric car and I have a charger for the car that's on the internet, which makes me a little nervous.
But I logged into it the other day and it had updated itself within the last two weeks.
So maybe the higher end devices will be a little bit better off.
Yeah.
Look, I think the devices that are doing these auto updates are the way we're going, right?
And some of them do it very well.
Some of them do it still with requiring user action, but sort of very low friction.
I hope that's going in the right direction.
But geez, there's so many things out there where something has gone fundamentally wrong in order to require the update in the first place as well.
Yeah.
Yeah, absolutely.
Yeah.
I mean, there's the danger that you could brick the device.
So there's that same type of hesitation to actually put that security patch in like that you have with the big companies, right?
Like no one wants to brick everything they've sold.
I know.
There's also that.
So, all right, I think we're just, I have so many questions I'd love to chat with you about and maybe someday we'll do a follow up and I can ask the other ones.
But I do want to give you a chance to talk about your courses because you've written a ton of PlutalSite courses and they're actually really, really valuable, I think.
So maybe touch on some of the ones you feel are notable for my audience.
I think the one which is most notable at the moment is the one that's still pinned to my Twitter timeline.
I do intend to leave it there for a little bit, which is what every developer must know about HTTPS.
And I love the HTTPS discussion at the moment because there are so many, so many angles to it.
And it's such an important time as well.
So, for example, back in January this year, we saw Chrome and Firefox start to warn anyone if they went to a login form or a credit card form over HTTP, even if it publishes or posts rather to HTTPS.
And that was an important change.
We're here recording in October and Chrome 62 has just hit.
And in 62, they are gradually enabling the feature, which now does the same thing for any page with an input form as soon as you type a character.
So you can go to like CNN, click on the search link, type any character into the search box, and then suddenly you get a big not secure warning.
So that makes things really, really interesting.
Like that's really starting to push HTTPS.
And the sorts of stuff I talk about in the course are things like, I think a lot of people know, you're meant to make sure that all of your embedded resources on the page are done so over a secure connection.
Otherwise, you lose your padlock and your green text and your secure in Chrome.
But there are tricks to help you do this.
So there are things like there is an upgrade in secure requests content security policy.
So you can add a response header or you can put it in a meta tag.
And if you accidentally put anything in securely on the page, then the request automatically gets upgraded to a secure one.
Oh, that's nice.
So there are all these neat little tricks like that you can do, which make HTTPS so much more easily accessible.
And a lot of time when I hear people saying I'm having problems because of this or that or whatever, it's like there are usually things like response headers, the CSP, also HSTS to enforce HTTPS connections for all requests.
You know, those sorts of things are just fantastic.
And that's what a lot of the course is about.
Okay, cool.
I'll definitely link to that and a couple of other ones in the show notes that I thought were pretty cool.
You also have a nice article on getting started in ethical hacking as a career.
So that's cool as well.
Yeah, I guess we're going to have to leave it there for the topics.
I always have two questions I ask at the end.
So let me ask them to you now.
The one of them is if you're going to write some code, what editor do you open up?
Usually Visual Studio.
Okay, right on.
And now normally I ask about libraries and Python.
You don't do that much Python.
So I'll give you a pass on that one.
I'm going to give you a variation on this.
So what password manager do you use?
So I'm like you.
I use the password manager called 1Password.
Now, I said the password manager called that because if you just say I use 1Password, people are like, what is wrong with you?
Well, people should be like, what is wrong with you?
You're using it everywhere.
What are you thinking?
I know.
So look, I still use that.
I'm a little bit agnostic in so far as I think, frankly, so long as you're using a mainstream professional password manager like that or LastPass.
Honestly, that's going to make your life so much better in so many ways.
So use one of those things.
Yeah.
It definitely makes your blood pressure stay pretty cool when you find that there's been a password breach.
Yeah, that was 40 characters random.
I'm going to reset it.
Not a big deal.
That's it.
Yeah.
Right on.
Okay.
Well, Troy, thank you so much for being on the show.
Any final call to action for everyone listening?
No.
Look, I mean, if you want to learn any more, go to TroyHunt.com or find me on the Twitters as Troy Hunt.
All right.
Awesome.
I'll be sure to put those links in the show notes.
And thanks for being here.
Good on you.
Thanks, mate.
Yeah.
Bye.
This has been another episode of Talk Python to Me.
Today's guest has been Troy Hunt.
And this episode has been brought to you by Rollbar and GoCD.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.
GoCD is the on-premise, open-source, continuous delivery server.
Want to improve your deployment workflow but keep your code and builds in-house?
Check out GoCD at talkpython.fm/G-O-C-D and take control over your process.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my WritePythonic code course at talkpython.fm/Pythonic.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I really appreciate it.