Runtime Arguments

0: Passkeys

• Jim McQuillan & Wolf

Share episode

There are many scams, some to get your password(s), some just for money.  Join us as Wolf tells everything he knows and together we discuss a new way to protect your online accounts.

Show notes:

Lists of login methods:

Who implements Passkeys?

The three things that come together to make passkeys:

Which password managers support passkeys?

  • 1Password (our personal favorite)
  • Bitwarden
  • Dashlane
  • Google Password Manager
  • Keeper
  • NordPass
  • RoboForm

A little about password managers:

Almost any password manager is better than no password manager at all so do your research. Find the best one for you. Make sure it answers these questions:

Wolf's top three personal digital security recommendations

  • Use a password manager (it should support passkeys).  See above.
    • Once you create a passkey for a specific service; change your previous password. The new one should be generated by your password manager and you should never use it unless you absolutely must.
  • Make sure your device is secure
    • Use biometric authentication
    • Have a strong password.  Your password manager can generate one made from words.  Easy to remember; hard to guess.
    • Make sure you know how to force your device to require a password.  You can be tricked or forced to authenticate biometrically.  Law enforcement can't force you to reveal a password; and if you're careful, you can't be tricked out of it.
  • Be aware of your surroundings.  Bad actors can "shoulder surf" and get your password, or cameras. It's just like the old days at the ATM.  You don't want a person right behind you to see your PIN.

Hosts:

Jim McQuillan can be reached at jam@RuntimeArguments.fm
Wolf can be reached at wolf@RuntimeArguments.fm

Follow us on Mastodon: @RuntimeArguments@hachyderm.io

Theme music:

Dawn by nuer self, from the album Digital Sky

Jim:

Welcome to Runtime Arguments. This is a new podcast that my friend Wolf and I are gonna put on. This is our first episode. We're calling it episode zero. Because we may or may not share it with the outside world. We will share it with our friends at least to get some feedback. See if uh see if they think what we're doing is worth doing. My name is uh Jim McQuillen, and my partner in this uh endeavor is Wolf. Say hello, Wolf.

Wolf:

Hello.

Jim:

That's Wolf. Um we uh Wolf and I, we the the way this podcast came about, Wolf and I meet for lunch every Saturday at a at a sushi place uh just south of Ann Arbor. Um every Saturday we sit down and we talk about everything. And one Saturday, a couple of months ago, we started talking about, you know, this is interesting stuff we talk about. Wouldn't it make for a great podcast? So here we are. We're gonna try to take uh some of the conversations we have at our lunch and uh put it into a podcast. That's not to say we're sitting at lunch making this podcast. Uh we're this is actually uh we're doing this on a Saturday and it's after we had lunch and we've each gone back to our respective homes. Anyway, we're putting on this podcast. Um we call it runtime arguments, and the reason for that name is often Wolf and I disagree about things. We uh we were just talking about it. We we agree more than we disagree, but we have different ways of looking at things. And uh that's that's what makes for an interesting conversation. He'll come at a problem one way, I'll come at it another way, and we'll we'll sometimes meet in the middle, sometimes uh uh each continue protect in our own separate ways. But uh it always makes for an interesting conversation. Uh so today uh we've got a great, great conversation lined up. Uh Wolf, why don't you tell us what we're talking about today?

Wolf:

Uh well, one of the big problems uh on the web today is authentication. And what I mean by that is when you log in uh typically to a website, but often there's an app you can use instead on your phone or or what have you that logs into the same service that you would be if you were contacting the website. And the problem is how do you prove you're you? Uh we have a great many methods right now. Uh a username and password. There can be a one-time password where you type in a code that your phone generates for you. It can send you an email with a link you have to follow. Um it can text you a number and you have to type in the number. There's lots of ways. And there's lots of scams for people who are trying to steal those ways so they can impersonate you to get control of your bank account or or who knows what. The idea is there's important services you want to access, you want to be the only one to access them, and you have to go through some procedure to prove you're you. Recently, there's been a new way of authenticating. Um, this new way is called pass keys. It's not everywhere, um, it's it's a very new technology, um, and it's very interesting, and that's what we plan to discuss today. Where did it come from? How does it work? What is it made of? Why is it good? Why is it bad? Um, and will you encounter it? And should you use it? I think those are all questions. Uh the way we're gonna do this is I've been researching this situation for a couple of weeks. Um, so I have lots of answers, not all the answers, but I I know some stuff, and the idea is Jim's gonna ask me questions so that at the end he's gonna know everything I know, and so will you.

Jim:

Great. Do you want to uh tell us a little bit more about pass keys, where they came from, how how basically how they work?

Wolf:

Absolutely. Pass keys are an uh integration of three separate things. To you, to a user, a passkey just looks like a dialogue pops up when you start to connect to something and says, Hey, do you want to use your pass key? And you click one button that says yes, and that's it. It's all over, you're connected. Um so the user interface to a pass key is simple, easy, and great. Um, the three things that come together to make this possible are a very old technology called uh public-private key uh encryption. This is something that has been in use for a long time by people who are computer savvy, uh, often to use uh a program called SSH to connect to remote websites, to connect to remote services, not websites, uh, but typically uh servers and other kinds of computers like that. But it's not used much by people outside of computer professionals. Second, things that your phone or computer do, uh biometric identification, fingerprint scanners, uh facial recognition scanners, um your phone knows who you are, and modern phones know who you are in the most secure possible way. And finally, um, a brand new collection of rules which in the documents that describe and define pass keys are often referred to as ceremonies for how past keys should be created, how they should be presented, how a user interacts with them. Uh so it's the combination of these three things uh key pair, umser interface, and biometric identification. Those three things go together to make up this idea of pass keys. Now the first thing you probably want to know is are pass keys better than what I'm using now? Um and the most important thing I can say is yes, absolutely. Pass keys are better than what you're using now. They typically don't require two-factor authentication, also known as 2FA. Um they're incredibly hard to steal, they're very safe where they're stored in your phone. The secret password is only on your phone, it's never presented to you so that you can type it into some attacker's dialogue. It's never given away, it never leaves your machine. Um Passkeys, I think, I'm safe in saying, are the future. Um they're significantly better in all ways than every authentication scheme we have right now. So that's my introduction to pass keys. Um What do you want to know, Jim?

Jim:

You spent some time in the last several weeks setting up pass keys uh for the various services that you use. Do you want to tell us about one of those adventures?

Wolf:

Absolutely. Um the first thing to know is that a passkey only ever communicates, authenticates, targets one service. So for instance, you might have a passkey that logs you into Microsoft. I'm gonna talk about some other things having to do with how you store your side, but in the simplest case, where it's you and a phone and Microsoft, there's only one copy of the complete pass key on your side in your phone. Microsoft only has half. They have the public half, which is not secret at all. Anybody could have it. It happens that only Microsoft has it, because Microsoft is the only company you use this specific pass key to talk to. Now there's a safer way to do this, and that is if your phone is actually part of some kind of cloud account. Um, for instance, uh Android phones have Google, iPhones have iCloud. Um, it may be that your passwords are stored someplace safe inside your phone, and then using end-to-end encryption so that no one can ever see them is uh transmitted to the cloud where it can be shared with the other devices that know you are you by uh facial recognition or fingerprint ID or whatever it might be. So that's the second level. Um using the cloud as provided by your device. And the third level, um, if you are concerned about being locked into one ecosystem, for instance, is at the very top level using a password manager. Um I happen to use iPad OnePassword, and one password knows about pass keys and has uh a cloud component where you can be running one password on any of your devices, whether it's your Windows machine or your Mac or your Linux box or your iPhone or your Android, whatever it might be. You're logged into the same OnePassword account. The OnePassword people can't look into your OnePassword account, they can't ever see your pass key. But no matter what which machine you're on, you have that one pass key. Um, so that's how it works for me. In the one device case, uh, but you at so no cloud and no password manager, but you actually have a desktop and a phone. When you talk to Microsoft, you'll have a separate pass key on the desktop. Um it has the same target, the same service in mind. It's thinking of Microsoft, and it won't ever offer uh a passkey authentication, this particular pass key, to any service other than Microsoft as you know them. But it's a totally different passkey for two different devices, but it's the same U and it's the same Microsoft. Um so this is how my adventure began. Uh first I started looking into what do I need to do to make a pass key, and is it the right thing for me? Is it better? Um the thing that I've mostly been using uh up until now has been um my username and then um a one-time password as presented from one one password. It it keeps what it calls a TOTP, time-based one-time password. Um, and it can present that to the uh typically website that you're trying to log into and identify you as as you. Um that turns out to be a pretty good way. It can be fished from you. Somebody can make a uh web page that looks to you exactly like the Microsoft web page, and you put in your user ID and your password, and then the second factor is your TOTP, and they catch it, and they relay that onto the real Microsoft. They've tricked you, they knew they know your TOTP that's good for another minute or 30 seconds, something like that, but they log in as you, and then they can do whatever they want to your Microsoft resources. So I don't like that. Another specific thing that I hate and am forced to do by some services is they have a second factor, and that second factor is SMS. The problem with SMS, when I say SMS, what I mean is you log in with your password, and then they immediately text you a secret code that's good for 15 minutes or something like that. And when you receive that secret code at the phone number they already have on file for you, you enter that secret code into a text box on the web page. Um there's uh two ways this can be spoofed. One, the way I just talked about, like you would do with a TOTP, but the other is there's a thing called uh sim swapping. And if you are important enough, if maybe you've got some giant crypto wallet, or you're a politician, or somebody important, um, it may be worth an attacker going to the phone store or calling the phone service, pretending to be you, and with a lot of effort getting them to duplicate your SIM for them so their phone now gets your calls. Um so what happens is they already know your password because they've somehow gotten that from you, they've scammed it, phished it, whatever. They use the password, but now they've got your phone and they get your text messages, they can use the SMS uh service to enter the second factor. And boom, they're in control of the resources at the other end of that authentication. You know, your Microsoft Azure account or whatever thing you're trying to use, your bank. Um I hate SMS because it's not encrypted end-to-end, and sim swapping is incredibly easy. All you have to do is fool a low-paid customer service employee at the phone company, Verizon or ATT or whatever. They get some training, but they are not uh sufficiently um incredulous about people trying to get replacement sims or new sims or whatever. They just don't know who the attackers are, so it's pretty easy to trick them. And I learned that past keys are not subject to any of these problems and don't need second factor. I was looking to see if they were better and or easier than what I was using, and they are. So because I use one password, it has a feature called Watchtower, and Watchtower in one pat in one password tells me what services I connect to that offer passkeys where I'm not using them. And so I started going through them in order of importance um and making pass keys. Now, the innovation in pass keys is not the encryption. The uh key pair um encryption technology has been around for decades. It's not the biometric identification. Your phones have been doing that for five, ten years. Um the innovation in pass keys is the workflow, the user interface. And so what I learned as I was using passkeys, as I was creating them and storing them and putting them in the right place and naming them and using them to connect, is that they're easy. Um, when you get to a service that wants you to use a pass key, um, it presents a dialogue uh in concert with your client, whatever software is on your side of the connection. So your phone or um your web browser presents a dialogue saying, you could have a pass key here. Would you like to? And if you push the yes button, you get a pass key. You don't have to enter any information, you don't have to um do anything, it just generates a pass key, and whatever thing the web browser or your password manager or the operating system, whatever piece of client software presented that dialogue to create a pass key, whatever did that, stores it in the most secure way possible on your device, and that's the end of it. All you had to do was click a button that said yes. And after that, um, let's say it's a week later and you want to get into Microsoft, you go there, it presents a um name and password field, and then up in the corner of your screen, either your web browser or your OS or your password manager, whatever you used to create that pass key, um that client software recognizes that you're trying to contact a service for which you have a pass key. And so it brings up a little dialogue, a little button that says, Would you like to log in with a pass key? And you click yes, and then you're in. That's all there is. Um it's easy, it's safe, and it was based on technologies I already understood and used for years. So um I switched over to it. Now it's not um it's a it's an it's a new. Combination of things to make this facility pass keys. So not every service offers it, not every password manager knows how to handle it, not every web browser knows what to do. You can't use it everywhere. But it's good, it's better than what we have. And so I'm using it every place I can. Um and that is my initial experience with it.

Jim:

That leaves me with so many questions. Um, first of all, uh uh uh I'll summarize what you said. Um briefly. Uh uh we've we've got multiple ways of logging into sites out on the internet. Uh the old traditional simple way, the username and password. We've been doing that for years and years and years. Uh the next level up would be a two-factor authentication method, like SMS or email, where you enter your username, you enter your password, and they send you a code. Usually it's a six-digit code, they'll send it to you either through an SMS text message or to your email account. Then you look at your message program and get that six-digit code, and you plug it in to the field on the screen, and that gets you logged in. That's how they figure you are who you say you are. And then the third way that Wolf just spent 10 minutes outlining was passkeys. Um I I'm gonna make a point that yes, there are levels of security here, right? Username and password is not very secure. It's easy to get around, especially when non-technical users create a password that's not very strong. They don't have a concept of what a strong password is. And you know, obviously, probably the most common password out there is password, or maybe password with an exclamation mark after it, uh, something like that. Those that's not secure at all. Um, SMS Wolf talked about how insecure that is. I want to make an argument that it's way better than the first way. Yes, it's not as secure as pass keys, but it's an order of magnitude better than a simple username and password. So don't feel bad if that's your only way of doing it. Don't feel bad if that's the way you've been doing it with a text message. I do it at lots of sites. Uh I have been switching over to pass keys, though. And I I understand that passkeys are much more secure. Um Wolf made the point that yes, if you're a politician or if you're somebody of importance, um you want the absolute most secure because somebody logging into your account and doing things as though they are you would really be a serious problem. So, yes, past keys are wonderful that way. You said that they're like I I I don't know if you actually said this, you and I said this earlier. They're like SSH keys. Because SSH is built on public private key pairs. When I use SSH, I try to always generate an SSH key pair. I keep the private key on my system, and I copy the public key to the remote system so that the next time I log in, I can just log in and it doesn't even ask me for a password because it it has my public key, I have my private key, the two of them together make a hole and it allows me in. One more point I wanted to make. We are counting on the fact that our phone knows who we are, right? So let's say you've got a phone and you've got a pass key set up on it for you to log into Microsoft Azure, right? So what if somebody else gets your phone? Don't they have that private key now? You have to have some secure way of authenticating to your phone, right? Whether it's biometrics or a secure password or something. Absolutely right. You have to count on that phone guaranteeing that you are who you say you are. Uh somebody else could grab that phone, hold it in front of your face, and they're authenticated to the phone, and they're in. And that's yeah, that's no stronger than a username and a password, right? Uh so we have to watch out for that. Uh obviously, I made the point. They are the passkeys are much more secure than than uh any other two-factor authentication method, or just a simple username and password. My concern is you've got this private key on your phone, and you're using it to log into these sites with pass keys, and you lose your phone. Now what do you do?

Wolf:

So this is a specific point I've thought about quite a bit, and it's a problem that people care about and talk about. Um at the lowest level of those three possibilities that I talked about. I talked about one device, I talked about one device and a backup cloud, and I talked about um using a password manager, a password manager that has some kind of cloud storage. So if you have one device and secure storage and no cloud, and you lose that device, and you haven't configured any other way to authenticate yourself to that service, for instance, um a one-time password or some kind of credentials uh that you can use with customer service. If you haven't done that, absolutely no one can help you. Um I mean, this might be as bad as you lose everything that was there that was connected to you, and you have to make a brand new account. Past keys are exactly like um uh any of these end-to-end encrypted cloud services where you have a special key on your phone that makes sure you can understand what's on the cloud service. Uh a thing I have experience with, not bad experience, but uh just I know about it and have used it, is if you have an iPhone and you have iCloud and you have turned on um the extra level of encryption, Apple doesn't have that key. Apple can't get into uh your backups. If you lose that phone, you have lost all your photos. Apple absolutely cannot help you get them back. So, this is a problem. One device, one pass key, no backups, you're done. It's bad. Um that is why I am using a password manager. Um, that way I've got the pass key in in a cloud uh and I can put it on a new new device.

Jim:

Ah, good point. So you're using uh, as you said, one password. You could be using Google's password manager or Microsoft's authenticator or uh Apple uh recently came out with a new password uh manager like last year for the iPhone for iOS. Those will all store your pass key private keys.

Wolf:

I know some of them do, yes. I don't know for a fact that all of them do.

Jim:

Well, I know the Apple one does, and I think the Google one does, and I think the I strongly suspect the Google one does. Yeah, if they don't, they will soon, right? Um but you need another device to store that inform to to sync, right? Um I I I'll I'll tell you a very quick story. Two years ago, I was visiting my friend Scotty up in Winnipeg, Canada. Uh we went out one night, I dropped my phone. I didn't lose it, I dropped it, cracked the screen badly, and uh immediately I was horrified. Not because it would cost me a lot of money to get the screen replaced, which it did, but I was out of town for a week, and that was my method of communicating with my life back here in the States. Uh I I I used Google for email, uh, and uh and currently I'm using a passkey for that, but I would have been in trouble trying to uh connect into my my work systems, uh into my email, into my bank, into my life. Uh the the screen was cracked, but the phone was still usable. Of course, I was worried about like slicing my finger as I slid it across, but the phone was usable, so I was safe. But had I dropped it a little harder, or had I lost it, I would have been in trouble. Uh, and I think that's about the time I switched over to one password so that I could sync all of my passwords between my laptop and my desktop and my phone so that I'm I'm not completely locked out. Um but you made another comment about having an alternate way to get in. If you lose your phone, uh you should have a backup method for authenticating. The problem is now you've got something less than pass key to authenticate with. Let's say it's SMS two-factor as your backup method. What's to stop somebody else from using your backup method to get in? You're no longer secured by that passkey.

Wolf:

Okay, I have two things to say about that. Um one is a possibly uh more secure method than anything except passkey, and the other is the idea that um, first of all, do not make up a password on your own. Um if you made it up out of your own ideas and thoughts, and maybe you specifically made up one that would be easy for you to remember, you're wrong. That password is wrong. If you want a password, and you might, you should let your password manager generate it for you. Sure. And there's many levels and many ways to get a password that's the right kind of password. Um for most of my accounts, I do have a password that I try not to use. If I come to a dialogue that says, please enter your password, well that's a problem. My concern is that window might be a trick. Maybe somebody's trying to get my password. So there's two ways people can get your password. One is by tricking you to tell them, and one is by guessing it. Um I use complicated, long, hard to remember passwords generated by my password manager, so the guessing part is out. I try never to enter them into a field, so the tricking me part is out. Why do I never enter them into a field? Because I'm using passkeys instead. So if you have a pass key, maybe now is the time to get a password manager to generate you a hard to remember password that it stores securely but manages to share it with your other devices in the cloud that you never enter until you absolutely have to. So they don't trick you, and they can't guess it. Passwords are not as good as pass keys, but if you follow those rules, um they might make a good backup. Now, just for completeness sake, I want to discuss a thing that I use, um, and that is a hardware security key. Now, this is a key, it's not unlike a pass key in that you are the one with the secret, and it's a physical object. Um people can't steal the authentication ability from you over the web. They have to have this device. I think my security key is great, but I will say a couple things about it. First of all, it's not for ordinary people. Uh a regular person who just wants to get on a website, a security key has an awful user interface. It requires you to grab your key ring or wherever you keep it, slide it into a USB port or hold it near an NFC reader, uh, touch a button. It is a huge annoyance, and you've got to have one. In fact, uh because you might lose one, you've got to have two. Do I think security keys are a good way to log in? Um if again, it depends on your threat model. If you're an important politician or an actor or somebody with a huge crypto wallet, your threat model might say you need uh hardware security key level of protection. And yet, pass keys are better than hardware security. These uh hardware security companies, they are working with and looking for ways to incorporate pass keys into their connection methodology, into their schemes. So they don't want to be irrelevant. Um, they have made a good product. I have them, I use them, I like them, but where I can use a passkey, I use a passkey.

Jim:

I think that's a great description of what pass keys are and how to use them. I I do have one more question coming from the other side of passkeys, and that is I I develop sites for my customers. I don't develop a lot of sites, but I develop some very important services for my customer. How do I incorporate passkeys into that so that they can so that the users of those sites can use a passkey to log in? Have you gone down that path to figure that out?

Wolf:

I absolutely have. And I have bad news. Implementing either side of pass keys, the client side or the server side, is a lot of work. And it's a lot of work you have to do right. It's like any other kind of cryptography. Um, if you're a developer, you know that a rule is you should not write your own encryption. You should find a well-tested, well-vetted, understood, open source, probably encryption library. Um for the parts of um pass keys, there already exist libraries in many languages. Uh not enough, and there aren't enough implementations yet. But if you're doing something in C or C or Rust, um there is something that is going to help you a great deal. But to make all of this stuff smooth for the user, there's a lot of ceremonies, as they call them, that you have to implement. A lot of conditions, uh things that don't just occur to you. Um for instance, when someone logs in uh and you don't even know who it is yet, um, you have to figure out which pass key is the right thing and if you should even ask for a pass key. Uh what if they have gone too long without touching anything, they've idled and timed out, and they are now disconnected, but they want to reconnect with their pass key. That's a different situation than just an ordinary first-time login, and you have to account for that. Um there are documents, uh passkeys are all um let me get to my web page here. Uh passkeys are under the umbrella of um some passkey implementation places. I think it's passkeys.dev. I think that's the the place where passkeys start. I have to look around. But um they provide documents, pointers to code, libraries that can help you, descriptions of all the cases and ceremonies that you have to implement. The bad news is there's a lot to do. It's super easy for the user, but it's super hard on the implementer. Uh I believe it's absolutely worth it. If you spent time in your uh app or website or what have you that you implemented putting in two-factor or whatever, and you remember that was challenging, but what a win that was for your users. This is the same thing, uh, except times ten. It's ten times as much work, um, but there are libraries for you, and the result for your user is absolutely the right thing to do. The user is more secure, it's easier for them, they're happier, you don't have to store anything secret. If you get um hacked or whatever, there's a nothing for the attacker to take from you that will let them compromise the user. Um it's all good. It's just hard.

Jim:

Alright, well, hopefully as time goes on, there will present itself an open source library, or maybe it's already there, that we can use uh to offer pass keys to our users. Uh uh I want to get to that point where I can do that. I'm not sure I have the bandwidth right now to spend all the time on that, but I I do want to offer that in the future. Um I I think everything you've covered is really interesting. What I think I'd like to leave for the listener now is a a short um best practices. Uh uh Paragraph, let's say. Can can you can you just sort of go over quickly uh if you want to have a good secure login um quickly, what do we do?

Wolf:

Alright. I have recommendations. These are what I tell all my friends. Um my in-laws don't listen, but this is what I say. The number one thing you should do is you should use a password manager. I have a favorite, but you should look and decide what is the best one for you. I happen to like one password, make sure you include that in the things you look at, but use a password manager, have it generate your passwords for things, have it remember the right things, and make sure it's available on all your devices. The second thing I would say is for the devices, especially the ones that you're going to carry around with you, make sure that that device is itself secure. On my device, it needs face ID to get into it. If I'm in a situation where I am concerned that someone might grab my phone and force me to show my face, for instance, if my phone was confiscated by border crossing patrol, whatever, uh, or stolen by someone at a bar. I don't go to bars, I'm old. But if any of those situations arose, I usually on my phone I can hold down the power button for a certain amount of time, and what happens is I can't open the phone with face ID. I have to type in the password for the phone. My password for my phone is incredibly long. Um so, and I don't type that password in in front of anyone. I think that shoulder surfing, that's a thing you need to watch out for. So, number one is password manager. Number two is make sure there's authentication on your phone. And on my particular phone, I want to add one more thing. Um, my password manager, which offers up uh the answers to these questions, it has its own separate uh test for biometric. When I try to get a password out of one password, um, I have to show my face again. Um that one time that opens the phone wasn't enough. Um and it only will allow my face for a certain span of time. I think I've got mine set for 14 days. If 14 days goes by, uh you have to re-enter your password manager's main password. Um, my password manager's password is even longer than my phone's. Um a thing I would say about passwords is some passwords you have to remember. You have to remember the password to your phone, you have to remember the password to your desktop, and you have to remember the password to your password manager. So the i the thing I think is good is something that you'll find in an old XKCD, is instead of some random collection of letters, numbers, and punctuation, um you can use a sequence of randomly selected words. Again, don't do this yourself. Ask your password manager to give it to you, to make one up. Um all password managers ought to be able to do this and do it well. Uh probably four um individual words that are un unrelated to each other uh are good enough. Um all it happens that on mine um they're all lowercase, there's no punctuation, they're separated by space, and there's lots of ways you could do this. Mine's not four words, it's seven words. But and so, well, you can tell I'm paranoid. But that's the basic idea. Um password manager, secure your device, whatever device that is, and be aware of your surroundings is the third thing. Um there if you follow the rules I've already given, you're not gonna be tricked on the web. They're not gonna guess your password. So that gets to where they observe you uh by shoulder surfing or whatever it might be in a bar. Just like we used to be concerned when we were at the ATM, is somebody right behind me looking at my four-digit code? Um, you still need to be aware of your surroundings. So that is my advice.

Jim:

Excellent. Thank you very much. Uh having a password manager is crucial. Uh so if you do lose your phone or drop your phone and break it, um, for instance, I could have gone to the Apple store and bought another phone, log into it, and install OnePassword, and type in my incredibly long password into one password to unlock all of my other passwords, then I would be back in business. So thank you. Uh I I think at this point, I think we covered our topic pretty well. Uh I want to thank everybody if if you've listened this far, I want to thank you for listening. Uh I I don't know yet what the frequency is going to be, how often we're going to do these podcasts. I think we'd like to do them every couple of weeks or so. Uh we're taking you on a journey with us as we figure this out. Uh I look forward to doing more podcasts. And uh again, thank you for for coming.

Wolf:

I uh I want to add that um our plan is for the topics we discuss that um will sort of alternate between who does the research. So hopefully in our next podcast, we find a topic where Jim learns everything and I ask the questions.

Jim:

Yes, I I I'm looking forward to that. I've got some ideas, and uh I I think it'll make for entertaining uh uh listening. So again, thank you for coming.

Wolf:

Thanks, everybody.

Contributor

Jim McQuillan

Co-host
Head Shot

Wolf

Co-host

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.

CoRecursive: Coding Stories Artwork

CoRecursive: Coding Stories

Adam Gordon Bell - Software Developer
Two's Complement Artwork

Two's Complement

Ben Rady and Matt Godbolt
Accidental Tech Podcast Artwork

Accidental Tech Podcast

Marco Arment, Casey Liss, John Siracusa
Python Bytes Artwork

Python Bytes

Michael Kennedy and Brian Okken
Talk Python To Me Artwork

Talk Python To Me

Michael Kennedy