#418: How To Keep A Secret in Python Apps Transcript

00:00 Think about the different APIs and databases your applications work with.

00:04 Each one of them requires either an API key or a database connection string that itself contains a password.

00:11 How do you let your application access this sensitive information without storing it in source code or putting it in other compromising locations?

00:20 On this episode, we have Glyph on the show to share his security fable as well as just good advice for keeping secrets out of Python code.

00:27 This is Talk Python to Me, episode 418, recorded May 24th, 2023.

00:33 [music]

00:46 Welcome to Talk Python to Me, a weekly podcast on Python.

00:49 This is your host, Michael Kennedy.

00:51 Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython.

00:56 both on fosstodon.org.

00:59 Be careful with impersonating accounts on other instances, there are many.

01:03 Keep up with the show and listen to over seven years of past episodes at talkpython.fm.

01:08 We've started streaming most of our episodes live on YouTube.

01:12 Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.

01:20 This episode is brought to you by JetBrains, who encourage you to get work done with PyCharm.

01:26 download your free trial of PyCharm Professional at talkpython.fm/done-with-pycharm.

01:33 And it's brought to you by the Compiler Podcast from Red Hat.

01:37 Listen to an episode of their podcast to demystify the tech industry over at talkpython.fm/compiler.

01:44 Glyph, welcome to Talk Python to Me.

01:46 - It's good to be here.

01:47 Thank you very much for having me.

01:48 - It is good to have you here and it's good to have you back.

01:52 You've been on the show a couple times, way back when you talked about shipping software to users.

01:58 And then also not so long ago, a little while ago, we talked about running Python in production.

02:04 And those were a bunch of fun shows and really excited to now talk about secrets.

02:09 Although it does pose a bit of a problem.

02:12 If we talk about secrets, are they still secret?

02:14 - That is an interesting epistemological question.

02:18 But luckily that's not the question that we need to answer today.

02:21 'Cause the kinds of secrets we're gonna talk about, other ones that are meaningless.

02:25 They are by definition, not very interesting to humans, but to computers.

02:29 - Yes, they are.

02:30 They're both for you to access your database and cryptocurrency people to get cheaper crypto mining.

02:37 - Yep.

02:38 - Depending on which way it goes, if you do it right or wrong.

02:40 - So before we get into that though, let's just do a quick catch up.

02:42 It's been, gosh, at least a year since you've been on the show, a little bit more.

02:47 So what have you been up to?

02:48 What are you doing these days?

02:49 - I am nominally independent now.

02:52 I am trying to make a career out of having good ideas and putting them on the internet.

02:58 Worked for a lot of different companies, doing a lot of different things.

03:00 Now I am making my own app.

03:01 I'm making an app called Pomodorobros, which is a terrible name that I'm sure you can't spell, but I'm sure we'll have some links in the show notes to get to that, which is a ADHD time blindness assistance app.

03:13 - Interesting.

03:14 - So on the one hand, I'm kind of leaning into the neurodiversity thing.

03:18 I have ADHD and I'm kind of trying to help other people with it as well.

03:21 But also it is written entirely in Python.

03:24 I'm working on the Mac version first, but there'll be other versions later and it's all open source.

03:28 And so I have a Patreon at patreon.com/creatorglyph, which has just terrible reward tiers.

03:34 Hopefully I'll improve those soon.

03:36 But the idea is if you want to support like various open source libraries that I'm working on maintaining, we'll talk about a couple of new ones that I've released recently in this podcast.

03:46 If you want to support the random stuff that I do, now you can.

03:50 And so we'll see.

03:51 People have been telling me for years that they love the stuff that I do.

03:54 So I guess we'll find out if they in fact do.

03:57 - Well, congratulations.

03:59 That's really awesome.

04:00 As somebody doing independent stuff myself, I know how rewarding it is, but also how stressful it is, especially early days.

04:08 - Yep, it is equal parts harrowing and amazing.

04:11 - Yes, that's well said, well said.

04:14 So yeah, certainly we will link to those in the show notes.

04:17 You give me the links, I'll throw them in there for people.

04:19 You said something interesting that I don't hear a lot of people say that I actually wish I heard more often was, "I'm working on a macOS version," and the word's Python.

04:28 So this is actually, it kind of dovetails with what we're going to be talking about today in an interesting way, which is that one of the things that I want to be doing with my independent work is kind of letting people program their own computers.

04:42 And part of that is like a lot of people use Macs, So I'm working on Mac desktop stuff. I hope to do some mobile stuff later.

04:49 I also want to do Linux and Windows desktop versions of this app and then others.

04:53 Because I think that it's, we've lost touch with that a little bit.

04:57 We all do stuff in the cloud these days, particularly in Python.

05:01 But Python's so versatile and you can use it in so many places.

05:04 And the way that that dovetails with what we're going to be talking about today is that it's also a neglected part of the security story.

05:11 story. Because no matter how great all of your cloud security is, you're using AWS Secrets Manager and HashiCorp Vault and all kinds of cloud security stuff, it all terminates at your computer. If your computer is not secure, if the secrets that you have locally in your possession are not properly managed, then all of the cloud stuff, you're doing it from your computer. So that computer had better be And if it's not, that kind of flows outward towards everything else if you're a developer or a sysadmin.

05:43 So, yeah, so the two libraries that we're gonna be talking about today are also both, they're a little bit more traditional kind of console text things, but they are designed to be run on your computer and not on the cloud.

05:55 - Yeah, absolutely.

05:56 That's a lot of interesting things for like, how do you secure secrets, connection strings and whatnot on your machine, right?

06:03 - Yeah, so, and as far as the other to their desktop programming stuff.

06:06 We do not have time to get into that today, but you can definitely follow my blog for more interesting details about how PyObjective-C works.

06:13 - Right, are you willing to share a quick what GUI framework you're using sort of thing and how are you packaging it up or not yet?

06:20 - I wrote a little tool called Encrust that does some of the code signing stuff.

06:24 I'm packaging it with Py2app right now.

06:26 And it's for GUI framework.

06:28 I'm just using PyObjective-C and writing all of the GUI by hand as like a traditional Mac.

06:33 I plan to redo the GUI for each platform 'cause Commodore Obrus is a thing that needs to be a local Mac app, like it can, or a local desktop app rather.

06:41 And so I really want to get the UI very kind of finely tuned per platform.

06:47 And so cross-platform GUI toolkits don't really do some of the stuff that I need to do.

06:51 So, and that's kind of part of the point I want to make with it is, it's actually not that hard to just like write things multiple times.

06:57 The Python lets you keep all the logic in a nice kind of core.

07:00 And then if you need to call some native APIs, Python can do that pretty much everywhere.

07:05 >> Okay. Well, very interesting approach.

07:06 I think one of the things that's held me back from going, "Oh, I'm going to use TK enter or GDK or whatever." It's just like, "Oh, but it just doesn't really look like it belongs here that much." It looks like it belongs here, but not really.

07:20 Some people don't mind that.

07:21 To me, I'm not a big fan.

07:23 I'm looking forward to this. It sounds great.

07:26 >> Cool. Maybe you can have me on again to talk about it when it's closer to done.

07:29 >> Yeah, absolutely. It'd be fun to talk about going through and building how you built it and some lessons that you've learned, right?

07:36 Also, I'm working on some desktop apps now and it's not as easy as it used to be.

07:41 It's like, oh, this one's not signed.

07:43 And so it won't open because the macOS gatekeeper says it's probably dangerous.

07:48 And you're just like, God, I used to be able to just hand out an app, right?

07:51 We can't have nice things because of people.

07:53 And I guess that's pretty much a great lead into this entire talk, because if we could have nice things, we wouldn't even need this talk, would we?

08:00 - Exactly.

08:01 I guess it's worth mentioning that I reached out to you and had you on the show here because you gave a talk at PyCon, how to keep a secret.

08:10 And what is it today?

08:11 It's May 24th, so a month and two days.

08:15 And I was kind of looking forward to watching all these on YouTube and they're not out yet.

08:19 So how about we have a podcast episode about it and share that with everyone.

08:24 So I'm looking forward to kind of doing the audio conversational version of your talk.

08:30 How did your talk go there?

08:31 I thought it went great.

08:36 There was a pretty good response in the audience.

08:36 One of the things I did, which I would recommend for other conference attendees and speakers in the future is whenever anybody came up to me and said, "Great talk," which is very nice, I appreciate it when people do that.

08:47 I didn't just say, "Thanks," I said, "Thank you, and how is this going to affect your behavior going forward?

08:52 What did you learn from the talk that's going to change what you do?" And a lot of people had specific things that they were going to change about their workflows their kind of personal security.

08:59 And so that was telling me like, I think this is an important message to get out there.

09:02 And I think that it's something that every developer should know about.

09:05 So the fact that people were like really learning from it, I thought was the best metric for success.

09:10 - It's got a lot of small lessons for many people.

09:13 And I suspect most people are not doing all of these things.

09:17 So even if you're like, yes, of course I keep, you know, I don't put secrets into my source code, or do you?

09:24 But there's something else, I'm sure there's something for everyone here.

09:26 So let's kick things off by talking about what you mean by secrets.

09:31 All right.

09:31 What are we talking about here specifically?

09:33 So the main kind of secret that I'm talking about is a token type of secret.

09:39 Whenever you use an API on the web, they'll give you like a little hex key, usually a short string that lets you access it.

09:47 Cryptographic secrets, like if you have some encrypted blob that's stored in block storage, You might have CryptoKey that's a similar kind of thing.

09:58 For your HTTPS certificates, you've got like, you know, private RSA key or something or ECTSA key that's a little bit longer, but still kind of text file that's no more than 20 lines.

10:09 And so all of those secrets are kind of interesting.

10:12 And I wanted to talk about them in particular because the way that security works just on computers generally is that all of your other security, all of the other bigger secrets you want to keep the confidential documents, media files or whatever it is that you're securing, your database, your user accounts, all of that stuff is secured by a smaller secret.

10:34 And so these secrets generally represent some kind of authority, like a thing that you can do in the cloud.

10:44 Even the cryptographic ones are kind of like the authority to decrypt another secret.

10:47 And so that's in particular the reason that restriction of the scope of this discussion to those smaller secrets is interesting, is because those smaller secrets don't have a lot of interesting storage requirements.

10:57 They're very small, and it's really about how you secure them, not so much about how you manage a huge scale of them.

11:04 Yeah, also, if you're going to, say, encrypt huge blobs of data, usually what you actually need to get back to it is just the encryption key, pretty small, right? So even if the actual data is large, usually the thing that is the access to it is also small.

11:21 Right.

11:21 What you said you were not covering, encryption and that kind of stuff, right?

11:25 There's a lot of other security stuff that you need to do. Like I touched briefly in the talk on disk encryption. We can talk about that in a little bit, but it's mostly not about that. In particular, like there's been a lot of discussion lately about end-to-end encrypted messaging between people, and I'm not really talking about that either.

11:43 This is really about securing your applications.

11:45 It's a lot of these techniques have to do with how you get your secrets, not just secured for you, but like into your Python code in a way which keeps them secure kind of on the whole journey from typing them in to using them in a production application.

12:01 - For sure, as you're talking, I'm thinking, this problem is only getting worse, right?

12:05 We're only consuming more APIs in our code And we're only stitching together more backends of cloud systems.

12:13 Right.

12:13 Yeah.

12:14 We've been writing code for a while.

12:15 I have to like, it used to be, well, what's your database connection street?

12:18 All right, we're good.

12:18 We're done.

12:19 That's what you store, right?

12:20 How do you store that?

12:21 Well, and if you were doing something really esoteric, you would have like Twilio API key, so you could send like SMS messages and now you've got like your billing provider and your database provider and your cloud and your user, you know, your customer relationship management API and your email service.

12:38 There's an API key for everything.

12:40 And the scale of this stuff is like, really, if you do this sort of simple thing that all the tutorials show you to do for each of these services, you end up in a complete mess with basically no security on anything.

12:52 So yeah, and that's why I wanted to talk about this at this point, because we need that security.

12:57 Yeah, we definitely do.

12:59 So I want to start out a little bit like you did with your talk, although not the same.

13:04 I want to start out with sort of something that, you know, maybe it gets people's attention that might make them worry a little.

13:10 And that's this project that has been gone unmaintained and has been shut down, I think because it was a little too much on the edge of what really you should be doing.

13:21 And it's called Shhgit.

13:23 Shhgit is a CLI thing, I'm not exactly sure.

13:26 Basically, a little app you can run, a little CI that you can run, that will show you secrets in Git code, in code in Git repository.

13:34 So you can look at your own, But for a while they were running this website called like shhgit.com or something, like shhh, secret.

13:43 And it was just a live stream of just all the secrets that were being committed to public repositories just screaming by and it's going by so fast that you really can't read it.

13:54 And this is just the public.

13:56 Here's all the things being uploaded.

13:59 These are all these API keys, database connection strings, etc. that we've been talking about that are just you shouldn't be doing an, "Oh my gosh, look at this," right?

14:07 This has got to grab people's attention.

14:09 Right, and it's worth noting that this feed is not people accidentally committing their secrets to the improper, secure place in their organization where they accidentally push to a private Git repo.

14:22 This is only showing you public repos with valid API keys being committed to them.

14:29 If you know, you can imagine within organizations, there's probably 10 times as much traffic where stuff is being shared too broadly.

14:35 Oh, yeah, people at least know they shouldn't do this and they still are like, they might think it's okay in their private repos, right?

14:42 Right, exactly.

14:43 It's just easier. Yeah, yeah, yeah.

14:44 This portion of talk Python to me is brought to you by JetBrains, who encourage you to get work done with PyCharm.

14:53 PyCharm Professional is the complete IDE that supports all major Python workflows, including full stack development.

15:01 That's front-end JavaScript, Python back-end, and data support, as well as data science workflows with Jupyter.

15:07 PyCharm just works out of the box.

15:09 Some editors provide their functionality through piecemeal add-ins that you put together from a variety of sources.

15:17 PyCharm is ready to go from minute one.

15:19 And PyCharm thrives on complexity.

15:22 The biggest selling point for me personally is that PyCharm understands the code structure of my entire project, even across languages such as Python and SQL and HTML.

15:33 If you see your editor completing statements just because the word appears elsewhere in the file, but it's not actually relevant to that code block, that should make you really nervous.

15:42 I've been a happy paying customer of PyCharm for years.

15:46 Hardly a workday passes that I'm not deep inside PyCharm working on projects here at at Talk Python.

15:53 What tool is more important to your productivity than your code editor?

15:56 You deserve one that works the best.

15:59 So download your free trial of PyCharm Professional today at talkpython.fm/donewithpycharm and get work done.

16:07 That link is in your podcast player show notes.

16:10 Thank you to PyCharm from JetBrains for sponsoring the show and keeping Talk Python going strong.

16:18 You also pointed out right before we hit record that GitHub has a more constructive, official way of doing this as well.

16:26 You want to tell people about the GitHub secret alerts?

16:29 Yeah, I don't know a whole lot about this, except that it is a feed that also produces a lot of data.

16:36 But there are secret scanning alerts.

16:39 And I believe it's also only for public repositories.

16:42 There might be some enterprise stuff that I have not used.

16:45 Like you can, yeah, so as it says on the page, I guess organizations using GitHub Enterprise Cloud with a license for GitHub Advanced Security can also enable secret scanning for users on their private and internal repositories.

16:57 But yeah, this is something that if you're running an open source project or you have a corporate GitHub account, you should probably look into just to understand how to manage these alerts, how to get them and what to do if people are accidentally checking in secrets to your repository.

17:12 'Cause you may have to worry about open source PRs including other people's API keys, if they were like testing something out with your tool.

17:20 Right. That's more likely even as you might have a placeholder, enter API key here, don't commit it and someone commits it in a PR, right? Something like that.

17:28 Yeah. Yeah. So don't do that. Don't, don't put a place to paste something in a file that's actually checked into Git. But I think that it's also important not to shame people too much for doing this. Like one of the points of, of showcasing these tools is to say like, hey, People are leaking secrets constantly.

17:45 You should be aware of it. It's a serious problem.

17:47 The other is, people are doing this constantly.

17:49 It's a really easy kind of mistake to make.

17:52 If you do it, or if some junior engineer on your team pushes some secrets to GitHub, don't shame them.

17:57 It's not a dumb thing to do.

17:59 It's incredibly easy to screw up in this way, and we should help each other build better processes.

18:04 So don't feel like it's a thing to mock or laugh at.

18:09 So you're not suggesting that GitHub adopts a new kind of badge, like a secret teller badge or something if you're caught doing this?

18:16 I think let's not gamify that in either direction.

18:19 [laughter]

18:21 It's a hard-enough conversation already.

18:23 It is. Well, and it can happen even if you know you shouldn't.

18:25 Maybe you understand the security, but you don't, you're not good with Git, and you accidentally overcommit stuff.

18:32 And you're like, "Oh, whoops." Yep, that's a very common way that it can happen.

18:36 And even if you are very familiar with Git and you know not to do this and all of the projects that you've set up are set up properly, you might find yourself in an unfamiliar repository assuming that something is Git-ignored and it's not.

18:49 You know, there's lots of different ways that it can happen.

18:50 Yeah, yeah.

18:52 So I guess if you're running an open source project, it's probably worth turning on or at least looking into the secret scanning that GitHub has, if it's on GitHub, right?

19:00 Yeah.

19:01 And if you want to startle yourself, just check out the link, the animated GIF in the Shhgit repository.

19:06 All right, so as we start our conversation about the different secrets, the pitfalls and how we might keep them, you told, this was a really creative presentation at PyCon and you presented it through by way of, mostly by way of storytelling.

19:23 >> Well, thank you for saying so.

19:25 >> Yes, of course. Was it Gerald who was your...

19:27 >> Jethro.

19:28 >> Jethro was the protagonist.

19:30 Yes, got it.

19:31 >> So there's this practice in security engineering, which I'm sure a lot of your listeners would have heard of, which is called threat modeling.

19:38 And threat modeling can be a bit dry 'cause it's really just repeating kind of these same scenarios over and over and over again with slight things changed.

19:46 And so I thought a good way to frame that would be like a time loop story where our protagonist is kind of running this service and every time through the time loop, his service gets pwned and taken down via some kind of compromise of secrets and he wakes up and has to do it all again and try to secure things properly.

20:05 >> Yes, indeed.

20:06 >> Yeah, that's where we get started.

20:08 >> Yeah, for sure.

20:09 >> Yeah, and one of the things I also called out is, I should mention this here too, it can be a little bit stressful listening to all these different things.

20:16 This isn't exactly like a content warning, like a really serious, heavy stuff, but be aware that even if it sounds light and fun and informative, if you find yourself ideating on these same ideas of, "Oh no, all of this could go wrong, this could go wrong, or this could go wrong." That is kind of just what security engineering is like.

20:33 But also it can kind of drive you crazy.

20:35 So don't let yourself get trapped in cycles of anxiety.

20:39 Just be aware that you kind of have to do your best and make a reasonable effort, but you're never going to get everything perfect.

20:46 And in fact, I'll spoil the story a little bit since we're not quite going through it in order here.

20:51 That's really the twist at the end of the talk is that Jethro needs to just put forward a good effort across the board for managing his secrets and not absolutely perfectly defend against every attack, but also not to defend against each attack piecemeal, kind of onesie-twosie, just like, "Oh, I'll address this thing, and then I'll address that thing, and then I'll address that thing." It's like, think about your whole process.

21:14 So, yeah, so I guess we should dive into what those actual specific attacks are.

21:19 Before we do that, one thing that I thought was really nice that you pointed out is, at least for me, when I feel like I'm putting a website up there, I feel like, oh my goodness, have I, what have I forgotten?

21:31 Right?

21:32 But there's, you point out that there's a lot of people on your side, right?

21:36 There's operating system vendors, the open source maintainers, you know, what I riff on that a bit.

21:42 This is also important to remember because, so for example, just to like, one attack that's been in the news a lot lately is typo squatting and software supply chain attacks, right?

21:54 Like somebody uploading something malicious to PyPI, somebody uploading, you know, pad NAS instead of pandas and you tie, you know, fat finger the name in pip and then, oh no, you're like running code from some attacker.

22:06 And that is a threat and you, you know, you should be concerned about it.

22:09 You should mitigate it in your code.

22:11 All of the different ways to do that are like a little bit out of scope for this discussion.

22:15 But also it's important to remember that a lot of these attacks are things that it's hard to demonstrate in like a quick, like circa 2007 type sniffing your Facebook password off the wire, like, Hey, look at this, like immediate attack where I've got all of your stuff. And they're difficult to demonstrate, because PyPI is actively scanning for these types of packages, they're actively responding to reports, there are lots of people, there are lots of security researchers developing tools, some of them, kind of over aggressively running them against the index to take them up a little too much too many resources. But there are lots of people doing things to defend you against each one of these attacks.

22:56 And so the simplistic version of them will rarely work out of the box.

23:00 The threat from typo squatting is a race condition.

23:04 It's that somebody uploads a malicious package that doesn't look malicious enough to get automatically caught in these various ways, that doesn't get immediately flagged, it's not popular enough to like be installed on a lot of people's machines, and that you happen to do the typo in the window where it's still up before the admins have taken it down.

23:24 That is a real threat, but it is not as serious as, "Oh, it's just a free-for-all.

23:33 Anybody can upload anything anywhere." There's a lot of security.

23:36 Not just the PyPI admins, but the distributors of all of the libraries on PyPI that you use are developing better processes on the teams that do uploading.

23:46 PyPI now has orgs, and so projects are starting to gather into organizations to apply more consistent security rules for uploading across the board.

23:51 So there's lots of work that's going on.

23:56 I happen to know a lot about PyPI, but your operating system vendor also is like, yeah, you could run some malware and that would really ruin your day.

24:04 But Apple, Microsoft, Google, Red Hat, none of them want their operating system to be implicated in the attacks so they're constantly hardening their applications, hardening their APIs, developing secure APIs that developers can use to prevent certain attacks.

24:18 different platforms are kind of at different stages of maturity there and have kind of different security features, but they're all trying their best to prevent the worst case from happening. And so you're not like alone in this fight, you need to model your own threats and use the tools that you've been provided in ways that are kind of helpful, but you don't have to do everything yourself, you don't have to worry that you're kind of besieged with and you're the only defender.

24:40 You're actually in a pretty big crowd of defenders, and we all got to share knowledge with each other to try to help each other out.

24:47 - That's interesting.

24:48 You know, we are, you know, there's a big concern about supply chain attacks and, you know, open source building blocks.

24:55 But it is a bit of a herd immunity type of thing, right?

24:59 - Yeah.

25:00 - If something comes in pretty soon, if it at all starts to gain any popularity, people are gonna notice and it'll get beat down.

25:07 So it's scary, but it's maybe not as likely to broadly affect the ecosystem.

25:14 - Right.

25:14 that doesn't mean that you can give up on this work or put it off as some kind of gold plating that you're going to do later.

25:25 But it does mean that you can kind of moderate the amount of energy that you put in.

25:29 And the way that you should think about it as an individual, as an app developer, is you should be trying to figure out what your responsibility is and handle your part of the responsibility.

25:38 Don't try to think about every threat and become a vulnerability researcher in order to secure your application.

25:43 Like let those people, there's a lot of people doing that stuff, let them do their job and just kind of figure out, okay, what do you need to do?

25:49 'Cause obviously, no matter how great the defenses are, if you don't use them, if you're not properly secure in your own processes, then it doesn't matter.

25:57 Like you can easily, if you're pushing your root cloud keys to GitHub in a public repo, all of the security of the world's not gonna help you.

26:06 - Yeah, it's not gonna be great.

26:07 You said there's even a pep to help solve this, pep 541? What is pep 541?

26:12 541 is actually a little bit broader than just like typo squatting. It's about how PyPI like retains names, how they deal with trademark dispute resolution, you know, it outlines some of the responsibilities of package maintainers. So for example, like one of the typo squatting or one of the attacks against supply chains is if you use a vanity domain name for your PyPI account, and then you let the domain name lapse and then somebody like registers the domain name.

26:41 Now they have access to your account cause they can do a password reset.

26:43 And so there are various responsibilities that you have, like you have to be reachable. If your project has been abandoned, the index might take it away, right? Like they might shut it down, they might freeze it.

26:55 And there are this pep kind of lays out a bunch of processes for various things.

27:00 And one of them is, you know, how things get taken down, how projects become invalid, what a typosquat is.

27:08 And so it's an even broader project than just the security of typosquatting, or even broader than supply chain security.

27:15 It's like the whole supply chain shebang.

27:18 And there will probably be more peps in this area in the future, I think.

27:22 - Yeah, I would imagine.

27:23 Yeah, so for example, if I had Michael.com and I registered, my account was Michael, or me@Michael.com, and then I didn't, that went away, someone else could buy michael.com for who knows how much and then do a password reset and they control all of my super important open source projects on there.

27:43 - Yeah, and then they can immediately do uploads, which is kind of a problem.

27:46 - Right, that might not be awesome.

27:49 Okay, so that's pep541, got it.

27:52 So it was all about threat modeling, right?

27:53 And you basically come through and you say, okay, well, first we're gonna write some code and then let's just push it to the cloud and to the cloud it says.

28:02 Yeah. Uh-oh.

28:04 You can't run your website, right?

28:06 So the first thing you got to talk about when you talk about secrets is human-generated secrets. The ones, like your passwords, that you actually have to remember and type in with your fingers. Don't ever share those. If you're sharing passwords between accounts, if you've got like a LinkedIn account that has been around for a decade, that's probably been in a breach. Even if it hasn't been in a breach, oh, For those who are not on the live stream, Michael is now typing, "Have I been pwned?" Which is a great tool that you can use to see if your passwords have been in a previous breach.

28:41 And spoiler alert, yes, they have.

28:43 So the first lesson is like, you should be using a password manager, because that's the kind of absolute root of your security.

28:51 You have your kind of vault password for your password manager.

28:56 You need to be able to remember that you need to generate that securely.

29:00 And then you should let your password manager actually generate all of the passwords for all of the different sites and apps that you use, because you don't want to be sharing those between them.

29:09 Because inevitably, if you share a password between 10 sites, one of them will get breached, like for sure.

29:17 And then all of the others can be breached later by anybody who can, you know, buy that data dump on the dark web or now access that information.

29:26 So I actually wrote like one of the tools that I released during this talk at PyCon is called the pin pal, which is kind of to help people adopt a password manager. One of the challenging things about adopting a password manager, especially if you haven't got one already, is you really need to generate a like a long secure password. And you have to memorize it. And you really can't forget that because this then and this is something that happened to Jethro, you have to think about not just confidentiality, but there's this thing called the CIA triad where you've got confidentiality, integrity and availability of your service. And if you get hacked and people steal your secrets, then they can access your cloud and it's game over. But if you forget all of your passwords, and you can't access your cloud, it's just as equally game over. So you have to like, do that memorization, you should ideally also change your your root password once every couple of years, you shouldn't change it too frequently, like policies policies that make you rotate every 90 days or whatever are just a relic of a bygone time and not a very good idea.

30:33 But you shouldn't keep it forever.

30:34 And that process can be difficult because you need to memorize it.

30:39 And because password managers try to be convenient, they're not prompting you for it all the time.

30:43 So Pinpal is this thing that sets up a spaced repetition process where it's gradually generating the password over time.

30:48 It just kind of prompts you over and over for like, here's the first word, it generates it, it asks you to kind of read it back to it.

30:59 It's a little console tool that you put in your prompt to see if it's time to do a memorization pass.

31:03 But you can use Pinpal, memorize the password before you get the password manager.

31:08 Make sure you've got it thoroughly memorized, and then you don't have to worry so much about like, oh, where was that little piece of paper that I put in my wallet that has the password in it because it's been a week and now I have to enter my master password again.

31:17 Pinpal can kind of get that part of the inconvenience of adopting a password manager in the first place out of the way.

31:23 And so I've made it as easy as I possibly can for you.

31:26 I know that that's the one thing that like gets people stuck and so now you have no excuse.

31:30 You gotta get a password manager right now.

31:31 - I absolutely, totally recommend a password manager.

31:35 And I personally use one password, but I'm also a big fan of Bitwarden.

31:39 You know, props to the open source side of Bitwarden, that's pretty cool.

31:42 And the pricing for the pro version is like, you know, a couple dollars a year or something ridiculously small.

31:47 So it's, they're good alternate, or good options.

31:50 Yeah, Dashlane is also pretty good.

31:52 Full disclosure, that was actually started by my cousin in France, oddly enough.

31:56 Okay.

31:56 Yeah, it's a little weird aside there.

31:59 I don't believe he works there anymore.

32:01 So those options are all good.

32:02 I would avoid LastPass.

32:05 If you've been using LastPass, that's fine.

32:07 It's still way better that like, again, it can be easy to catastrophize security.

32:13 Like LastPass had a bunch of breaches and the breaches were like worse than they said.

32:17 And their security, like they used a lower iterations on their key derivation function than they should have.

32:23 And so there's all these issues with LastPass.

32:25 But like, if you had been using LastPass, when they got breached, you're still in way better shape than if you had been trying to like memorize.

32:34 Just reusing your passwords. Yeah.

32:37 Yeah, one of the big, I think, big no-nos of LastPass, other than also the low iteration, the folding account, was that a lot of stuff is stored in plain text.

32:49 So like the URL of the place for which the password goes to is stored in plain text so that the hackers could go through the dump and go, "Okay, well, just show me all the Bank of America ones.

33:00 Let's just work on that for a while." Right?

33:02 Yeah, it was...

33:03 They definitely had an architecture that was like bad for no reason. Like there's no reason that they should those that stuff.

33:09 Oh, I totally agree. So yeah, I people would choose the last pass if they want, but there's a bit word and one password. Those that's where my, my heart lives.

33:17 in.

33:19 This portion of Talk Python to Me is sponsored by the Compiler podcast from Red Hat.

33:23 Just like you, I'm a big fan of podcasts, and I'm happy to share a new one from a highly respected open source company, Compiler, an original podcast from Red Hat.

33:32 Do you want to stay on top of tech without dedicating tons of time to it?

33:36 Compiler presents perspectives, topics, and insights from the tech industry free from jargon and judgment.

33:42 They want to discover where technology is headed beyond the headlines and create a place for new IT professionals to learn, grow, and thrive.

33:49 Compiler helps people break through the barriers and challenges turning code into community at all levels of the enterprise.

33:55 One recent and interesting episode is there, the Great Stack Debate.

33:59 I love love love talking to people about how they architect their code, the tradeoffs and conventions they chose, and the costs, challenges, and smiles that result.

34:08 This Great Stack Debate episode is like that.

34:11 Check it out and see if software is more like an onion, or more like lasagna, or maybe even more complicated than that.

34:17 It's the first episode in Compiler's series on software stacks.

34:21 Learn more about Compiler at talkpython.fm/compiler.

34:25 The link is in your podcast player show notes.

34:27 And yes, you could just go search for Compiler and subscribe to it, but follow that link and click on your player's icon to add it, that way they know you came from us.

34:37 Our thanks to the compiler podcast for keeping this podcast going strong.

34:43 I did have one of have I been pwned up?

34:45 And I would just like to point out the question is, have I possibly right?

34:49 I can tell you the very has a list of most recent breaches.

34:53 This Luxottica one here was 77 million.

34:57 I just got a notification that I was in that one.

34:58 That's like literally the most recent one.

35:01 And here's what drives me nuts about these things.

35:04 This bit of a sidebar.

35:05 So nothing you can do about it, but it's maybe about the, you give it your best shot and you can just only do so much, Cliff.

35:11 And I am in this breach because I went to my eye doctor and my health provider, they subcontracted to Luxottica to get my glasses created.

35:24 Luxottica was hacked and therefore my information, I'd never even heard of this company or interacted with them and yet here we are, right?

35:32 And so, you know, do your best, but don't go crazy.

35:35 - Yep.

35:36 - Okay.

35:37 - So, okay.

35:37 - I guess you have more control over, right?

35:39 But I guess one of your very first recommendations was use a pass manager or use something like PinPal to help not forget your password to your password.

35:48 And sort of the lesson is the CIA triad.

35:50 Like availability is also important, not just the other two security bits, but if you can't get to it anymore, that's still a problem.

35:57 - Yep.

35:57 Don't be your own worst attacker.

35:59 - Exactly.

36:01 - So yeah, and I guess that one of the other major things I wanted to talk about here.

36:05 Part of this story is that the documentation, so Jethro follows the docs on a lot of different things that he's looking at.

36:13 And a lot of those docs, and this was kind of the inspiration for the talk in the first place, was that many, many APIs are documented by saying, here's some code, and here's where you paste the string of your API key.

36:27 And big companies do this.

36:28 Stripe does this, DigitalOcean does this.

36:31 it's not a unusual thing. It's not a thing that only kind of low security, uninteresting APIs do. The idea is they're writing the docs, assuming that you kind of have some secret management strategy to begin with, that you know, your API token is really sensitive. And so obviously, you won't follow their example directly. But like, as seen from the GitHub stream of, you know, constant secrets being pushed to public repos, a lot of people don't know that.

36:59 And there shouldn't be any shame in not knowing that.

37:04 If the docs say, "Put this string here," and you're like, "Okay, I'm going to put that string there," there's no way that you could have somehow known in advance if you're a novice coder, that if you put that string there like they said, then all of your money will be stolen and your attackers will boot thousands of servers to mine cryptocurrency.

37:24 So one of the things that calls to action here is, if you're maintaining those docs, if you're leading people down that path, please at least mention that this token is extremely sensitive, at least explain that people should be looking somewhere else for documentation of what to do. And like, in Python, it's actually quite easy to know what to do. It's use keyring, like exactly how you configure keyring and what you do with it, we can talk about in a minute or two. But from a perspective of like an application loading something from the example from the perspective of like a code example that you want to put on a website, just never tell users to put a string directly in the code. The string in your code is obviously never the user's like actual API key. They're going to have to edit it anyway. So in the example code, just import keyring into a keyring.getpassword. And they can replace that with their key as easily as they can replace a string. But at least you're calling out there, oh, hey, this is like a piece of data that has to be managed in a particular way. Here's how you manage it in Python, is you call the keyring get password API. So the keyring module is like very simple. It's basically just a wrapper around a function that returns a string. But by centralizing that function, all of the myriad nuances of what exactly like how exactly to get that string, how's it encrypted? Where's it stored? Whatever can be kind of pushed out of the application.

38:46 Yeah, so let's talk about keyring a little bit. It's a Python library that you can use. And you can say, basically, save a secret or get a secret?

38:56 It calls it a password.

38:57 I kind of would like it to not be password 'cause what if it's a API token for that?

39:02 You know, I don't know, it seems a little, what if it's a connection string?

39:04 I don't know.

39:05 - Yeah, it's a little bit like, it was definitely written quickly and saw just a crazy amount of adoption and, you know, we're kind of just stuck with that naming now.

39:13 I agree that it's not the best, but it's, you know, it's fine.

39:17 Any secret token that you treat this way is kind of functionally a password.

39:22 So the terminology is a little confusing, but it's fine.

39:25 - Yeah, so regardless of whether it's an API key or a password or a connection string, you can say keyring.setpassword or keyring.getpassword.

39:34 And that's pretty much the API, right?

39:36 - Yeah, and the nice thing about it is that there can be a lot of complexity in how it's configured, but the default, if you just like pip install keyring and you start using it on a desktop machine, Windows, Linux, macOS, doesn't matter, it by default will use your platform's default secret store, which is kind of the best that you can do without any additional configuration.

39:58 And ironically enough for the talk, I really wanted to talk about like how this works on every platform.

40:05 I kind of figured that every platform was like equivalently secure.

40:08 I kind of hate being a shill for a trillion dollar corporation, but like Apple does this so much better than either of the other major desktop platforms because on the Mac you've got like intra user security boundaries.

40:23 So like your, there's apps are generally sandboxed on the Mac if they come from the app store, if they've opted in, even if they're not sandboxed, there's a lot of things that they can't do. Like if you, you may have noticed if you use a Mac, if you try to like run a Python program on like a file on your desktop or in your documents folder, it'll like pop up a dialogue and say like, Hey, this program is trying to access this thing.

40:45 secrets or something like that, where when an app tries to access a secret, you have to not just say yes, but you have to like enter your account, your login password again. And you can choose to either allow it temporarily or permanently. And you can then go in and configure it to say like, Oh, this, like, I know I said that I this app could access its own secrets, but like, actually, I want to be prompted every time. So like, for example, my PyPI keys, if I use twine, or flit to upload a package to PyPI, I always get a secret.

41:15 get a password prompt because my PyPI token is not stored anywhere on my file system. The key that's stored in my Mac key ring is like locked.

41:24 It's not allowed to be automatically accessed by anything.

41:28 And that adds a little bit of friction versus something like PyPI package uploads.

41:31 You want to have that friction there.

41:34 It's not very frequently used.

41:36 Now on Windows and Linux, you still get some protection against offline attacks.

41:39 You get protection against other users.

41:40 Like if you share a computer or you're on a Windows, like, you know, a corporate laptop where things are executed under like administrative tasks or are executed by your company under different users, it'll be protected from that.

41:54 It'll be protected when you're not logged in.

41:55 And on Linux, oddly enough, you can lock your credential locker, but like only the whole thing.

42:00 And then anytime any app needs to do anything, it's like, Hey, do you want to unlock this again?

42:05 And so like your mail client will be checking your mail and it'll constantly be saying like, Hey, do you want to unlock this?

42:10 But nevertheless, it is still locked in a way that like, if you step away from your computer, if the screensaver is on, I think it will generally kind of lock it for you. So it provides as much protection as it can, given the way the platform works without any additional inconvenience. Like if you use key ring, and you just kind of use it in the default mode, you get a bunch of extra security. And it's all for free, like you don't have to think about it. It'll just work.

42:36 - I'm pretty comfortable just putting true secrets into macOS key chain, for example.

42:42 I feel like that's a pretty safe, it's probably better than a source file, a text file.

42:47 - Yes, it's definitely better than a text file.

42:49 And it's better than a text, I mean it's way better than a text file in your Git repo.

42:53 It's still much better than a text file like in your home directory.

42:57 Like a lot of, the less irresponsible code documentation tends to tell you to like put your keys into like dot this app dot CFG in your home directory or something.

43:09 And that's like kind of okay, like any software that can steal stuff out of your home directory is probably already, you know, got a lot of control of your computer.

43:20 But it's still better to put it in key ring if you can.

43:25 Right. Well, my assumption about most malware type of things is it's going to be 100% automated.

43:32 I imagine there's very few, I'm just going to remotely log into each computer and go hunting for secrets.

43:37 More like it's going to look for well-known things.

43:40 Much like if you tail the log of your website, you're going to see some things trying to access /wpadmin.php.

43:47 Even if it's not a PHP site, like that's, they just got the things they look for, and they're going to go through their processes to gather secrets and access.

43:54 And I guess the less standard, the less obvious it is to get a hold of it, probably the better.

44:00 It's easy to kind of trick yourself into thinking like, "Oh, I should just put everything in like really weird locations and like the automation won't find it." Quite often the automation like does kind of scrape through every file it can get access to because it doesn't cost them anything.

44:13 They can just like read every file.

44:14 It's your processor, it's your processing.

44:16 Maybe just runs Shhgit on every Git repo it can find on your computer.

44:20 Right.

44:21 So it's better to kind of like, put all your eggs in one basket and really watch that basket. And that's what the keyring approach is. But it also like, beyond just the protection against malware, there's also a kind of level of management that you can do it puts by using your platforms default keyring, or cryptic, you know, encrypted store, there are platform specific API's for like enumerating secrets. And so if you're trying to do an inventory of like, what secrets are on my computer, having them in there is nice, because you don't have to go hunt for them.

44:51 hunting around for them. It gives you as a defender a little bit of an advantage because you know what you're defending against, you know, Oh, hey, this secret shouldn't be on this computer. This should really be like only you know, on this one server over here. So using keyring also gets you that it also gets you this configurability because like once you actually put your code into production in the cloud, it's not going to have access to your local keyring on your Mac, it's going to be a certain deadlock of your app if it pops up, can this website access the keychain, you know, use touch ID allow, it's probably not going to work in production.

45:23 Right. So you have to use an alternate key keyring back end to on your server.

45:29 And that is a little bit awkward. And that sometimes turns people off. And they're just like, I'll just use a config file. But there are ways to configure like, and they're actually documented, like right on the keyring web page, like, you can it talks about keyrings.crypt file, which is this like extra back end that you can get that store stuff in an encrypted file.

45:47 Keyrings.alt includes like just a plain text file.

45:51 If you know that on your server, you have like a secure place to put a text file, 'cause the server's gonna need to be accessing the secret over and over again, you can just say, okay, I'm gonna configure the backend as part of this Docker container.

46:03 Like it's just gonna read this file from this volume and that's the keyring backend I'm using.

46:08 But again, that's all configuration.

46:10 You write your app to just use keyring And then after the fact, when you're setting up your deployments, you can select what the most appropriate back end is.

46:20 And in fact, one of the things I talked about during the talk was as I was trying to find like the super secure way to like disable access to secrets on Windows and Linux, and I didn't find it, I actually wrote my own keyring back end to demonstrate how you would do this that does the encryption with the keyring protocol or the sorry, the client to authenticator protocol on a UB key or a web auth key.

46:42 It's called Token Ring. You can pip install Token Ring.

46:45 And it works on Linux, it works on macOS, it works on Windows, and it requires you to be seated at your computer with your YubiKey plugged in in order to use this keyring backend.

46:58 So by configuring...

47:00 - So when your Python code hits keyring.getpassword, the next thing that has to happen before that returns, you have to touch the YubiKey.

47:07 - And this is also a good example of how this was a cool project, It was fun to play around with that API.

47:13 I had some smarter security people than me look at it to make sure I wasn't releasing something super unsafe just for a laugh.

47:19 So I think it is definitely usable.

47:22 But it's also an example of a key ring backend that you would not always want to use, right?

47:26 Like this is for your super high security secrets.

47:29 It doesn't even have support for multiple YubiKeys.

47:32 So again, you gotta think about availability, like anything you put into this, you probably wanna back up somewhere else, but it is a relatively convenient thing.

47:40 you just have to kind of touch it with your finger to unlock it.

47:43 But it's also really, really secure.

47:45 So like some of your secrets you might want to put into this backend to make sure that there's no way for software to access them automatically.

47:52 There's no way that malware running on your computer is going to be able to just like, hoover them up.

47:57 Anytime you see a prompt for a, you know, authenticator touch that you weren't expecting, that's like a real eyebrow raise moment.

48:06 And so the but but you know, token ring is just kind of my example of one of these things. There are dozens of other keyring backends that you can use for either different levels of security on your own machine, although honestly, the platform encrypted stores are generally pretty good, like for a default. But you can also use alternate backends for different cloud secret providers, like I believe HVAC, which is a hashi Corp vault, back end, I haven't actually used So I'm not totally sure how it works, but I believe it actually has a keyring back end, which is only one like tiny part of what it does, but it can turn a vault into a keyring for you, I think.

48:46 If it can't, then the adapter to do so would be very trivial to write. But that's the idea is that you write your code to use keyring and then wherever you deploy it, you can figure it to use the keyring that's appropriate to that context.

48:56 All right. Right. One of the interesting ones is the Bitwarden back end, which is kind of nice.

49:01 - Right, I was actually a little disappointed because I'm a big 1Password fan.

49:04 I don't use Bitwarden personally, and I was like, "Oh, but there's a CLI, "like they could have made one." And I'm sure somebody eventually will.

49:11 - Yeah, I think it's also worth just a quick pointing out that both 1Password and Bitwarden come with CLIs.

49:18 So that is an option, right?

49:21 And 1Password even can be an SSH daemon for some of that as well.

49:26 So those are both options for ways that your app can directly interact with your password manager.

49:32 And it doesn't have to necessarily be the one that you use, right?

49:35 For example, you and I are one password people, but maybe our app is a Bitwarden person.

49:39 Right?

49:40 It's all about separating that software authorship thing from the user experience, right?

49:47 The user should be able to select their own keyring.

49:49 And it almost sounds a little bit trivial to say, "Just use keyring and it'll all work." But it's that separation that you're trying to achieve, is that you want code that can be configured to be as secure as it needs to be and has good defaults for most people.

50:03 Okay. All right. So there's a couple more lessons in here.

50:06 If you're a doc writer, don't encourage people to put their API token straight in the source code.

50:13 And you shame a few well-known companies saying it's not just that.

50:16 But...

50:17 Yeah, so that was like the biggest lesson.

50:20 But some other things here is that...

50:22 Or sorry, another call to action here is that you really want to think about, you know, think think about that time loop that you're in, what are all of the different attacks could impact you? Write them down, think about how what you want to be secure against the talk when it's out on YouTube, kind of goes through them in, in order and can, maybe when it comes out, you can have a listen. But once you've written that down, stick to it, and make sure that your processes are such that it's really easy to do all of the defenses that you have selected that are relevant to you and to your application.

50:57 Doing threat modeling is a great way to draw a line around that anxiety about how secure are my secrets?

51:04 If it's all just vibes and you think about this one news story one day and then you write some security that defends against that one particular thing, or you do something on your laptop one day that's in a more secure way, but you don't encode that as a process or something that you do repeatedly repeatedly for each new secret, like as you said, close to the top of the show here, like we're all using a zillion API's now. So if you think of a good way to access your Stripe API key, and then next week you have to add Braintree support.

51:38 And then the week after that, you have to add, you know, open AI, right? Like as you add each one, you need to be doing things the same way, both so that you can correctly directly implement your security controls for each new thing, but also so that once you've implemented them, when you want to enhance them, when you grow to a certain size, you start getting more attacks, you start getting, you know, facing new, more difficult threats as you're a bigger target, you have to be able to upgrade and you want to be able to upgrade all of your secrets management at once as easily as you can. And there are other things outside the scope of what we're talking about today.

52:15 You also need to be able to like rotate those secrets, which is a whole other mess.

52:19 I mean, that's what tools like HashiCorp's vault can like help manage that part of the process.

52:25 But yeah, so the call to action for like doc writers and framework authors is like, don't document things the wrong way.

52:31 Don't provide bad defaults.

52:33 You use keyring if you're doing Python stuff, but the call to action for like app maintainers and people operating services is do some threat modeling, write it down and do everything the same way.

52:44 the more that it's all funneled through that choke point of keyring and of your documented security processes, the more that when you have to make it better, it will not be a giant pain of like trawling through all of your code and all of your libraries and trying to figure out where things even are.

53:01 You'll just be able to look at your, you know, the code that's accessing the secret and say like, "Oh, well, we're going to switch from like, you know, our sort of homegrown thing to some vault or to Amazon's secret store or Google Cloud equivalent or, you know, DigitalOcean has a thing.

53:17 Everybody's got their own secret storage thing.

53:19 There's a bunch of products in this area.

53:20 And when you adopt one, you want that process to be as smooth as possible.

53:24 - It's also probably a bit of a friction.

53:27 I always think about, you know, how do you encourage people to do the right thing?

53:31 In a way you discourage them as you add friction and you make it harder to do the right thing.

53:36 - Right.

53:36 - So if the right thing is to, you figure out a way to manage one of your secrets, well, make it easy to bring on another API, make it easy to, you know, basically get in there and change that and work with that system.

53:47 Yeah.

53:47 All right, let's see. We're getting short on time, but what other lessons do we have?

53:50 You know, talked a bit about where do we put some of these things.

53:53 You did also point out that there's, beyond the keyring stuff, is you do have stuff for like AWS secrets in particular.

54:03 And I suppose there's probably other ones as well, right?

54:06 Like what we talked about so far mostly is security on your computer or security on the one server that you go and run your app or the cluster of servers.

54:16 But you know, what about GitHub automation?

54:18 No, things like that, right?

54:20 There's various tools.

54:22 The two that I've talked about in my talk are there's a tool called AWS vault.

54:26 There's another one called gimme AWS creds, which make it more secure to store your AWS credentials in particular.

54:33 Cause those are pretty in the same way that like your computer is the root of of security for everything, and that's where all your secrets are ultimately stored.

54:42 Your AWS account is the root of your security for AWS, for all of your cloud resources if you're using them.

54:50 So it's good to focus more on the specific things that have a lot of power.

54:56 Those also can reduce the power, have roles that have less permission that isn't just your cloud root API key for everything.

55:03 There's also GitHub that has a secrets system which is effectively just injecting environment variables, but it stores them in a way that like keeps them out of your repo.

55:12 It puts them in a place that again, you can enumerate, you can see all of the secrets that are provisioned against your particular repository. It manages access control for like, you know, public open source, PRS can't like immediately access all those secrets cause they're running.

55:27 Like they have to be run in a way that indicates that like an admin has kind of seen that something is going to happen.

55:36 So they only run on your main branch or things like that.

55:39 It's a little difficult to talk about these, and this is one of the reasons that I focus so heavily on your local computer.

55:43 Both because it's the base of this pyramid, but also because you really have to do that research on your own.

55:47 Because you have to know what services you're using and what tools are available to manage certain secrets within them.

55:56 And keyring is so important because it's the thing that gives you the joint of flexibility to say like, oh, well, when it's running in GitHub, it's gonna be in an end var, and it's gonna be in this end var, and I'm gonna write a keyring back and it knows that.

56:08 - Interesting, yeah, keyring sounds like a really important piece of this story.

56:11 - Yeah, I mean, it is, in the Python world, it really is like the beginning of every story about improving your security is, okay, now that you're using keyring, you can, and then there's like the next thing, and there's a bunch of directions you can go in, depending on if it's your local computer, if it's the cloud, if it's a dedicated server, if it's an embedded device, there's all different ways that you could go, but it all starts with acknowledging that you're going to need that flexibility.

56:36 And honestly, you could write your own version of Keyring.

56:39 All it is is a function that looks at a config file and figures out what other function to call, but because it's the standard one, like it is a social convention, that is very powerful because you really don't want to write all of your own backends for everything.

56:52 >>Right, it's about the integration with the other systems, about integrating with the Bitwarden CLI and with macOS Keychain and doing all those things right.

57:00 - Yeah. - Right.

57:01 Yeah, and those good defaults are really important 'cause integrating with the macOS Keychain is not easy and Keyring just does it all for you.

57:08 So, one thing I also wanted to, this is kind of a minor point, but I really want to toss it in there because I feel like it's rarely covered, which is environment variables have kind of taken over in the cloud, like they're the standard way that a lot of services expect you to inject stuff.

57:22 So I can't say like, don't use envvars, like it's just, that's not feasible, but when you can avoid them, like if you can get your credentials stored some other way, like in a text file or whatever, try to stick to that because envvars are really easy to accidentally dump in a debugging session.

57:39 Like you could just type env and it'll dump out everything and a lot of like CI builds or debug log uploaders, will just like kind of dump out the environment 'cause it's useful to know And filtering secrets out of that is a whole like discipline that you have to develop.

57:54 And like a lot of tools that do debug like Sentry will have like a lot of code to do that filtering.

58:00 But it's best if you could just put the secrets where the secrets go.

58:03 So like one idiom that you could use is like, you can put a crypto key in your environment variable, which can't do anything but like decrypt the text file.

58:11 And so that key is kind of useless outside the CI context or whatever.

58:15 And so you just like indirect it so that the actual secret stored in a place that is not just going to be dumped in every debug log.

58:21 The danger may be given away too much. That's what I do. I have a one encryption key that's pretty long and a really high level of encryption of the actual secret somewhere else. And for me to add another secret, another API endpoint as well to add it to this file, and then re encrypt it, you know, it doesn't, it's sort of the same process. So it's not like, well, these API's are encrypted that way. And the database connection is encrypted that way. It's like, here's the file that's got all the info in it, and then it's highly encrypted.

58:50 - Yeah, and that's exactly what I want to encourage people to do, put all your eggs in one basket, and then watch the basket.

58:55 (laughing)

58:57 - Passwords go in the password manager, cryptos stuff goes in the file.

59:01 Please, please, please don't let it get exposed.

59:02 Okay, let's wrap up this conversation with a bit of a summary from what you take away from your talk here.

59:10 - Yeah, so I think we've hammered home, you know, you should use a password manager.

59:14 You should make sure that your master passwords for that password manager are backed up.

59:19 One thing we didn't cover today, but it's pretty big in the talk, is you should trust the autofill on your password manager 'cause a lot of phishing attacks will make a very convincing website that will trick even the most seasoned security people.

59:32 So just, if it doesn't autofill, close the window, type the URL by hand, make sure it autofills.

59:38 - Yeah, I think people often see that, well, this is just the password manager's incomplete, so it's not helping me with this website.

59:45 That should be a super big red flag if the password manager is not suggesting to autofill.

59:50 Yeah, and one of my favorite things about 1Password is that they have been getting progressively more aggressive about making it super annoying to disable that.

59:59 Like now, if you try to autofill with 1Password in the wrong app or the wrong website, it now pops up a dialog that's like, "Do you want to add this URL? Do you want to fill this once? Or was this a mistake?" It will ask you every time if you try to force it to.

01:00:15 But obviously, like copy paste kind of circumvents all those protections.

01:00:18 So like never ever use copy paste, always try to get it to autofill.

01:00:22 You should use full disk encryption, just turn on file vault or what's the Microsoft BitLocker or DM Crypt, I think is the Linux one.

01:00:31 Like you should, the technology now is like pretty much free.

01:00:34 It doesn't really cost much in the way of performance.

01:00:36 Like, and it gives you peace of mind if your laptop gets stolen, which is sadly a thing that speaking of like, you know, GitHub credentials leaking constantly, laptops are stolen every day. So you should make encrypted backups, you should make sure you have like a restore plan because availability is really important.

01:00:52 Obviously, use keyring, use keyring, use keyring and pick an appropriate back end for the level of security that you need in each place where your code is deployed.

01:01:00 Yeah, absolutely. All right. Well, Glyph thanks for thinking about all this for everyone and giving us a list. And I think people will really enjoy your storytelling when the PyCon video eventually comes out.

01:01:13 Yeah, I can't wait to start sending people over to the YouTube video.

01:01:15 I was pretty proud of how it went.

01:01:17 It's my first talk in quite a while, because I don't know if you know this, but the last few years have been a little stressful for everybody.

01:01:24 A lot of stuff going on.

01:01:27 It's going to scramble up the whole conference track, conference circuit a little bit, yes.

01:01:32 All right, before we get out of here, let's give you a chance to give a shout out to a PyPI package.

01:01:36 I mean, feel free to pick Keyring if you want one more time or something else that you think is kind of awesome people should check out.

01:01:41 That's always tough. I remember, I know that this question is coming every time I'm on this podcast.

01:01:46 I'm like, I'll see you like, or the choices are getting harder because we're up to 456,000 packages on PyPI. How nuts is that?

01:01:53 There's a lot out there. I guess I should take this as an opportunity to like, Oh, you know what, actually, I do have a self promotion thing that I should put in here that is not, we did not talk about it all today, which is date type. Date type is another little package that I wrote.

01:02:09 And it's a workaround for like one specific bug in the standard library, which is that dates are assignable to like dates and date times are considered equivalent because they are one subclass is the other.

01:02:25 And this will make it so that you can't assign a date time to a date because they don't actually like they're not compatible.

01:02:31 They're not Lispcoff substitutable.

01:02:33 And it will also give you separate types for naive and aware date times.

01:02:37 So you can't mix those up.

01:02:38 Oh, nice.

01:02:39 It is not actually a library.

01:02:42 It looks like a library, and I guess it does have one function in it.

01:02:44 But what it actually is, is a bunch of abstract protocol-like type stubs.

01:02:50 And so at runtime, they're still datetimes.

01:02:53 Everything works exactly the same. It doesn't change how your code behaves at all.

01:02:55 But by importing from datetype instead of datetime, you get this extra mypy type safety.

01:03:00 Excellent. All right, very cool.

01:03:02 That and also Rich, because that text UI stuff is amazing, but I feel like everybody talks about that one.

01:03:08 which is awesome.

01:03:09 We're doing a good job over there with that for sure.

01:03:12 All right, final question.

01:03:13 If you're gonna work on DateType or any of these other projects, what editor are you using these days?

01:03:18 - I use Emacs as I have for nigh on 30 years now.

01:03:22 - You prefer to have an operating system for your editor?

01:03:25 - I don't treat it as an OS.

01:03:27 I feel like a lot of people, you know, kind of live inside Emacs all the time and I use Emacs for a lot.

01:03:31 I think I love the text editing facilities.

01:03:34 Every time I kind of try to drop into like VS Code one of the new cool text editors.

01:03:39 I always like the IDE stuff is often nicer than Emacs, but the text editing itself, like the number of motions, the kinds of things you can do to like select a word, select a function, select a lines, you know, select a sentence, rewrap a paragraph, right?

01:03:55 There's all these things that you do as you're just working with text in Emacs that, so it's like a, it's a text editor in a way that few other IDEs are really text.

01:04:06 Yeah, I feel like Vim is a little more interchangeable.

01:04:09 Yeah.

01:04:09 A lot of the editors have Vim bindings, right?

01:04:11 I've used Vim. I actually kind of took a break from Emacs for about two years at one point and switched entirely to Vim.

01:04:17 But my Vim config has been slowly breaking over the years.

01:04:21 So I actually deleted the whole thing last year and I've been trying to get into NeoVim.

01:04:26 But there's a little bit of like, it's a different world.

01:04:28 So I haven't managed to get into it.

01:04:31 Very cool.

01:04:32 All right, well, final call to action for people who are now maybe a little bit nervous and thinking about how they should treat their secrets differently.

01:04:38 Yeah, I mean, I think that that's a good point. They might be a little nervous. Relax. It's going to be okay. That's my call to action.

01:04:45 And use keyring and don't write docs that tell people to paste stuff into their source code. But mostly just relax and take this methodically.

01:04:54 nobody's attacking you right now. And it's very easy to get worked up about security and think like, Oh, no, you know, this all of these attacks, like all this horrible stuff could happen. But really, like, today's the same as yesterday, you just need to start adding those defenses a little bit at a time.

01:05:08 Absolutely. Well, thanks again for being on the show. It's great to catch up with you. Thanks so much for having me. This was great. Yeah, you bet. Bye.

01:05:13 Bye.

01:05:13 This has been another episode of Talk Python to me. Thank you to our sponsors.

01:05:19 Be sure to check out what they're offering. It really helps support the show. The folks over at JetBrains encourage you to get work done with PyCharm. PyCharm Professional understands complex projects across multiple languages and technologies, so you can stay productive while you're writing Python code and other code like HTML or SQL.

01:05:38 Download your free trial at talkpython.fm/donewithpycharm.

01:05:43 Listen to an episode of Compiler, an original podcast from Red Hat. Compiler unravels industry topics, trends, and things you've always wanted to know about tech through interviews with the people who know it best. Subscribe today by following talkpython.fm/compiler. Want to level up your Python? We have one of the largest catalogs of Python video courses over at Talk Python.

01:06:05 Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription in sight. Check it out for yourself at training.talkpython.fm.

01:06:16 Be sure to subscribe to the show, open your favorite podcast app, and search for Python.

01:06:21 We should be right at the top. You can also find the iTunes feed at /iTunes, the Google Play feed at /play, and the Direct RSS feed at /rss on talkpython.fm.

01:06:31 We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.

01:06:43 This is your host Michael Kennedy.

01:06:44 Thanks so much for listening.

01:06:46 I really appreciate it.

01:06:47 Now, get out there and write some Python code.

01:06:49 [MUSIC]