Security Now 1008 Transcript

Please be advised this transcript is AI-generated and may not be word for word. Time codes refer to the approximate times in the ad-supported version of the show

0:00:00 - Leo Laporte
It's time for security. Now Steve Gibson is here. We have one of Steve's favorite propeller head episodes. There's, of course, some security news. He answers some of your questions and then he's going to go into. He's actually going to answer a listener question from Max who says yeah, I look at my 2FA, my authenticator app, and there always seems to be like non-random repetitions of numbers in there. Are these numbers really random? It's an interesting question, but it prompted Steve to go into a deep dive on how these one-time time-based passwords are generated and you won't believe what a kludge it is. It's mind-bending. Stay tuned. Security Now is coming up. Next, podcasts you love from people you trust this is twit.

This is security now with steve gibson, episode 1008, recorded Tuesday, January 14th 2025. H-o-t-p and T-O-T-P it's time for security now, the show where we cover your security, your privacy online. We cover all of the stuff that you want to know about with computing, because this guy right here is the king of computing, Mr Steve Gibson, GRCcom. Hi Steve. Hello, my friend, I was getting the fire report from you and you're safe and sound. Yes, I'm safe.

0:01:35 - Steve Gibson
A number of our listeners wrote to say hey, you know, all I know about you is that you're somewhere in California. Are your feet toasty? California, are your feet toasty? And the good news is we're about an hour and a half south of the well, I don't want to call it the action or excitement or anything. I mean it's devastation.

0:01:56 - Leo Laporte
It's so horrible yeah.

0:01:58 - Steve Gibson
And Leo, the cost. That's what's astonishing to me. I mean, mean, we've noted that anything that is done these days is expensive, so I mean the, the, the cost throughout the entire system of of rebuilding this much area is just, yeah, you know, astonishing well, and there's of course the question of whether it even should be rebuilt, given the hazards. Why do people keep building in florida, where an earthquake, where hurricane just keeps wiping, you know coming through and wiping the, the real human.

0:02:36 - Leo Laporte
We don't give up easy. It's nuts, uh. So what's coming up today on security?

0:02:40 - Steve Gibson
okay, so, uh, I'm. I was tempted, after I learned the word where is it apophenia? To give the podcast that title. But even I can't remember that word so I thought no that's not good. Instead, I'm titling. Today's second podcast of the year 1008, for January 14th, is titled HOTP and TOTP.

0:03:10 - Leo Laporte
Well, that's much clearer than apophenia.

0:03:12 - Steve Gibson
Yeah, why apophenia.

0:03:14 - Leo Laporte
What's apophenia when it's at home? Did we talk about that?

0:03:18 - Steve Gibson
last week. No, it's the tendency to see patterns in random noise where none exist. That's a good term. And so today's topic derives from, actually, two pieces of email that I received from our listeners two weeks apart, suspicious of the digits that his authenticator was generating. And I realized that through all 1,007 previous episodes, although we've talked about time-based one-time passwords and, in the case of HOTP, hmac-based one-time passwords, we've never looked HOTP and TOTP.

Well, it's going to give our listeners a workout because it turns out I had a lot to say. In fact, the show notes, as I mentioned to you before, are now at version 1.2. This is the second time I've had to put a version number on the show notes because I just, even though I sent them off to everybody in version 1.0 last, I guess early evening on Monday, I just couldn't stop messing with them. So then I went back to work and I fixed them more and fleshed them more things out, and then at the end of the evening I updated. I didn't send another email, but I updated the online versions to 1.1. And then, as I was laying in bed last night thinking, you know, I really didn't explain exactly why you wouldn't have an even distribution of outcomes.

I just said pretty, you know really pretty good, but I didn't explain why it wouldn't be perfect, not no, so there went this morning, uh, up until well, yeah, pretty much all morning, and one where whereupon 1.2 was updated on the website.

0:05:38 - Leo Laporte
So I do understand the epiphenia, because I often feel like, oh, that's, that number is not random.

0:05:45 - Steve Gibson
You know that's too obvious, right, but it but that's the nature of random and I'll tell you, leo, when I see times on the clock like 256 and 512 and 1024, I think, wait a minute. Hey, that's a, that's a power of two. That's one of my, that's one of my special numbers, you're funny. And frequently we'll look at the clock and they'll say it'll be 11-11.

0:06:10 - Leo Laporte
11-11. I know what are the chances that happens to you too, because I see 11-11 all the time.

0:06:16 - Steve Gibson
Yeah, See, I think we're actually. There's many more of those than we suspect.

0:06:20 - Leo Laporte
Oh, maybe that's it. That's the only explanation right it couldn't be apophenia could be because yeah anyway, so but that's.

0:06:31 - Steve Gibson
That's gonna be again I. If anyone's mowing the lawn, I would say pull off to the side of the garden.

0:06:38 - Leo Laporte
When we get to this, uh, do not operate heavy machinery. Is that what you're saying?

0:06:43 - Steve Gibson
and if you do have a self-driving car that you trust, well then maybe it's safe to continue listening. Okay, but we're going to first talk about meta, briefly winding down third-party content filtering as our segue into Matthew Green, the cryptographer's comment about that, whether encryption is soon to follow. Whether encryption is soon to follow taking over abandoned command and control server domains, now strictly for research purposes only. We also have IoT devices getting the cyber trust mark and wonder whether anyone will notice or care. Syncthing received a blessedly infrequent update, which we'll touch on, and government email is still not using encryption Really. Also, email relaying prevents point-to-point, end-to-end encryption and authentication. That we're going to look at. And just because let's Encrypt doesn't support email doesn't mean it's impossible. Also, we're going to examine what sci-fi chat gpt thinks that I steve should start reading next. And I have a new author.

0:07:58 - Leo Laporte
As a consequence.

0:07:59 - Steve Gibson
Oh my, gosh, it worked also to auto update or not to auto update? And is that one question or two? And until today, as I said, somehow through a thousand and seven episodes before this, we've never actually looked at the technology that produces the. Remember the football? That was like our first introduction to a time varying code, uh, those time varying six digit time tokens, and we're going to find out whether they're as random as they appear or maybe more random that they don't appear. Anyway, I'm not sure. We do have, uh, a great picture of the week, which which I didn't even caption it. This one is just so good it doesn't even need a caption. And then we do have the result from last week's uncaptioned come up with a caption picture contest. So, I think, certainly a gripping and interesting podcast for our listeners.

And boy, I tell you you're going to be done by the time this podcast is over.

0:09:13 - Leo Laporte
All right, well, I'm going to grab a cup of coffee. You're going to be crispy, so I get my thinking cap on. Steve Gibson is going to do it again. Kids, stay tuned. This is why we look forward to Tuesdays, because Tuesday is Steve Gibson GRC Day. Our show today, brought to you by Thinkst Canary Really glad to have them. This is their eighth year advertising.

We love this Thinkst Canary. What is it? It's a honeypot, but normally a honeypot is a complicated beast of a thing to employ, not with the Thinkst Canary. It can be deployed in minutes. It's about looks like an external USB drive plugs into the wall, into your ethernet, and suddenly you've got something on your network. Hackers can't resist.

Now you might say what do you mean? I don't have any hackers in my network, do you? How do you know? This is the problem in general with security is you've got perimeter defenses, but once somebody gets in, how do you know they're inside? On average, companies don't know they've been breached for 91 days, three months, whether it's a windows server, a ssh server, an iis server, it could be nginx, it could be Apache, mine's a NAS, a Synology NAS.

It looks, for all intents and purposes, identical. Identical to the real thing. Plus, you can use your Thinks Canary to create LUR files that look just like PDFs or doc files or Excel files, spread them around your network, give them provocative names like employee information, and then if someone is accessing those lure files or somebody is brute forcing your let's say, fake internal SSH server, you're going to get a notification from your ThinkScanary. It'll immediately tell you have a problem. No false alerts, just the alerts that matter. So choose a profile for the device, register it and, by the way, mine's a Synology NAS. It has a Mac address. That's a Synology Mac address, right, it has the DSM log and it's indistinguishable from the real thing. That's the point of the things, canary. They look like real devices, attractive devices.

Once you register it with the hosted console console, you'll get monitoring and notifications. Notifications any way you want email, text, web hooks, slack. They have an api. I mean, I go on and on once you set it up. But you just wait and if all's well it'll be quiet. But an attacker who's breached your network, or a malicious insider or any adversary will make themselves known. They can't help themselves by accessing your things to canary.

Now, how much is this going to cost? Well, it depends on how many. You need Some big operations. A big bank, for instance, might have hundreds. A small business like ours, a handful. I'll give you an example Go to canarytools slash twit.

$7,500 a year, five Thinks Canaries. That also includes your own hosted console, all the upgrades and the support and the maintenance. And if you use the code twit in the how did you hear about us box, you're going to get 10% off, and not just for your first year, but for as long as you use those Thinks Canaries. You are going to love them, I promise you. But if you're at all hesitant, you should know you can always return your Thinks Canaries Within 60 days. They have a two-month money-back guarantee for a full refund. So there's no risk at all. And I have to tell you that in the eight years Twitter has been partnering with Thinks Canary, their refund guarantee has never been claimed, because it works, it does what it says, it does and everybody.

Once you have one, you realize how do we live without this? Find out more at canarytools slash twit. Don't forget to enter twit in the offer code. Actually, I think you there's in the how did you hear about us box. Just put twit t-w-i-t. That way we get credit for it. Canarytools slash twit. This thing's brilliant, brilliantly designed to do exactly what it says, and no more, no less. All right, picture of the week time.

0:13:13 - Steve Gibson
mr g, which needs no caption okay it's just it speaks for itself.

0:13:21 - Leo Laporte
All right, I've seen it. Now Let me show everybody else.

0:13:28 - Steve Gibson
You want to describe this, steve. So we're looking at this so-called end cap that stands at the end of some sort of a store, like a hardware store or something that has aisles, and so this is at the end of one of the aisles and it's got a big sign and maybe it's seasonal, because I see like some holly leaves and berries and some wispy, like some stars and some maybe it's like signs of wind in the borders of this large sign, the borders of this large sign. So over this end cap, it says hard to find items. Where items is, you know, in the 300 point font. Really there, um, and we're looking at one, two, three, four, five, six shelves completely empty so they're hard to find all right, I can't see them anywhere.

0:14:27 - Leo Laporte
They are difficult to find, anyway, I just loved it because it just spoke for itself.

0:14:33 - Steve Gibson
Yeah, and interestingly, one of our listeners asked one of the AIs I don't know if it was chat or whom, or whom. Oh, there we go or what or what? Yeah, but to describe the picture, and it produced a complete interpretation of even what would be found humorous about this picture, about this picture, and our listeners' comment was boy, you know, for unsighted people this is going to be life-changing. Yeah, because you know it does the work of interpreting. It's not just like, oh well, there's some shelves that are empty. It's like okay.

0:15:22 - Leo Laporte
I don't get it.

0:15:25 - Steve Gibson
You know anyway it's fantastic. Now did ChatGPpt come up with a caption for last week's picture no, it didn't, um, but uh, we can now scroll to the next page where you will find the caption. Actually, I gave it now recall that we have this lone gate, just sort of sitting out in the middle of a meadow with beautiful forestation, shrubs and trees and things behind it. Nothing else is there. Anyway, a listener of ours, stephen Kangas, wrote to me. He said caption contest. He suggested Earth Abides.

0:16:02 - Leo Laporte
Oh, yeah, what a wonderful book that was. Do you ever read that?

0:16:04 - Steve Gibson
book oh, I never did. It's a classic, he said from a great book about life of a small number of survivors after a devastating worldwide pandemic and anyway. So that kind of put me on the sci-fi thread and anyway. So I gave our picture of just this lonely gate standing there with nothing around it except nature.

0:16:26 - Leo Laporte
I said some believe that long ago humans roamed this beautiful planet and that's all that's left of us, and it might just as well be for the best at least from the planet's standpoint.

0:16:42 - Steve Gibson
Okay, so it wasn't until I encountered Matthew Green's comment about Meta's announcement last week that I decided to just touch on that, like on any of that today. So, before we get to what Matthew posted, here's a brief update for those who may have been without any other source of news for the past week. Last Tuesday, a week ago, while we were recording this podcast, podcast 1007, mark Zuckerberg posted a video in coordination with a meta-news release titled More Speech and Fewer Mistakes and fewer mistakes. Part of what they wrote under the heading Ending Third-Party Fact-Checking Program. Moving to Community Notes, unquote, was, they wrote when we launched our independent fact-checking program in 2016, we were very clear that we didn't want to be the arbiters of truth.

We made what we thought was the best and most reasonable choice of the time, which was to hand that responsibility over to independent fact-checking organizations. The intention of the program was to have these independent experts give people more information about the things they see online, particularly viral hoaxes, so they were able to judge for themselves what they saw and read. That's not the way things played out, especially in the United States. Experts, like everyone else, have their own biases and perspectives. This showed up in the choices some made about what to fact-check and how. Over time, we ended up with too much content being fact-checked that people would understand to be legitimate political speech and debate. Our system then attached real consequences in the form of intrusive labels and reduced distribution. A program intended to inform too often became a tool to censor. We're now changing this approach. We will end the current third-party fact-checking program in the United States and instead begin moving to a community notes program. We've seen this approach work, and I'm so tempted to put work in quotes, but they didn't approach work on X, where they empower their community to decide when posts are potentially misleading and need more context, and people across a diverse range of perspectives decide what sort of context is helpful for other users to see. We think this could be a better way of achieving our original intention of providing people with information about what they're seeing, and one that's less prone to bias.

Now then, a bit lower down in that lengthy posting, Meta noted they said as part of these changes, we will be moving the trust and safety teams that write our content policies and review content out of California to Texas and other US locations. So that was the preamble which led Matthew Green, the well-known cryptographer at Johns Hopkins University, to, I guess, worry about what's happening, and he then sent. He said about what's happening and he then sent. He said lots of folks are commenting on the fact that Meta is cozying up to the current administration, cutting out fact-checking and other forms of moderation. This stuff is obviously worrying. But my big concern, he wrote, is what happens when the government asks them to turn off encryption? Okay, is what happens when the government asks them to turn off encryption? Okay?

Now what's interesting is that our own CISA, you know, the Cybersecurity Infrastructure Security Agency just published a five-page PDF titled Mobile Communications Best Practice Guidance, and its first number one recommendation, like you know, in the officially published five-page CISA guide is titled Use Only End-to-End Encrypted Communications. Underneath they wrote adopt a free messaging application for secure communications that guarantees end-to-end encryption, such as Signal or similar apps. Cisa recommends an end-to-end encrypted messaging app that is compatible with both iPhone and Android operating systems, allowing for text message interoperability across platforms. Such apps may also offer clients for macOS, windows and Linux, and sometimes the web. These apps typically support one-on-one text chats, group chats with up to a thousand participants and encrypted voice and video calls. Additionally, they may include features like disappearing messages and images, which can enhance privacy. When selecting an end-to-end encrypted messaging app, evaluate the extent to which the app and associated services collect and store metadata.

And there was another related piece of news about this telecom hack, which was sort of the underpinning for all this right. The reporting is that a source has told the Wall Street Journal the names of three additional American telcos that were breached by the Chinese espionage group Salt Typhoon last year. Those are Charter, consolidated Communications and Windstream, and, as we know from previous reporting, the other four now-known victims were AT&T, lumen, verizon and T-Mobile, with those first three AT&T, lumen and Verizon, you know victoriously claiming a week or two ago that they are. Now they've fully expunged the perpetrators from their networks. Now, given the count of breached firms that has been shared publicly, there are still two that remain unnamed. So two more telcos we don't yet know about.

So the clear point being made here is that no one can rely upon the security of telecommunications carriers to protect the privacy of anything that uses their bandwidth. So this begs the question, you know, whoever did believe that we could rely upon anyone else's security? After all, that's the entire point of, and reason for communicating consumers, adding our own after-the-fact, pre-internet encryption as we called it long ago to everything we care about specifically so that we don't need to trust anyone else and one of our early abbreviations TNO trust no one has been the rule of the road from the start. So this brings us to Matthew Green's worries about encryption. At this point, that's all they are is worries, and I would suggest that it's probably not worth worrying about.

No one appears to have any idea what the incoming Trump administration plans to do or will do, but I'm certain that Elon Musk, who appears to have a great deal of technical sway with President-elect Trump, certainly understands the pros and cons of any form of mandated backdoor being forced into today's exception-free end-to-end encryption as we have it now, end-to-end encryption as we have it now.

And I'm certain that our incoming president is well aware that the Chinese government appears to be behind much, if not most, of the hacking into our nation's critical infrastructure, and especially the government's infrastructure. Mr Trump feelings about China are well known, so I would be quite surprised if he wanted to in any way open any doors or back doors into our nation's encrypted communications. I would therefore be very surprised if anything were to change along the lines that Matthew fears. You know, changes in content moderation are not even in the same world as changes that would weaken our encrypted communications, and you know, I think that much should be clear to everyone. So I hope that's right. I think he's just grumbling because he's, you know, worried about content moderation. You know changing, but boy, you know, saying no to encryption. I don't think it'll happen because, again, I just think the downsides are too severe.

0:25:50 - Leo Laporte
I mean WhatsApp is using signals encryption. You feel like it's safe to use WhatsApp.

0:26:01 - Steve Gibson
Yes, actually necessary to crack encryption, because the handsets that we're all using are receiving plain text and emitting plain text, receiving voice communications and video in the clear, and so what we're creating is a bulletproof so far as the best cryptographers in the industry know a bulletproof tunnel, but at the input and output of the tunnel, everything is in the clear and is available to the underlying operating system. Right.

0:26:42 - Leo Laporte
You don't have to go to all that trouble, just get the phone.

0:26:44 - Steve Gibson
Yeah, I really think this whole thing is a little bit of a straw man, you know. It's like we're all worrying about encryption and it's like wait, you know, before it's encrypted, and after it's decrypted you can have it. So what's the big deal of not being able to get it in transit?

0:27:01 - Leo Laporte
I guess that really raises the bigger issue, which is we're all carrying in our pockets the ultimate spy device with no real means to secure it yes, and many, many astute observers have commented that our law enforcement has never had it so good.

0:27:17 - Steve Gibson
I mean because it was when we were going into the middle of a field under a comforter and whispering to each other that it was virtually impossible to know what's being said.

0:27:30 - Leo Laporte
The more we move into an electronic environment, the more opportunities there are for that to betray us Right weekly now wearing an ai wristband that has, uh, that is, recording everything that happens, every voice, everything, sending it to some unknown ai in the cloud and sending me back notes, things to do, assessments, I mean. I'm basically just you know, I don't.

0:27:59 - Steve Gibson
I'm blithely trusting this microphone leo, we love you, but we know you gave up a long time ago Exactly.

0:28:08 - Leo Laporte
All right, clear my cookies. Nah, why bother I?

0:28:12 - Steve Gibson
just I like cookies, okay, Okay. So whose command and control server is it anyway? This is an interesting story that I think everybody is sure to get a kick out of. I recall that we talked about the security research group Watchtower Labs not long ago. They're memorable not only for what they do, but because they dropped the E from the tower of Watchtower, so it's W-A-T-C-H-T-O-W-R. I don't know if that was a typo that stuck or what the deal is, but anyway, here's what they posted last Wednesday about their last escapade under the title Backdooring your Backdoors Another $20 domain, more governments.

They wrote, after the excitement of our MO CA process you know the certificate authority process for verifying domain ownership to give ourselves the ability to issue valid and trusted TLS certificates for any mobi domain. This resulted in significant internet-wide change, with Google petitioning the CAB forum to wholly sunset the use of Whois for ownership validation when issuing CA-signed TLS certificates. As always, idle hands, idle minds. It was never going to be long until our ill-advised sense of adventure struck again. I love this. Until our ill-advised sense of adventure struck again.

0:30:05 - Leo Laporte
I love this.

0:30:08 - Steve Gibson
And at this point the only thing holding us back is our publishing schedule. This time our sense of adventure struck again in the same vein of expired and abandoned infrastructure, but with a little twist. Today we're taking you through our adventures, through what we've affectionately termed mass hacking on autopilot. Imagine you want to gain access to thousands of systems but don't feel like investing the effort to identify and compromise those systems yourself or getting your hands dirty. Instead, you commandeer abandoned backdoors in regularly used backdoors to effectively steal the spoils of someone else's work, giving you the same access to a compromised system as the person who put in all the effort of identifying the mechanism to compromise and performing the compromise of said system in the first place. Zero effort, same result, all for the price of a domain. So we've been hijacking backdoors that were reliant on now abandoned infrastructure and or expired domains that themselves existed inside backdoors, and we've been watching the results flood in. This hijacking allowed us to track compromised host coasts as they reported in and theoretically gave us the power to commandeer and control these compromised hosts Over 4,000 unique and live backdoors later, a number which continues to grow. We decided this research would never be finished and it would be interesting to share the results in its current state, so we can report that, across those 4,000 unique and live backdoors, we now have access to multiple compromised governments, including those of Bangladesh, china and Nigeria, of Bangladesh, china and Nigeria. Compromised universities and higher education entities across Thailand, china, south Korea and more and much, much more. We've so far recorded over 300 megabytes of logs to trawl through. As always, we're quick to remind everyone we're not the first to track hackers for fun. We no doubt won't be the last, but we've enjoyed continuing to exploit what truly appears to be a hugely underrated vulnerability class, abandonedandoned and Expired Infrastructure to basically give ourselves theoretical free access to thousands of systems for the cost of a few $20 domain names.

Now, okay, their post goes on, and I've got a link to their post for anyone who's interested in more um, but what this amounts to is that they found that some hacker gangs had allowed the domain names used by infiltrated client malware to reach, which were used to reach their command and control servers. Those domains were allowed to expire, of course. Why would you keep them? Who knows why? Perhaps those particular hackers are now behind bars, but for whatever reason, those domains were never renewed.

This meant that the Watchtower researchers were able to re-register those previously abandoned domain names to establish their own IP for them. Then, the next time, the infiltrated malware performed a DNS lookup as the first step to re-establishing with the hackers you know, the malicious hackers mothership the IP the malware received would be the researchers. So the watchtower folks registered those domains and pointed the domain's IP address to their incoming connection monitor connection monitor. What they found was that thousands more than 4,000 and counting machines scattered around the planet that had previously been infected were still today trying to re-establish contact with their controllers. I'm sure that the Watchtower folks were only gathering data, but many of the incoming links were to remote web shells, which would allow anyone accepting such a connection to issue commands as if they were the administrators of those remote machines. Since the wayward domains were now under their control, the Watchtower folks felt free to list 31 domains they now control. I have them in the show notes. Let's see We've got, for example, six, six, three, four, five, nine, sixcom.

0:35:37 - Leo Laporte
It makes you wonder why they bothered registering a domain like that.

0:35:42 - Steve Gibson
I mean, why even bother? Well, surprisingly it was free, so nobody had that. And then we also have al jazeera 7.com, al turkscom, caspius, caspian hyphen, piratesorg they're looking for some good branding there that's right.

0:36:00 - Leo Laporte
cshiscom dcvinet dracdandynet, emperor with the second E of emperor being a numeral three emperorcom, flyphotous, gorilladnscom.

0:36:22 - Steve Gibson
Hold, with the O of hold being a numeric zero. Hold-upinfo hacks with the A being a numeral four. Hacksin hackruinfo. I don't know, I'm happy girl, I'm happy.

0:36:42 - Leo Laporte
What the HabilryG somethingcom girl.

0:36:44 - Steve Gibson
I'll be what the happy, happy, happy hillary g something dot com. Surprisingly, leo, that domain was available.

0:36:51 - Leo Laporte
It's uh you know what's interesting is, maybe they were using these also for spoofing and and other things, because you don't really need An ISP can shut down an IP.

0:37:17 - Steve Gibson
That's true. So you use DNS to redirect about systems. These were bots that were using a calendar-based formula to predict a future domain name, and that's not what we see here, but there they were just gibberish domain names, and so when the good guys got a hold of some of that malware, they would reverse engineer the algorithm, determine what the domain name would be in the future. So clever.

Beat the bad guys to registering that domain name and then wait for all the bots to come there and then shut them down. Wow, so yeah, a deep history of all this. Anyway, and the list goes on on. We've only know that iron rare, where's dot info, and that's only the first half of the list.

So, anyway, so the point is that that they're using these domains as their, as the, as the central uh, uh, you know communications point for their command and control servers, and they just let them expire. But they never told the malware like, oops, we're going to go somewhere else. If they even did, again, we don't know why they expired. They literally could be in jail. They might have been locked up when the domain expired, so unable to re-register it. That allowed the domain to go free. These Watchtower guys grabbed it. Now all of their bots are reporting into them.

So, anyway, since they have control over those domains, they said that they obtained a monster wildcard TLS cert covering all of those domain routes and began accepting HTTPS web shell connections as they came in. So you know, just imagine how, when you think about it, this is not something we've ever talked about in all these years. How many long forgotten and unattended systems out there are hosting old malware that gangs have moved on from and forgotten. But you know the bad guys don't clean up after themselves, they don't shut that stuff down, they just, you know, move on, they forget about it. So it's still out there, trying, you know, like calling out in the middle of the night, trying to make, trying to reach out and make contact with home base.

0:39:50 - Leo Laporte
Are you there, bots? Never answers is it mostly irc bots these days still, or they have other? They must have other oh yeah, they've.

0:39:58 - Steve Gibson
They've got all you know. That's all kinds of stuff. I would actually I would be surprised if IRC was still in use, because it just so now everything's gone TLS and they had to get a TLS cert in order to be able to accept authenticated connections from all of these, because typically, the malware is living off the land, so it did not bother to bring a whole big TCP, tls internet protocol stack with it. It's just using whatever happens to be in the OS in order to establish outbound connections for it.

So it needs to have a certificate in order for it to be honored. Okay, we're going to talk about IoT in order for it to be honored. Okay, we're going to talk about IoT devices getting the Cybertrust mark after we take a break After this mark, After we talk about our sponsor of the hour, US Cloud.

0:40:58 - Leo Laporte
Actually, it's appropriate. This is Patch Tuesday, isn't it oh?

0:41:01 - Steve Gibson
yes.

0:41:17 - Leo Laporte
A lot of people on Patch Tuesday go. I need help. Oh, yes, now we've been talking about them for a few months. They are the global leader in third-party Microsoft support for enterprises. They support 50 of the Fortune 500. And there's a reason people flock to US Cloud instead of Microsoft. It's less expensive, it's faster and it's better support than Microsoft.

Switching to US Cloud let's talk about less expensive can save your business 30% to 50% over Microsoft Unified and Premier support. But you're not getting some cut rate solution. It's actually better. It's faster twice as fast in the average time to resolution as Microsoft two times faster than Microsoft. And now US Cloud has some new feature. This new feature that I think is so cool that will help you save a lot of money. It's called their Azure Cost Optimization Services.

So if you use Microsoft's Azure, there's a certain I guess Azure creep is the term people use. When's the last time you actually looked at your Azure usage line by line? If it's a while, you've got some Azure sprawl, some spend creep going on. But the good news is you can find it and you can get rid of it. Saving on Azure is easier than you think with US Cloud. So US Cloud offers this eight-week Azure engagement. It's powered by VBox. It will identify key opportunities to reduce costs across your entire Azure environment With expert guidance. You'll get access to US Cloud's senior engineers and when I say senior, they are good an average of over 16 years with Microsoft products and at the end of those eight weeks, you're going to have an interactive dashboard that will identify, rebuild and downscale opportunities, unused resources, allowing you to reallocate your precious IT dollars towards needed resources. You could save a lot or, you know, wouldn't be a bad idea to invest the savings into US Cloud's Microsoft support that's what a few of US Cloud's other customers have done and completely eliminate your unified spend. Wouldn't that be nice?

Sam is the technical operations manager at Bede Gaming. He gives US cloud five stars. In his review. He said quote we found some things. This is with the Azure engagement. We've found some things have been running for three years that no one was checking. These VMs were what I don't know 10 grand a month not a massive chunk in the grand scheme of how much we spent on Azure, but once you get to $40,000 or $50,000 a month, it really starts to add up. It's simple Stop overpaying for Azure. Identify and eliminate Azure creep. Boost your performance, and you can do it in eight weeks with US Cloud.

Visit uscloudcom. Book a call today to find out how much your team can save Better Microsoft support for less. That's uscloudcom. Book a call today. Get faster, better Microsoft support for as much as half as the cost. That's a great thing. I hope you know the name. I hope you'll visit the site. Book a call today and if they ask you, tell them. Oh yeah, I saw it. On security now uscloudcom. We thank them so much for their support of the good works Mr Steve Gibson does here on security, now On we go Sher Okay.

0:44:46 - Steve Gibson
So last Tuesday the US government announced the launch of the US Cyber Trustmark. This is a new cybersecurity safety label for our Internet of Things consumer devices. Now it's unclear to me whether any consumers will care or even notice. Today's IoT devices are often purchased online. Where any such marks go unseen. And with so many certifying standards bodies all weighing in with their own seals of approval, what difference is one more going to make? I remember looking in a box a while ago I think that's what I was. We were at a retail location, micro center, laurie and I, because our router had died on the weekend. And you know, the box is covered with little seals and emblems of certifications and things. It's like okay anyway, but there may be a reason nonetheless to hope that the presence of such a seal may mean something to IOT companies that are seeking any edge they can get. So if changing their behavior or behavior of their products in ways that enhance the privacy and security of the users means that they qualify for yet another seal of approval, then this new FCC award may be, you know, have been worth creating. In their announcement last week, the US Federal Communications Commission, our FCC, said quote IoT products can be susceptible to a range of security vulnerabilities. Uh-huh, they said. Under this program, qualifying consumer smart products that meet robust cybersecurity standards will bear a label including a new US Cyber Trustmark and for anyone who's curious, I have a picture of it, of the effort. That logo will be accompanied by a QR code which users are able to scan to take them directly to an information registry, which is kind of cool, containing easy to understand details about the security of that specific product, you know, such as the support period and whether software patches and security updates are automatic, which this all sounds great, so it seems like something that would be of tremendous interest to at least to the audience of this podcast, you know, but I do wonder how clued in the typical consumer is today. Still, the registry's information will also contain details related to changing the default password and the various steps users can take to configure the device securely. The initiative which was announced last summer in July of 2023, so that's actually summer before last will involve the participation of third-party cybersecurity administrators who will be in charge of evaluating product applications and authorizing use of the label. Compliance testing will be handled by accredited and independent third-party labs Eligible products that come under the purview of the CyberTrust Mark program will include, you know, internet-connected home security cameras, voice-activated shopping devices, smart appliances, fitness trackers, garage door openers, baby monitors, but not everything, of course.

The mark does not cover medical devices, which are separately and already regulated by the US Food and Drug Administration, nor motor vehicles and equipment related that's already regulated by the National Highway Traffic Safety Administration, that's our NHTSA, nor any wired devices and products used for manufacturing, industrial control or enterprise applications. So you know, basic consumer electronics that aren't already covered under something else, the program does not extend to equipment added to the FCC's covered list, the products manufactured by companies added to other lists for national security reasons you know the Department of Commerce's entity list or Department of Defense's list of Chinese military companies nor any ban from federal procurement. So again, your basic consumer electronics, but that's a huge swath of stuff that doesn't already have any coverage. In order to apply to the use to use the US Cybertrust mark, manufacturers who meet the eligibility criteria must have their products tested by an accredited and fcc recognized cyber lab. So that's sort of following the model of ul labs right, where, like where you, the maker of the equipment, submit this to ul labs in order to get their certification. So here the f FCC will recognize a cyber lab, which will then test it to ensure that the product meets the program's cybersecurity requirements and then submit an application to the cybersecurity label administrator with the necessary supporting documents in tow. So for their part, last week the White House chimed in with their canned statement saying, quote the US Cyber Trust Mark program allows for testing products against established cybersecurity criteria from the US National Institute of Standards and Technology, you know NIST via compliance testing by accredited labs and earn the Cybertrust mark label. This will provide an easy way for American consumers to determine the cybersecurity of products they choose to bring into their homes, unquote. So to me this all sounds like really a good thing, not so much that consumers will necessarily be aware and looking for it, but that manufacturers who are in a competitive environment may be willing to change their behavior in order to obtain this.

Now, I did search around the various announcement pages from both last summer and more recently.

There's very clearly a lot of movement on this front, because the wheels turn slowly, with various companies and individuals being selected to fill key roles. That's all been happening, but what I was unable to find at this point was any very clear specification for the criteria NIST will be setting for the behavior of complying devices. However, we've been seeing a lot of good sounding policies coming from NIST and CISA recently, so this is very hopeful. You know things like, remember, requiring long lifetime support and firmware updates and in another instance, requiring consumer devices to be able to keep themselves updated and even requiring that a physical button on the device be pressed before any potentially dangerous configuration change could be applied, thus preventing remote attacks that have otherwise been possible. So these are all really hopeful changes in the right direction. And you know, a decade from now, once all of our first generation systems have been retired or cycled out of service, we may see a very different terrain than we have today. And, leo, you and I will probably be around to celebrate that Episode 2000.

0:52:27 - Leo Laporte
Who knows?

0:52:28 - Steve Gibson
Maybe the podcast will be.

0:52:32 - Leo Laporte
This is good. I think this is really good.

0:52:34 - Steve Gibson
Okay, so surprisingly there was not a lot of security news around. That was all the moderately interesting stuff I was able to find, but we have a lot left to talk about. Sync Thing moved to version 1.29.2. You know, what we want in software is reliability and stability, with infrequent discovery and repair of the exceedingly rare obscure bug. What we don't want are daily, weekly or even monthly updates where we're on the receiving end of the ongoing maintenance of software that advertises itself as being feature complete and finished. Advertises itself as being feature complete and finished. As I've noted before, while I like the many features of the Notepad++ editor for Windows, its author's apparent inability to either leave it alone or get it right has become a source of continual annoyance for me. If supporting his work means encouraging him to keep changing it, then I'm less inclined to do so. Now, all of that is preamble to an event I can't recall ever experiencing. Sunday morning I was surprised by an instance of sync thing which I have open on a side monitor so that I'm able to keep an eye on its synchronization with my other location. It notified me of an available upgrade. I can't recall that ever happening before. And that's exactly what you want. The bug that was fixed by the release of version 1.29.2 was obscure. The person who discovered it wrote, quote by changing the contents of a synced directory. It seems that sync thing crashes when scanning a subdirectory that contains A letter U with an umlaut. Okay, the report of the problem two days ago generated some online dialogue as logs were exchanged and examined and a resolution was produced Sunday morning two days later. You know that's like the perfect model that you want. You know that's like the perfect model that you want. And since sync thing has become a favorite for many of us, you know it's what Leo and I both use extensively now to keep the observation of how refreshing it is to see a highly complex and functional open source software project that's finished being largely left alone because it does everything it was designed to do and so we're not being constantly hounded to update it just because you know its author said oh look, I can. You know we're not synchronizing dishwasher firmware. Let's add that, because wouldn't that be cool? No, no, it wouldn't. We don't need that. We don't need that, okay.

Last week's discussion of the persistence of unencrypted email in transit and the fact that some 3.3 million email servers worldwide, most of them located in the United States, are still not bothering to offer a TLS certificate that would allow for email encryption, triggered a lot of feedback from our listeners. I'm going to share some of it and we're going to talk about it because it's interesting. Philip Peterson said Steve, after your piece on the non-use of TLS for SMTP, I looked at some of the email I've received. I thought it might be small businesses that had not set up certificates, but found it to be large companies as well. The most troublesome one I found is that treasurydirectgov sends their one-time password notifications in the clear. It also seems like organizations with multiple email servers don't all have them set up for TLS. Idme sends the welcome to IDme message from a non-TLS server, although the other messages sent while setting up an account. He says parens to log into IRSgov. We're using TLS, regards Phil. So Philip's note is interesting because it hints at something I want to discuss in greater detail after I share another piece of feedback, but here's the part that's interesting, philip wrote. The most troublesome one I found is that treasurydirectgov sends their one-time password notifications in the clear.

What's tricky about diagnosing email's use of TLS encrypted connections is that it mirrors today's web browsing, where the connecting to server is the one that's offering to prove its identity to its caller. So, in the case of email, it's not the sending SMTP server that offers its TLS certificate, it's the SMTP server on the receiving end that does so the SMTP server on the receiving end that does so. So a sending SMTP server would always have the choice of refusing to send email to any recipient SMTP server that wasn't offering to prove its identity with a TLS certificate and encrypt their conversation, and any received email with a TLS certificate and encrypt their conversation and any received email with a TLS connection. But otherwise, whether or not a sending server is able to protect the email it wishes to send is up to the receiving server. Either the sender or the receiver might elect to not send or receive messages over an unencrypted connection, but it's only the receiving server that's able to offer the use of encryption for both sides to then enjoy. Okay. So let's now look at what Travis Hayes, another of our listeners, has to say. He said Hi, steve, enjoying this week's show, as always.

Regarding the TLS encryption of email, the thought occurred to me that the reason we're where we are, with unencrypted transport of email between gateways, is because email, from the beginning, has always been designed to be fault tolerant, with multiple hops, just like physical mail. If something is to be sent confidentially, it's put into an envelope rather than on a postcard for everyone handling it to read. This is different from the design of the relative latecomer HTTT protocol, which was designed to be point-to-point. The reason SMIME, pgp, gpg and the like were invented was to address that to handle the transfer of sealed packages over a system of untrusted, unknown delivery gateways over a system of untrusted, unknown delivery gateways. So even if widespread adoption of TLS between gateways was achieved, I still have to be trusting that my mail host, your mail host and any intermediate gateways are trustworthy. Even if the mail exchangers talk between themselves over TLS connections, the only way to ensure confidentiality between us is to encrypt the payload itself, and that's the price that is missing. I'm sorry, that's the piece that is missing when all those one-time six-digit pins and forgot my password reset URLs are being sent to me until there's some way for my bank's automated systems and me to exchange public keys so they can securely send those pins to me. It doesn't matter if my bank's ISP and Gmail connect over TLS.

I think there's some interesting things that could be done with the DKIM system. We are already digitally signing email to show it's authentic. Why are we not encrypting the message body as well? Thanks again for the show, cheers Travis. So the point Travis made about email being a multi-point relaying technology is crucial because, as he noted, tls and as we know, tls is only able to work with HTTP because users' web browser clients directly connect to the servers from which they wish to obtain web pages and other web application data. If a browser were to connect to any sort of intermediary server, well, we would call that a man-in-the-middle attack, which we go out of our way to prevent. The point is, with TLS transport layer security, we receive a certificate directly from the server we wish to trust which asserts that server's identity. There's no middleman mechanism.

One reason for this is that, whereas web surfing is a real-time, point-to-point activity, email was never guaranteed to be immediate. These days it tends to be, but that's mostly coincidence. Email was deliberately designed to be a store-and-forward system where someone's mail message would be dropped onto an SMTP server with the address of its destination and that SMTP server would then forward their email onward toward that destination If the receiving server was not answering at the moment. Another server might be tried if the destination's DNS MX records for mail exchange records offered more than one, or the email would be queued for later retry delivery. Having watched the delivery queue of my own email server when it's sending more than 15,000 pieces of email every week to those in this audience who've subscribed, I've seen that it doesn't all go through quickly or immediately. Some mail gets stuck there for a while and then it gets accepted by the receiving end, and I know that everyone has experienced the occasional delay where, you know someone says, hey, I just emailed that to you, you don't have it yet, and then a few minutes later it shows up. This store and forward system was what allowed the internet's email delivery to be extremely robust back in the early days, when connectivity was far less assured and when receiving SMTP servers might be coming on and off the Internet for whatever reason.

Things have changed dramatically since those early days. One of the things that's changed is that connectivity is now pretty much always on and servers are pretty much always up, but during those early days that wasn't always the case. Even now, from time to time, I need to update and reboot GRC servers. From time to time I need to update and reboot GRC servers During those times. For a few minutes GRC's visitors will receive 404 messages about the site being down and any remote SMTP server that's attempting to deliver mail to GRC will find that they need to queue it and retry a few minutes later. So, again, the need to store and forward has not disappeared.

But, as I noted in thinking about Philip's earlier note Philip's first note any remote SMTP server that insists upon sending email to GRC over a TLS connection, to GRC over a TLS connection, or if GRC were to insist upon only receiving email over TLS connections, then that remote server would need to ask for a TLS connection, which GRC would offer, which would allow that remote server to authenticate GRC and for them to bring up an encrypted tunnel with us. However, note that although we do get encryption for privacy, the authentication is only one way. Grc offers up its TLS certificate, but the incoming connecting SMTP server does not, but the incoming connecting SMTP server does not. So it's a one-sided deal. What this all appears to represent more than anything else is just laziness or lack of concern, really, on the part of the industry. We talked last week about how free certificates were not easily deployed using the ACME protocol because it appeared to be myopically designed for web-only use. I'll have some feedback from listeners about that in a minute. But encryption, if that's what we want, if we want encryption, it's easily obtained.

As we've often discussed, standard generic Diffie-Hellman key agreement allows any two parties to publicly negotiate a secret key which they could then use for their communication. Doesn't need a certificate for that. This would protect email and transit from passive eavesdropping. But since Diffie-Hellman-style key agreement does not itself authenticate the endpoints, again no certificates. This would not prevent an active attacker from intercepting email communications, taking the man-in-the-middle position, then negotiating separate keys with each endpoint on either side and being able to see everything in the clear as it passes through this intercepting tap. But we do have a potential mechanism that would solve the entire problem if anyone really cared to. Because, although it's not the default case for anonymous web browsing, it is possible for both ends of a TLS connection to require the other end to provide a trusted TLS identity certificate. So simultaneous mutual authentication of TLS connections is possible, of TLS connections is possible, but no one really appears to care that much and there doesn't appear to be any movement afoot to improve email security.

We do, however, care about spam and spoofing. So those problems, notice, have been solved. Spf allows a domain to specify which SMTP servers are allowed to originate its email, and DKIM allows those SMTP servers to cryptographically sign the email they send. In both cases, dns is used to supply the SPF record and the server's matching DKIM public key. This is done to prevent others from being able to originate spoofed email claiming to come from any source that has protected itself with these measures, but even then, it's up to the recipient to care enough to check. I'm not sure where all this leaves us. We definitely have the tools today to bring up mutually authenticated and fully point-to-point encrypted email. Before that could happen, practically all email servers would need to have current and maintained certificates, just as all web servers do today. And this brings us to our listeners, who have arranged to do so. Leo, we're at an hour, let's take a break, and then we're going to look at what Josh Caluette in Austin, texas, said in response to my saying let's encrypt Doesn't make that easy.

1:09:51 - Leo Laporte
It's kind of you know, and I want to hear all about this, but my attitude is email is not, and was never intended to be, secure. You shouldn't be using email for secure communications. Use Signal or something that's encrypted and has all of those features built in.

1:10:06 - Steve Gibson
Well, and I'm sure you know anyone who's worked with a financial agency of some sort like when I'm doing anything that is important, they send a link which. I use on the web to then authenticate myself and log in, and then it's a web communication. It's a web session where the actual work gets done not email, then it's TLS.

1:10:35 - Leo Laporte
Yeah yeah, email was really. It's inherently insecure.

1:10:41 - Steve Gibson
And here we are using it for pins and password recovery links. Sigh, because that's all we have.

1:10:48 - Leo Laporte
By the way, the Patch Tuesday updates came out 161 updates, including three zero updates.

1:10:54 - Steve Gibson
Oh 161. Oh.

1:10:58 - Leo Laporte
That's more patches than they've shipped in one go, according to Brian Krebs, since 2017.

1:11:09 - Steve Gibson
Wow, but it's getting more secure. That's right, leo, it's settling down, it's just, it's just like sink thing, it's all done. And it was that pesky umlaut over the? U? Yeah, you never know, wow a hundred zero day umlaut.

1:11:21 - Leo Laporte
Yeah, you never know. Wow 100s, zero-day umlaut. Wow, our show today. We'll be right back with more security now. I know you love this show.

By the way, if you don't like interrupting the show, if you don't want advertisements, we do make an ad-free version of the show available, of all of our shows available if you pay for it and I know I mean, it's lovely to get it for free. That's why there's ads. Somebody's got to pay for it and thank you to our great advertisers who do. But if you join Club Twit, seven bucks a month, no more ads, plus a lot of other benefits like access to the Discord. We're really pushing this year to get more members because as ad sales dwindle, not for this show but for other shows, we need to make up that revenue and I think the best way to run a podcast network is supported by the listeners. Unfortunately, I'm the only one who thinks that, because fewer than 2% of our audience members actually are members of the club. I'd like to get that to, I don't know. 5%, 1 in 20. That doesn't seem so much. $7 a month, ad-free versions of all the shows, access to the Discord, special programming just for club members and a whole lot more. Find out more at twittv slash club twit, our show.

Today we do have a fine sponsor, delete Me, and it's a sponsor probably a lot of you know about and if not, you should know about it. You know we talk on this show about things like the big national public data breach where hundreds of millions of people's social security number was revealed, including Steve and mine. But when Steve and I went to check, I said let me check Lisa's, and Lisa's social was not in the National Public Data database because she uses Delete Me and that's why you need to use Delete Me. If you've ever searched for your name online, you won't believe the detail and the amount of personal information that's out there, including even your social security number. This is something we all need to worry about, not just a personal concern, but a business concern. That's why we got Delete Me for Lisa A family affair too. With Delete Me's family plans and corporate plans, you can ensure that everyone in your family or your company stays safe online. Delete Me reduces risk from identity theft, cybersecurity threats. That was the real reason we had to get it for our management at Twit, because we were getting spear phishing, because all that stuff was easily found online, saves you from harassment and a whole lot more.

We believe in Deleteme because we've used Deleteme. Deleteme's experts will find and remove your information from hundreds of data brokers. If you're doing it in your family, you can assign a unique data sheet to each family member, tailored to them, with easy to use controls. Account owners can manage privacy settings for the whole family or the whole company. Deleteme will continue to scan. This is actually really important because even if you get rid of all that information, the dossiers begin to refill almost immediately. Plus, there's new data brokers all the time. This is their business. The lead me knows who's out there and make sure that they continue to scan and remove your information regularly Addresses, photos, emails, relatives, phone numbers, social media, property, value and more.

It's all in these databases. Protect yourself from data brokers. Reclaim your privacy. Visit joindeleteemecom slash twit. When you use the offer code twit, you'll get 20% off. Joindeleteemecom slash twit. Don't forget the offer code twit, and we thank you so much for supporting security now and all of all of you and all of us who use delete me and our privacy is, uh, is I mean it makes such a big difference. Join delete mecom slash twit offer code ist w I t back to you, steve, okay.

1:15:19 - Steve Gibson
so josh caluette in austin texas wrote hi, steve, I was just listening to last week's podcast and I heard you mentioned that let's Encrypt does not support email services. However, I've been using let's Encrypt on my mail servers for a few years now. The CertBot app has some plugins that make this possible even without a web server. One of the plugins is for NGINX, which is a web server, and Apache, another web server, which allow it to spin up a temporary web server for the verification process then takes it down again. The other plugin is for DNS text verification. There is an RFC 2136 dynamic DNS plugin which allows for dynamically updating a DNS zone with the necessary text record, waiting for propagation, completing verification and then deleting the record. This works with any servers that support and are configured to allow dynamic DNS updates securely using private keys. There's a similar plugin which I use specifically for Cloudflare. It does the same thing, but it works with the Cloudflare API to dynamically update the DNS zone with the correct text record Once a certificate has been generated or renewed.

It can be used in the config of anything that accepts certificate private public keys. Because the file names do not change, you can easily configure services to point to the let's Encrypt Managed files and then configure CertBot with a POST script to restart the necessary services in order to begin using the new certificate. I've been using this for the past couple of years and it has worked great with no intervention. I have some monitors set up that monitor all of the certs used by services and alerts me if any of them get within 28 days of expiration, as that indicates a problem, since they should be renewed by or before reaching the 30-day mark. But anytime there's been a fault, it's been due to my own errors, firewall changes, bad configuration changes, etc. Thanks for all you do.

I look forward to the podcast during my two days a week commute and to and from work. Okay now, I think Josh's note serves to illustrate two things perfectly yes, it's possible and no, it's neither automatic nor easy. And not surprisingly, many of our listeners who are technically sophisticated and capable of rolling their own kludges, have similarly done so. And a kludge it is. That's the proper term for arranging to create a temporary web server to satisfy a port 80 only certificate issuing service or dynamically editing dns and waiting for propagation, then copy the resulting certificate around and restart all dependent services nightly, so that the updated certificates are recognized Wow.

1:18:36 - Leo Laporte
But you know what? That's not the hardest thing about running your own email server either. Okay, but admittedly you're pretty sophisticated, yeah it's the very definition of a kludge as I mentioned last week.

1:18:49 - Steve Gibson
Now I fully intend to do something similar. I'll have no choice if the lifetime for all certificates are forced to drop below one year. Given that, long certificate lifetimes appear to be an entirely made-up problem. The more I've thought about this, the more it seems that web browser certificates should be members of a separate elite class. If that's what they want, let them expire every six days so long as anyone offering the ACME protocol will keep them all fresh, but then leave everything else alone. Let non-web servers use good old, reasonable three-year life certificates for, you know, our internet appliances, email servers and other things. Don't force this nonsense down everyone else's throat or allow those of us who wish to obtain an identity asserting certificate, for which we're paying good money, to decide for ourselves how long that certificate should last. Obviously, every time I talk about this, I get myself all worked up.

This just really rubs me, so let's change the subject. Doug Curtis in Waukesha, wisconsin, said Steve, thanks so much for your overview of the current state of the art on AI. It prompted me to use ChatGPT to get some recommendations for more sci-fi books. I've really enjoyed some of the recommendations that you've made over the years in various Security Now episodes. I received a gift for Christmas of several credits toward Audible, so I wanted something new to listen to. I started by asking ChatGPT about two of my favorite sci-fi series the Bobaverse and the Giants series and then I asked it, based on those two series, if it could make recommendations based on my preferences. It made quite a few. I'm starting with something called the Murderbot Diaries by Martha Wells.

1:21:15 - Leo Laporte
Stacey Higginbotham loves those.

1:21:17 - Steve Gibson
He said so far and a few chapters into the first book of the series. I'm liking it very much. The next book that I'm going to try after this one is called Old Man's War by John Scalzi. I've read another of his books called Starter Villain, which was very interesting. Thanks again for all you and Leo do with the Security Now podcast and for your Spinrite program. I have a license and have used it several times. Regards Doug Okay, so I've not looked at the Murderbot diaries, but I've definitely heard of them and other of our listeners have recommended them to me, and the same goes for John Scalzi's Old Man's War novel. It's been recommended too.

Taking Doug's clue of asking ChatGPT for some recommendations, I logged into my own ChatGPT account, selected the full-strength O1 model and asked the following question Quote I enjoy reading science fiction novels and my favorite author is Peter F Hamilton. I also enjoyed the Silver Ships series and Rick Brown's Frontiers Saga series. Can you recommend other authors whose science fiction novels may be similar? Now, this gave it some pause while it worked through what I was asking. The O1 model shows you the various phases of its work as it's going along. After cogitating for a full 10 seconds, it replied. If you're a fan of large-scale space opera likens like Peter F Hamilton's Commonwealth or Knight's Dawn universes, and long-running series with plenty of interstellar adventure, like SH Yuka's Silver Ships or Rick Brown's Frontiers saga, which of course, it apparently understood the natures of because it correctly characterized them it wrote here are some authors slash series that capture a similar feel. First recommendation Alistair Reynolds. He said he it it, it's recommended, he it it it Recommended.

1:23:51 - Leo Laporte
So Alistair Reynolds, he said it said I can't, I'm having a problem with my pronouns.

1:23:53 - Steve Gibson
It's hard not to personify it, it's really hard. It is Recommended starting point. Revelation Space, which I should say I have read and very much enjoyed. It wrote why you might enjoy it. Reynolds is known for sweeping, galaxy-spanning storylines that blend astrophysical plausibility with far-future imagination. If you like Hamilton's big ideas, reynolds' Revelation Space Universe offers a similar sense of scale and mystery and I agree they were a little dark but they were definitely captivating. Second recommendation Neil Asher. It said recommended starting point Gridlinked or the Skinner, both set in the polity universe. As for why I might enjoy it, it wrote Asher's polity novels deliver gritty, action-packed stories in a post-scarcity future run by powerful AIs. The cast includes enhanced humans, alien threats and a lot of big tech ideas echoing the grand technology vistas in Hamilton's work. Third recommendation James SA Corey. No surprise, recommended starting point Leviathan.

1:25:11 - Leo Laporte
Wakes book, one of the Expanse.

1:25:13 - Steve Gibson
Why you might enjoy it. The Expanse is a multi-volume series known for its realistic-ish physics, gritty political drama and deep space exploration. While it starts in our own solar system rather than spanning galaxies, it still provides epic storytelling and intense space conflicts. And then, I have to say, my eyebrows rose. Number four, jack Campbell, recommend a starting point Dauntless book, one of the Lost Fleet, which was one of my earliest recommendations for our listeners.

1:25:50 - Leo Laporte
I remember, yeah, yeah, it said why you might enjoy it. You recommended all of these books except for the Asher right. Yes, yeah.

1:25:56 - Steve Gibson
Yes, campbell's Lost Fleet series focuses on large-scale fleet engagements, strategy and leadership under pressure. Fleet engagements, strategy and leadership under pressure Perfect, if you like, space opera with a strong military twist, intricate battles and a big overarching plot. And again, I'm just. I'm astonished by this response. Fifth, david Weber recommended starting point. Oh my God, on Basilisk Station. Oh my god. Book one of the Honor Harrington series.

1:26:28 - Leo Laporte
Yeah, I think you might like that.

1:26:31 - Steve Gibson
Maybe just a bit. Read it twice and I actually read the Lost Fleet series several times, it said. While you might enjoy it. While the Honorverse is definitely military sci-fi, it features expansive world building across numerous star systems, detailed technology and a strong continuity across a large number of books, much like Hamilton's broad universe building, huh. Number six, elizabeth Moon Recommend a starting point Trading in Danger book, one of the Vata's War series. While you might enjoy it, moon's style blends space opera, military sci-fi and strong character development. The Vata's War series follows Kailara Vata and her family in an interstellar trading empire. So you get both epic space battles and corporate-slash-political intrigue.

Seventh, glenn Stewart Recommend a starting point Starship's Mage book, one of the Starship's Mage series, or Duchy of Terra series. You might like it because Stewart's series offers combined space opera tropes like Starship Cruise, alien Empires and Grand Scale Warfare with a smooth, action-driven narrative. They're fast-paced, entertaining reads that grow into multi-book arcs. Finally, number eight, michael Cobley Recommend a starting point Seeds of Earth book, one of the Humanity's Fire trilogy. You might enjoy it because Copley's Humanity Fire features multiple human colonies struggling after Earth's near destruction, alien civilizations and galaxy-scale conflict. If you enjoy multi-threaded plots and epic storytelling, this trilogy is worth a look.

I'm reading what it wrote. I'm just astonished. And in the more to consider category at the end there's John Scalzi, known for his blend of humor and is character-driven, swashbuckling space opera with great political intrigue. Ian Douglas and Joel Shepard. Anyway, summary at the end if you love the grand interstellar scale of Peter F Hamilton's books and the long connected story arcs found in silver ships and the frontiers saga, these authors deliver similar epic space operatic adventures. Whether you lean more toward military sci-fi or more traditional space opera, they're sure to be a new universe here to explore that's hysterical, unbelievable.

1:29:23 - Leo Laporte
Had you read all of these, most of of these, I know. The first three or four you knew.

1:29:28 - Steve Gibson
No, I'd read Alistair Reynolds. I don't think I ever mentioned it. But of course, Jack Campbell and the Lost Fleet and David Weber with the Honorverse and Honor Harrington.

1:29:38 - Leo Laporte
Yes, of course, yeah, of course. In fact, you could be cribbing from your show notes. To be honest with you, Could?

1:29:45 - Steve Gibson
be, and I did publish. Yes, it occurred to me, and I did publish a Steve's Sci-Fi Reading Guide PDF that does have the earlier works, the Lost Fleet and the Honorverse stuff. So, wow and Leo, I have a new author. Okay, I decided I had heard a lot of neil asher mentioned. I had never read any of his books. I've already started and I cannot put it down.

1:30:18 - Leo Laporte
Oh good, it really looks and which one of you is reading gridlink to the skinner gridlinked or the Skinner Gridlinked?

1:30:26 - Steve Gibson
Gridlinked, Gridlinked, it is just. I just, and I have to tell you, Leo, a couple of weeks ago I'd finished this latest Hamilton workout.

1:30:40 - Leo Laporte
And I thought I need something simple.

1:30:44 - Steve Gibson
Yeah, I overdid it in the simplicity category.

1:30:49 - Leo Laporte
You went too far.

1:30:54 - Steve Gibson
The book. It was called Artifact and it began. I kid you not, the book started as it dropped out of orbit, the alien starship Ziggawatt. Oh, never mind.

1:31:01 - Leo Laporte
And at that point Bye-bye. I should have stopped Bye-bye.

1:31:07 - Steve Gibson
You actually called your alien starship Ziggawat.

1:31:12 - Leo Laporte
Uh-huh.

1:31:13 - Steve Gibson
No, no. Anyway, I've been saved by Neil.

1:31:17 - Leo Laporte
Asher, I've never heard of him. I'm going to have to look that up. I have heard of him.

1:31:21 - Steve Gibson
And I thought it occurred to me that it's somewhat fitting that after finishing the first novel in Peter Hamilton's newest two-book series, I plowed into the research to understand how chat, gpt and similar large language models operate. That technology has just recommended how I might best resume my previously interrupted work to return to science fiction. I believe that's what's known as closure.

1:31:55 - Leo Laporte
Yes, full circle.

1:31:57 - Steve Gibson
This grid-linked novel, whoa. I mean, it is exactly. It's just. I just want really good writing More than anything else. You know, Not Zigawatt, not so much, but this is like whoa the author makes you work a little bit to understand the meaning of new terms, and then it's like oh, I know where that came from.

1:32:25 - Leo Laporte
Interesting new terms. And then it's like oh, I know where that came from.

1:32:27 - Steve Gibson
Anyway, it's good, it's good. Okay, bob said hi, steve, I want to supply some feedback to your last show regarding auto updates of hardware. I don't agree with your comment that enterprise level network security appliances, firewalls, routers and switches should be set up with automatic updates. History has shown that automatic updates can cause devastating outages for businesses. I find it doubtful that you would turn on automatic updates on any of your systems. Okay, well, he's got me there. Yeah, I'm not at all certain that I would take my own advice in that regard, but he continues. Maybe the point here should be if a person's company does not have the staff, knowledge, experience or money to have test systems that can be used to install updates and confirm that they're working as expected, then, and only then, using automatic updates makes sense, since at least that way they would be protected from unpatched vulnerabilities. But again, they would probably be better served with a managed service partner taking care of their systems for them. Okay, of course. Now that's meaning that smaller enterprises should perhaps outsource the responsibility for managing the infrastructure which, on the one hand, they need because you need to have a network and it needs to be connected to the internet these days, but which, on the other hand, they don't have the staff focus or care to maintain for themselves. So I think Bob makes a good point, even though we have seen the MSP route go very wrong, when the MSP's network was compromised, which allowed bad guys to get into the networks of all of their clients, which allow bad guys to get into the networks of all of their clients. Anyway, bob continues, I retired.

He wrote from a multinational transaction processing company After a security breach. They implemented tightened security procedures that I am surprised more companies don't. This company has more than 50,000 employees. He said we used network segmentation and the office network was not able to directly connect to the transaction processing network without going through a bastion server which was fortified, through a bastion server which was fortified, locked down and had separate two-factor authentication. All new servers had to have a defined owner contact and business unit owner. All firewall rules had to be justified and these rules needed to be reviewed by the business unit owner quarterly to ensure that the rules were still needed.

All hardware and software had to be supported by the manufacturer. Patches needed to be installed within two weeks sooner if the issue was critical, allowing time for testing, production, beta testing and full rollout. We had redundant data centers so we'd first install into the production data center and if the updates caused issues, we'd fail over to the unpatched backup systems. These guys were serious. But again, a 50,000 employee, some sort of transaction processing center, I mean that's a big global enterprise. We don't know who these people are.

But yeah, he said all software being run on any systems needed to be whitelisted. Being run on any systems needed to be whitelisted meaning you can't even run anything that isn't permitted. So it's not a blacklisting system, it's whitelisting meaning deny all permit specifics. Any exceptions, he said, needed to be reviewed and approved. No personal devices could be used on any networks Wow, he says I won't even get into the DDoS and web app firewalling we used. He says my point is security is tough and employees hate it. He said I know because they kept complaining to me how much harder their jobs were once we implemented the clearly required security measures. My comment back to them was that they were being paid very well and if we were breached they likely wouldn't have a job because clients would drop us and move to a competitor. He finished love your show. Happy new year, bob. So Bob's note is a perfect case in point for the trade-off of convenience versus security. And imagine the extra cost to this organization of doing all this.

1:37:46 - Leo Laporte
This isn't free either. What's the cost of a breach either right Exactly?

1:37:51 - Steve Gibson
And the reputation damage that takes a long time to amortize out of an employee who relocates from a company with very little security and lacks useless controls to one with strong and truly useful security. Such an employee might well be grousing about how they didn't need to do all this or that at their last company. Right? And finally, our listener, patrick Beamer, who runs a 15-year-old, runs a 15-year-old managed service provider himself. You know an MSP shares some background on SonicWall. Patrick wrote hey, steve, I'm listening to your commentary about SonicWall exploits Remember we talked about them last week about how so many of them after four months from a critical patch being made available, 10% still had not been patched and how many apparent vulnerabilities on the public internet remained. He said I'm listening to your comment here about SonicWall exploits and I wanted to provide some additional thoughts about why over 10% of the installed base is still vulnerable to an exploit from August of 2024. He says I run a 15-year-old managed service provider and have been a SonicWall partner from the beginning.

Sonic Wall firewalls were mandatory for all our clients. He says, perenz, we're slowly moving our clients away from Big Iron at the edge for reasons that are not relevant to Sonic Wall as a company or this message, he said. Sonic Wall is a very popular firewall for small businesses and MSPs. These aren't large companies with IT departments, but are typically orgs with 10 to 15 staff that rely on an MSP or maybe a I love this term, I've never seen it before, leo a solopreneur. They rely on an MSP or maybe a solopreneur to support them. You know a one-man tech firm, small. He said. Worse, many companies this size choose not to maintain a relationship with a support partner. These firewalls are just sitting there waiting to be exploited, and there's a lot of them, he said, all caps.

Secondarily, leo asked why SonicWall doesn't just push the firmware updates. Two reasons First, concern about impact, responsibility and liability. Setting at the edge of a business a firewall with a bad update immediately becomes a hair-on-fire emergency. As an MSP, I wouldn't want SonicWall pushing updates at my clients' firewalls. That's not their job. The risk here for SonicWall is too great. The other reason is that SonicWall sells features, and the feature that enables cloud-based scheduled firmware updates costs extra, a cost that many budget-conscious businesses are unwilling to invest in. He said parens, we make it mandatory. Close, parens, he said. I hope that provides a little context about why this is still a thing. Finally, I want to take a moment to thank you and Leo for the expert guidance I've received over the years. I've been following Leo since the 90s.

1:41:40 - Leo Laporte
I started using Shields Up. Oh, that's who's been behind me. I was wondering who's following me.

1:41:44 - Steve Gibson
He's been following you since the 90s. He said I started using Shields Up almost as soon as it came out, and I've been following you both ever since, though it wasn't until I got my CISSP in 2019 and needed a reliable source of CPEs that I started listening regularly, and I'm also a member of Club Twit. The information you provide each week keeps me informed and makes my job easier. Thank you, cheers, patrick Beamer.

1:42:17 - Leo Laporte
That gives me an idea for a slogan for joining Club Twit it's cheaper than a firmware update feature or something like that.

1:42:26 - Steve Gibson
Yeah there were lyrics to a song, or maybe it was a title. It's cheaper to keep her.

1:42:33 - Leo Laporte
Cheaper to keep her, which I never got out of my head. Seven bucks a month is cheaper to keep her.

1:42:41 - Steve Gibson
Anyway, I thought Patrick'd spotted a contradiction, since he noted that you know the potentially catastrophic danger that automatic updates pose. Yeah, but he makes a mandatory Well then he later noted that automatic updates were actually available for an extra fee.

1:43:01 - Leo Laporte
That's the problem.

1:43:03 - Steve Gibson
So which is it?

1:43:04 - Leo Laporte
Yeah.

1:43:16 - Steve Gibson
Either they're a danger or they're a benefit. Yeah, that's the problem, that part of that agreement with SonicWall is that keeping one's firewall updated is a good thing. Thus the reason for offering the service in the first place.

1:43:31 - Leo Laporte
Good point.

1:43:31 - Steve Gibson
But if something happens as a result, we did the best we could and, after all, you paid us to do this for you, because it's what you asked for.

1:43:45 - Leo Laporte
Oh, that's, a good point so it sort of you know it takes the danger level down a bit Okay.

1:43:52 - Steve Gibson
So we're right on schedule. We're at an hour 34. We are now going to roll up the sleeves and dig in, so we'll take a break. We have one left, which I'll break in the middle of the balance of this, because people are going to need to catch their breath, I think.

1:44:14 - Leo Laporte
It'll be a good break. Yeah, go on.

1:44:16 - Steve Gibson
It's going to be where we're headed is not for the faint.

1:44:22 - Leo Laporte
You can run out and get a Vernors or something to stimulate the brain. Our show today brought to you by 1Password. You know the name, I know you do, and maybe you remember when 1Password acquired another sponsor of ours, collide. Well, they've put them together to make something called the 1Password Extended Access Management. That is a great, affordable solution for every company. If your end users are so good, like, uh, like our correspondents here at the big financial services company, that they never bring in their own devices right, they never use any app not approved by IT, right, then you don't need to listen to this commercial Congratulations. But if you're in a company where they've got their own phones, they've got sometimes they bring in their laptops and sometimes those devices have apps that you never heard of. You need to be listening. How do you keep your company's data safe when it's right there next to those unmanaged apps, on all those unmanaged devices? 1password has a solution Extended Access Management. 1password Extended Access Management helps you secure every sign-in for every app on every device because it solves problems the traditional IAM and MDM just can't touch. It'll help if you think of your company's security.

Like the quadrangle of a college campus Beautiful. Imagine that green lawn, with the lovely brick paths winding their way between the ivy-covered buildings. It's just perfect. It's the peaceful kingdom right. Covered buildings it's just perfect. It's the peaceful kingdom right. Those are the company owned devices, the IT approved apps, the managed employee identities. Everything's nice and manicured. But no quadrangle stays that way, because there's always those little muddy paths. That are the paths that people actually use. They bypass the brick paths because they want the straightest line from building A to building B. We human, after all, we're not going to go winding down the brick path and we can just go cut right across. Well, that's, that's what happens on your network. Those are the unmanaged devices, the shadow it apps, the non-employee identities like contractors, stuff that you don't really have any control over, right, but but that people use. The problem is, most security tools work perfectly well on those winding brick paths, but many of the security problems happen on the muddy little shortcuts.

One Password's Extended Access Management is the first security solution that brings all those unmanaged devices and apps and identities under your control. It ensures that every user credential is strong and protected, every device known and healthy and every app is visible. 1password is ISO 27001 certified and they have regular third-party audits so they exceed the standards set by the authorities. You know the people in the know. They're a leader in security. You know the name. Of course you do. One password extended access management security for the way we work today. It's now generally available to companies with Okta and Microsoft Entra. They are in beta for Google Workspace customers. You've got to check this out. Secure every device, every app, every identity, even the unmanaged ones. At 1passwordcom slash security. Now it's all lowercase 1password, the number one P-A-S-S-W-O-R-Dcom slash security now. We thank 1password so much for their support on the show and we thank you for supporting us by going to that special address. 1passwordcom slash security now. All right, wait a minute. Let me get my thinking cap on. I'm ready. Let's talk about HOTP and TOTP, steve. Okay.

1:48:23 - Steve Gibson
As I mentioned at the top, today's topic was inspired by feedback from one of our listeners. Max Feinlieb sent two notes two weeks apart. I collected his two questions, which I initially started out answering as part of our regular listener feedback. Length grew I realized that not only had we somehow never at any point in our 1007 prior episodes talked in detail about something that probably every one of us is using, but I believe that the details of the technology that's going on would be something everyone would enjoy thinking about, because there's more to it than you might think. Okay, so to get us started, here are the two pieces of feedback Max provided. He said first hi, steve.

I've been noticing lately that the six-digit codes I get for two-factor authentication almost always seem to include one or more repeated digits. Of course, you'd expect some repeated digits. Nearly 85% of six-digit numbers have six unique digits. However, my sense is that there are more repeats than there should be. I see a lot of codes that only use three or four unique digits, like, say, 906090 or 131327. It feels like the codes are being biased toward numbers with repeating patterns to make them easier to type.

Have you or any other listeners observed this? If two-factor authentication codes are truly being dumbed down in this way. How much of a concern is that? Maybe it's not a big deal, because the 30-second rotation makes brute forcing two-factor authentication codes quite difficult To note. I use DiscoDuo for my personal accounts and Microsoft Authenticator for my work accounts. Both apps seem to give me these dumbed down codes. Thanks, max. Then, two weeks later, max said Hi, steve, I wanted to follow up on this question. Over the past several weeks since I sent you this, I've continued to note my two-factor authentication codes. I've continued to get much below 15% of my codes with six unique digits, and it's far more common to have two repeats or a tripled digit. My mom has been doing the same and she's only told me about two occasions when she got a code with six unique digits. So I still believe that two-factor authentication codes are being dumbed down for easy typing. Would love to hear if you can find anything on this.

1:51:09 - Leo Laporte
Well, this is really interesting. I'm looking at my 2FAS app and looking at all the codes and he's right. I don't think I have any with the six unique digits. He's saying that 85% of all numbers should not have a repeat or should have.

1:51:27 - Steve Gibson
Yeah it turns out, uh, and I think either I did or he did somebody. Uh, I think maybe I did. I asked chat gpt, which I'm still having fun with and it stunned me again. It perfectly explained where that 15% came from. It explained that for the first digit you have any one of nine possibilities, Then for the second digit, any one of eight possibilities, then any one of seven, then any one of five and so forth.

And when you do the math, multiply it out and divide it by a million possibles, you know from 0, 0, 0, 0, 0, 0 to 9, 9, 9, 9, 9, 9, that's 15%.

1:52:14 - Leo Laporte
It's like 15.21 or something like that. Okay, yeah.

1:52:18 - Steve Gibson
So you can do the math, okay. So, before we examine Max's observation, his question, as I said, points out that in none of our previous 1,007 podcasts have we ever taken the time to examine exactly how and where these time-varying digits are generated. Since that bears upon Max's observation, as the saying goes, no time like the present, but even more. This provides the perfect setup for one of our theoretically pure deep dives into fundamental computer architecture and technology. And buckle up, because there's more here than you might imagine. Even the gurus among us who know all this maybe give you something to think about. T O T P, which is the abbreviation for the algorithm that all time-based authentication uses, stands for time-based one-time password algorithm. It was standardized and specified in RFC 6238 back in 2011. It builds upon HOTP, the HMAC-based one-time password algorithm, which was standardized and specified by RFC 4226 in 2005. In 2005. We positively know that these standards are what everyone must be uniformly using everywhere. Otherwise, there would not be and could not be the universal agreement we obviously have about the proper six-digit code to use at any point in time. So that's established. These are the governing standards and specifications. So this allows us to dispassionately examine those two RFCs to see what they say, knowing that they must be operative. Of the two, the only one that matters is the earlier HOTP, since that's the standard that's used to generate the digit sequence, with TOTP just being used to feed a new time-based value into HOTP every 30 seconds. Hmac H-M-A-C stands for Hash-Based Message Authentication Code, where the HOTP standard uses the long-proven, well-known-to-be-cryptographically-secure HMAC SHA-1 hash algorithm.

As we've discussed many times on this podcast, any cryptographic hash function, such as SHA-1 in this case, takes an input plaintext of any length and digests it into a fixed length output. That's all any hash function does. So we can imagine that we are wanting to somehow hash the current time of day and date to produce and then display a random-ish result. The problem is, if that's all we did, everyone's authenticator would be producing the same random-ish result all the time. What we need to do is introduce the idea of a secret key so that we can create a collection of these time-varying, randomish outputs. Once again, our cryptographic toolkit provides a perfect tool known as the HMAC. The long-established and well-proven HMAC algorithm uses any cryptographic hash at its heart, but it also adds the provision of a key, so it essentially takes an unkeyed and unkeyable generic hash function and turns it into a family of hash functions, where the particular hash function performed is determined by the HMAX key. So now we have the basis for what we need.

A remote server randomly generates a secret key to be used for authentication for a specific user. It converts that secret key into a QR code and presents it to the user as part of their identity signup. The user's authentication app scans the QR code to capture and retain that key, and the remote server stores that key with their account Subsequently at any point in the future. With each endpoint having the same shared secret to key their respective HMAC functions, they're each able to HMAC the current time of day and date, which will result in an identical output. And since the output will only be identical if both HMACs are identically keyed, this allows the re-authenticating user to prove that they still have the previously shared secret key without ever divulging what it is. And since this correct output is based upon the time of day and date with 30 seconds of granularity, anyone who might arrange to intercept or capture the authenticating conversation will not have obtained anything that they can use in the future, since they won't ever have the secret key. So we have an extremely elegant solution that is working well for us today. I wanted to first establish this foundation for those who may not have been with us from the start, so that we're not missing any critical pieces for what comes next.

At the heart of every HMAC lies a hash function, and in the case of the TOTP and HOTP functions, which were standardized back in 2005, that hash function is the venerable SHA-1. The SHA-1 hash takes whatever is fed into it and hashes that into a fixed size, 20 160-bit hash digest. What we know about any cryptographically secure hash is that the bits produced by this hash are all every single one of them completely pseudo-random. The SHA-1 hash has been in use for decades and its bits have never shown any discernible pattern that would weaken it. The only reason SHA-1 has been deprecated over time is that these days, the world has much more processing power available for hacking and cracking than it once did for hacking and cracking than it once did. So we'd prefer to have more bits of hash output just for the sake of more is better and it makes us feel more secure. Consequently, the world has moved to the newer family of SHA-2 hashes, typically using SHA-256 to give us 256 bits, or 32 bytes of hashed output.

Okay now I could hear some of our more informed listeners grumble that this old SHA-1 hash was found to have some weaknesses. That's true, but none of those ever related to the use of the hash for the generation of high-quality, pseudorandom data. High-quality pseudo-random data. There were some so-called pre-imaging attacks against SHA, where it was being used to generate a cryptographically secure signature for a document. We never want to be able to manipulate the input of a signature's hash so that we're able to design a modified document that winds up having the same hash and thus signature as the target document. That would completely break the guarantee that document signing provides. Over time, sha-1 was found to have some weaknesses there.

As junior cryptographers, the important takeaway lesson for us is that just saying SHA-1 is always depends upon how that function is being used, and SHA-1 remains a perfectly good and cryptographically strong pseudo-random number generator For this application. As a pseudo-random number generator, it needs no upgrade or replacement. This is why the entire industry has remained standardized upon it, even today, in 2025. Okay, so, with 30 second granularity, the UTC time, as in the current time and date, along with a secret key, is fed into this SHA-1 HMAC, which converts it into a cryptographically strong pseudo random set of 160 bits, which is 20 bytes. So we have what is essentially 160 pseudo-random bits. This can be viewed as a single, very, very large decimal number ranging from zero to two, raised to the power of 160, which is okay. Now it's in the show notes. Leo, put it on the screen. Thank you, leo. Uh, I cannot begin to pronounce this. It is 1-461-501-637-330-902-918-203-684-832-716-283-019-655-932-542-976. Wow, that's the number.

2:03:33 - Leo Laporte
I'm going to ask ChatGPT how you say that in English.

2:03:36 - Steve Gibson
Oh, you probably could. I'm going to ask ChatGPT how you say that in English, oh you?

2:03:37 - Leo Laporte
probably could I bet I could.

2:03:38 - Steve Gibson
It is a 49-digit decimal number, so that gives you a sense for the size of the number of combinations that you can have of 160 binary bits. So I mean, this is why binary and bit length is so powerful. There's only 160 binary bits, but you get that many combinations of them, Okay. So now let's explore, because this is the output of the HMAC 160 pseudo-random bits.

2:04:20 - Leo Laporte
You want to know.

2:04:21 - Steve Gibson
Okay.

2:04:23 - Leo Laporte
I'm going to put this up on the screen 1, quattro decillion, 461, tredecillion, 501, duodecillion, 637, nonodecillion, 330 decillion, 902 nonillion, 918 octillion, 203, septillion, 684, sextillion, 832 quintillion, 716 quadrillion, 283 trillion, 19 billion, 655 million, 932 thousand, 400, 542 thousand and 976. Wow, wow, it's an extremely large number. Says Perplexity 2,976. Wow, wow, it's an extremely large number, says Perplexity AI.

2:05:02 - Steve Gibson
And what's interesting is it got the digit count wrong.

2:05:05 - Leo Laporte
Oh, did it, yeah, oh yeah. It says it's 51 digits.

2:05:08 - Steve Gibson
That's not right, it's 49 digits. Huh, isn't that interesting, huh.

2:05:13 - Leo Laporte
I'm wondering if I oh, I think I pasted the right thing in.

2:05:15 - Steve Gibson
One. Yeah, it starts off. Yeah, I mean I'm looking at it and it is exactly right. Well, this is the kind of weird thing.

2:05:21 - Leo Laporte
This isn't ChatGPT. I could try. Let me try. Well, go on with the show. I could spend a lot of time on this one. I'll do it on Chat.

2:05:31 - Steve Gibson
I counted the groups of three. Between commas there's 16 groups of three, so that's 48 plus the one in front is 49 digits. So that is the kind of thing that these things get wrong.

2:05:45 - Leo Laporte
Little weird things like that they're not math machines.

2:05:48 - Steve Gibson
They're generalizers. Okay, so I need your attention on this, leo, because you're going to love this. Okay, so let's explore because this is the output from the HMAC, the HOTPHMAC is these 160 pseudo-random bits ways that we might go about converting this humongous 160-bit, 49-decimal digit or 20-byte SHA1-based HMAC output into those six digits that we want our fancy authenticator to produce. Thinking of this as a very large and long binary number, let's first say that we wanted to extract digits only ranging from 0 to 7, which is to say, any one of 8 possible values right, 0 through 7, 8 values to shift the entire large number three bits to the right. In binary math, shifting a binary number to the right divides its value by two, and the bit that's shifted off the right end is the remainder of the division by two. So if we shift the large value three bits to the right, that divides it by eight, because it's divided by two three times, and the three bits that would be shifted off the right end would be the remainder of the division by eight. That would give us a binary number ranging from zero to 7. Those three bits give us a binary number ranging from 0 to 7, and, when converted to decimal, a single digit between 0 and 7. So by dividing the massive number by 8, we are able to extract a digit ranging from 0 to 7. And we could do this again and again, as many times as we need to extract as many digits from the large number as we need. But we do not live in an octal world, presumably because we do not have 8 fingers and toes. We have 10 fingers and toes. So we count in decimal, with a 10-digit alphabet ranging from 0 through 9. And it's a 10-digit alphabet that we need our TOTP and HOTP to produce. So here's the coolest thing Since our fingers and toes friendly authenticator wants to produce one-time passcodes containing all 10 digits ranging from 0 to 9, instead of dividing the very large number by 8, we divide it by 10. Dividing any large number by 10 will give us a remainder ranging from 0 to 9.

The solution is clean, simple and elegant. If it had been left to me to design the digit extraction algorithm for the HOTP algorithm, I would have done exactly that. I would have simply successively performed a very long division of that very large 160-bit number by 10, taking the remainder from each division, which would have resulted in an extremely uniformly distributed digit range from 0 to 9. Range from 0 to 9. And that simple long division could have been repeated as many times as needed to successively extract as many pseudo-randomly determined digits as needed.

And if we generalize this a bit, just for the sake of cool math and theoretical computer science. What's so cool about this approach is that it is wonderfully generic. If the size of one's alphabet happens to be exactly some power of two, then dividing any binary number by that is as simple as shifting the binary bits of that number to the right and grabbing the bits that fall off the end. They form the choice for the item extracted from the large number. But having a practical alphabet size that's exactly some, you know, exact power of two would mostly be coincidence. The usual case is that the size of the alphabet is whatever it is.

If we want to extract decimal digits, we divide by 10. If we wanted to extract evenly distributed English alphabetic characters, we could perform long division by 26. Then map the resulting remainder which would range from 0 to 25, to the letters of the alphabet A through Z. Or if we wanted both upper and lower case alphabetic characters, we'd divide by 52 to get a remainder that could be mapped to both lower and upper case alphabet. And if we wanted upper and lower case plus decimal digits, we'd divide by 62, and so on. This is exactly what I did with the design of the perfect paper passwords system which we talked about during Security. Now, episode 115, which Leo, you and I recorded on October 25th of 2007.

The perfect paper password system successively performs long division of a very long number by the size of the alphabet the user wishes to use. This generates successive division remainders of exactly the alphabet size which is used to enumerate successive items of the alphabet. So in the case of something like HOTP, this clean and simple approach of the long division of the entire 160-bit SHA-1 number by 10 would allow any number of decimal digits to be extracted from that very long value to satisfy the need for a maximum quality pseudo-random decimal number having any number of digits. Boy, that brings back some memories.

2:12:36 - Leo Laporte
Look at that, look at that, look at that. But you can read this whole thing that you're doing the same thing. You can read it all there.

2:12:42 - Steve Gibson
Yeah, yep, that's really that's super cool and that it just it's so slick yeah but I said that's what I would have done, uh-huh, if I'd been given the task.

2:12:58 - Leo Laporte
As I said, it's what I did do back in 2007.

2:13:02 - Steve Gibson
But the group who designed the HOTP algorithm? They didn't ask me and that's not what they chose to do two years earlier in 2005. Looking at what they chose to do makes me want to scratch my head. The only rationale I can come up with for what they designed the term being kind would be ad hoc was that it was good enough and that perhaps they didn't trust coders who would be implementing their standard to be able to divide a long binary number by 10.

2:13:48 - Leo Laporte
Is it computationally expensive?

2:13:50 - Steve Gibson
No, no, it's elegant and it's beautiful. I mean, and actually the code in Assembler which is, you know, is where I wrote, it is just wonderful. But you can do it in anything, because you're just shifting bytes along. So they went way out of their way to avoid that, oh dear Okay.

2:14:12 - Leo Laporte
Okay.

2:14:13 - Steve Gibson
So I wanted to first explain, as I just have, the cryptographically optimal way of solving this simple problem of computer science, so that everyone would have a reference point against which to judge what actually transpired. Transpired get a load of the universal hotp algorithm that we all wound up with, for better, for worse.

2:14:45 - Leo Laporte
And, leo, we will continue after our final break and that's a tease. Wow, wow, um you won't believe it if you did it when you do it your way, it's going to be completely uniform in the distribution. Right it's, it's. It's not going to favor any digit, it's just, it's random and it's going to be uniform in its distribution.

2:15:08 - Steve Gibson
Doing it your way what's so significant about my way and we'll we'll actually visit this explicitly later because we're going to look at how like, like, how bad their compromise makes things is that I'm always using all the bits right. That's important it well, if you want the cryptographically perfect solution, yeah, that's how you do it right.

2:15:36 - Leo Laporte
That's not what they don't throw out entropy. Oh boy did they. We come limping across home plate with barely enough entropy oh my god so, in other words, our correspondent was right to say, hey, something seems fishy well, we'll get to there too.

2:15:57 - Steve Gibson
We'll answer that question.

2:15:59 - Leo Laporte
Okay, this is good. I hope you're following along. I'm only kind of sort of following along, but I'm getting the general gist of it. I'm surprised that Advent of Code has not had this as a challenge. I think they actually have come to think of it to do your own hashing algorithm. Anyway, we will get to Steve's explanation in just a moment, but first a word from our sponsor, the nice folks at zscaler, the leader in cloud security.

You know, enterprises have spent so much money, billions of dollars on, on two very common forms of security firewallss, right to secure the perimeter, and VPNs, which is what you need to get through the firewall so that an employee on the outside can get into the inside. Right Works perfectly, doesn't it? No, it doesn't. In fact, breaches are rising like crazy 18% year-over-year increase last year in ransomware attacks, 18% and a record $75 million payout in 2024 18% year-over-year increase last year in ransomware attacks, 18% and a record $75 million payout in 2024. Although I'm thinking that's just the tip of the iceberg. Most people aren't reporting how much they spent to recover their data after a ransomware attack. I think $75 million is way low. If you listen to the show, you know it's a problem. These traditional security tools are not getting the job done. I mean, among other things, they expand your attack surface because they have public-facing IPs that can be banged on by bad actors, and now, with AI tools, in unique and powerful ways. Plus, these firewalls struggle to inspect outbound encrypted traffic at scale. Why is that important? Because that's how the bad guys, once they're inside, exfiltrate your private data, your emails, your customer lists, your customer information. They encrypt it and they send it out through the firewall, but the firewall can't catch it. Vps and firewalls also do nothing to protect you against lateral movement. They just assume you're in the network. Oh, I have had it. So once you're connected to the network, you're connected to the whole network. You can get everywhere. You can find anything. You can exfiltrate it. With encrypted traffic. The world's your oyster if you're a bad guy.

Hackers exploit traditional security infrastructure using AI to outpace your defenses. They're doing it fast. They're doing it better than ever. We know that you listen to the show. You know that it's time to rethink your security. You can't let these guys win. They're innovating faster than we are Exploiting your defenses. That's why you need Zscaler Zero Trust plus AI. It stops attackers by hiding your attack surface. Making apps and IPs invisible Can't attack something you can't see. It eliminates lateral movement. This is Zero Trust. It connects users only to specific apps, not the entire network, and it continuously verifies every request based on identity and context. Plus, it simplifies security management with AI-powered automation. When you are ingesting over half a trillion daily transactions, you've got to have AI to analyze them, find the threats. Half a trillion with with a T daily transactions, hackers cannot attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscalercom security, z-s-c-a-l-e-r or Zed. If you're in Canada or the UK, zscalercom security, you should check this out.

Zscalercom slash security. We thank him so much for supporting security now and the good work Steve is doing. Hey, one more thing before we get back to Steve and some number crunching, more number crunching. I would be greatly appreciative if you would go over to our website, twittv slash survey and fill in our survey. It should only take you a few minutes.

It's the one thing we do once a year to try to get to know our audience as a whole. We're not collecting information about you individually, but we'd like to know more about our audience, what they're interested in, what their occupations, are their ages. Like that for two reasons it helps us design programming that's better suited to you, but also helps us sell advertising, because advertisers, they always want to know all about you and we don't want to tell them anything about you. But we like to be able to say things like oh you know, 75 of our audience are it decision makers. That's useful, so fill that, if you will. It really helps us. You've got maybe a week more before we uh, take it offline. Twittv slash survey and thanks in advance. I appreciate it. Now get your propeller heads back on. It's time to get back to the math. This is a very propeller head show. I'm ready.

2:20:54 - Steve Gibson
Tell me what they actually did, okay so get a load of what the non-computer scientists who apparently-.

2:21:01 - Leo Laporte
Aren't they computer?

2:21:02 - Steve Gibson
scientists One would wish, but wait till you hear this. So, once again, here's what we actually got. This is the definition in the RFC of the HOTP algorithm from 2005. Once again, of course, we start with the output of the SHA-1 based HMAC, but this time, rather than viewing it as a large and I don't know, I guess apparently intimidating 160-bit binary number, we view it as an array of 28-bit bytes. The bytes of this array would be numbered 0 through 19.

The officially standardized HOTP algorithm instructs us to take the last byte of the array, byte number 19, and mask off or ignore the upper 4 bits of that last 8-bit byte. Thus we'll be paying attention to only the lower four bits. We're throwing out half the entropy right there, right there. These four bits will thus have a binary value ranging from 0 to 15. So we use that 0 to 15 value as an offset into the entire 20 byte array where, starting at, at, starting at the, at, whatever offset we have, we then take four successive bytes to get 32 bits. So, for example, if, after masking off the upper four bits of the last byte and retaining only the lower four bits, we wound up with a zero, we would obtain the four-byte 32-bit value from bytes 0, 1, 2, and 3 of the array Okay be my word for the day results in us having extracted 32 bits somewhere from within the first 19 bytes of the 20-byte SHA-1 hash value, where the lowest four bits determine where, within those 19 bytes, we grab 32 bits.

2:23:41 - Leo Laporte
Okay, but those are still random bits, right.

2:23:45 - Steve Gibson
Oh yeah, it's true. Okay, now next, believe it or not? The implementer is then instructed to set the most significant bit of those 32 bits to zero. This creates a 32-bit value which, if it were to be treated as a signed integer, would be guaranteed to be positive, because signed integers use their high bit as their sign, where that high bit set to one means that the number is negative.

2:24:15 - Leo Laporte
So now it's a 31-bit number.

2:24:17 - Steve Gibson
Correct.

2:24:18 - Leo Laporte
One of those bits.

2:24:19 - Steve Gibson
Yes, exactly. We have what is essentially a very tame 31-bit positive number ranging between 0 and 2,147,483,648, which fits handily into a CPU's 32-bit register. That's easy to say. Algorithm next instructs us to divide that 32-bit guaranteed-to-be-positive integer by 1 million, because the remainder of that division, when converted into a decimal number, will give us all possible six-digit numbers from 000000 to 999999. And they're still randomly distributed in that range. Yes, eh0. 0 0. 0 0 0. 2, 9, 9, 9, 9, 9, 9.

2:25:22 - Leo Laporte
And they're still randomly distributed in that range. Yes, oh, okay.

2:25:28 - Steve Gibson
Watch what happens, okay, so does it work? Yes, and what it? Sacrifices in elegance, which is to say pretty much everything. Yeah, it doubtless gains in ease of proper implementation using any high-level language. I'm sure anyone could write it in BASIC and obtain the correct answer.

2:25:51 - Leo Laporte
Okay so that's important.

2:25:53 - Steve Gibson
It would be. Yes, it is. It would be very difficult to screw that up. To screw that up, and since interoperability among all HOTP generators all arriving at the same correct six digits is paramount, I guess I can see why the designers chose the kindergarten design that they did. Now you might ask kindergarten really Isn't that being too critical? Garden, really isn't that being too critical? Let's look at it from a cryptographic standpoint. The algorithm itself is really quite crappy, because very little of the sha1 hashes entropy winds up being used. Right the last, the last bytes, top four bits, as you commented, leo, are completely ignored and the lower four bits select just four out of the remaining 19 bytes, completely ignoring all of the other 15, which is 120 bits ignored out of the total 160. Then, adding insult to injury, of the precious 32 bits that were selected, one of those is discarded because whomever is implementing this might not know how to perform unsigned division.

2:27:19 - Leo Laporte
So we're going to take that off the table.

2:27:22 - Steve Gibson
So the dividend on top is forced to be positive, just to be sure. So we wind up using the entropy contained within just 31 bits of the HMAC function. Now, by comparison, my approach of successively taking the entire 160-bit hash output, dividing it by 10 and using the remainder takes advantage of every one, as we noted, of the available bits of the HMAC output for the determination of each successive decimal digit. But I will be the first to concede that interoperability of implementation matters here far more than cryptographic perfection. Dividing the extracted 31-bit value by 1 million to obtain a value ranging from 0 to 999999 will absolutely provide a completely useful and a highly pseudo random result.

2:28:27 - Leo Laporte
Yeah, I mean at this point, the only flaw is you over-generated entropy by using HMAC. You made too much entropy.

2:28:36 - Steve Gibson
You could definitely look at it that way. Yes, you generated unnecessary entropy, and boy have we just thrown it out.

2:28:45 - Leo Laporte
Okay.

2:28:46 - Steve Gibson
One of the features of a high quality cryptographic hash function such as SHA1, is that and this is to your point, leo every single bit of its result has an exactly even 50-50 chance of being a 0 or a 1.

So taking any sufficiently large set of them and dividing them by 1 million will give us a good result. However, if our priority, as it appears to be, is to create a super simple, easy to implement and highly interoperable solution, then why all the low four bit nibble nonsense to select the set of four bytes to use? As we all know, any four would work. Yes, the definition of any cryptographically strong hash function, which lies at the heart of the HMAC, is that every single one of its many bits are treated equally. They each have that algorithmically guaranteed 50-50 chance of being either a 0 or a 1. So if we're going to go the route of using a 32-bit positive integer as our dividend, it absolutely and truly doesn't matter at all which 31 bits out of the SHA-1's hash is 160 bits bits out of the SHA-1's hashes 160 bits we select to be the dividend for our division by 1 million. In fact, it cannot matter, or we don't have a truly strong cryptographic hash function to begin with.

2:30:36 - Leo Laporte
That makes sense. I mean we do have to come up with a uh, a universal way of doing it.

2:30:42 - Steve Gibson
So we all do it the same way well, this means that an exactly equivalently strong hotp algorithm could have told us to just take the first four bites.

2:30:57 - Leo Laporte
You don't have to pick randomly in that big set. Just take the first four.

2:31:01 - Steve Gibson
Makes no difference at all.

2:31:03 - Leo Laporte
That's a good point.

2:31:04 - Steve Gibson
Did this make them feel better? I mean, I worry, because who were these people?

2:31:10 - Leo Laporte
Either they know what they're doing or they don't. Why did they do all the rigmarole of taking four bits off and then indexing into the big number and finding it's nonsense? It is nonsense. Take the first four.

2:31:26 - Steve Gibson
It is nonsense.

2:31:28 - Leo Laporte
Oh, that's hysterical, which makes you worry, as you should, that it was a lot of hand-waving.

2:31:37 - Steve Gibson
Did someone's mom suggest this? I mean not, not against anything, not just saying they get better.

2:31:43 - Leo Laporte
Mom might be a mathematician.

2:31:45 - Steve Gibson
There are a lot of cryptographically savvy moms out there. But boy, that's a really interesting point.

2:31:51 - Leo Laporte
It's nonsense, okay, so it's like swinging a chicken around three times before you pick the number no, that was in the appendix.

2:32:00 - Steve Gibson
Oh my God, that's hysterical.

2:32:07 - Leo Laporte
It's a little worrisome, right.

2:32:09 - Steve Gibson
Why did the designers of the HOTP algorithm that we're now all standardized on not understand how hash-based HMAC functions operate?

2:32:20 - Leo Laporte
It doesn't matter what four bytes you select.

2:32:25 - Steve Gibson
Not at all.

2:32:26 - Leo Laporte
They're all random. It cannot matter, they're all equally random.

2:32:31 - Steve Gibson
Yes, it cannot matter, Wow, okay, so the only additional observation I'll make is that it is only now here's the really really. You thought the propeller head was spinning fast, already it's. It's only when the dividend on top is an exact, even multiple of the divisor on the bottom that we obtain a truly evenly distributed remainder. Whoops, and the corollary to that is that the larger the dividend is than its divisor, the more evenly distributed are the values of the remainder. More than anything else, this is why I prefer my approach, because it uses the largest possible value, meaning the entire 160 bits, as the dividend.

2:33:33 - Leo Laporte
And that is an even multiple.

2:33:35 - Steve Gibson
Well, no, it's still not an even multiple, but boy is it big. It's big, okay. The bigger it is than the divisor, the better, okay. So let's look at an example. Okay, we'll use a super simple example to clarify the point. Say that we want to extract a decimal digit from a four-bit source. We know that we can do that by dividing the source dividend by 10 to extract the decimal digit. So now let's look at the result we obtain from all 16 of the source's possible values. Zero divided by 10 gives us a 0 with a remainder of 0. 1 divided by 10 results in0 with a remainder of 1. 2 divided by 10 is 0 with a remainder of 2, and so on upward, where 9 divided by 10 is 0 with a remainder of 9. Next, 10 divided by 10 will be one with a remainder of zero. 11 divided by 10 will be one with a remainder of one, and so on up to 15, the maximum value that four bits can have. Dividing 15 by 10 gives us one with a remainder of five.

2:35:00 - Leo Laporte
And we only care about the remainders here right, correct.

2:35:03 - Steve Gibson
But look what happened. We were asking our 4-bit source to give us 10 possible output values, 0 through 9. But because 4 bits has 16 values, it cannot be evenly mapped into 10 results. So, taking the remainder of the divisions by all possible source values, we wind up with two instances of remainders of 0, 1, 2, 3, four and five, but only single instances of remainders six, seven, eight and nine. In other words, we do not wind up with a perfectly even distribution of all possible output values. So that's why you get repeats.

And since that total number of possible input values, 2.147 billion, is not evenly divisible by 1 million, because it didn't end in six zeros, it's got to end in six zeros. If it's divisible by a million, six decimal digit values produced by the industry standard HOTP algorithm will occur with exactly the same frequency. Now, in practical terms, am I splitting hairs? Definitely, it absolutely doesn't matter at all. Doesn't matter at all. It won't result in the final decimal output, which will change again in 30 seconds anyway, being usefully any more guessable the case of generating 10 values from only because 16 was so very close to 10. By comparison, hotp's dividend is $2.147 billion, which is much, much larger than 1 million. In fact, it's more than 2,147 times larger than 1 million.

But that said, computer science is computer science and all of this makes for intriguing questions. If nothing else, these questions must be examined, if only to be able to judge their size and impact and to make certain that their effects will be negligible. And impact, and to make certain that their effects will be negligible. The only thing it means is that the exact number between 0 and 999999, some of them in a huge universe will occur ever so slightly less often, and it's like three or four decimal digits of percentage. You know, one of them is 0.99999 and the other one is 1.00001. So just a tiny bias in the number of times. If you, if you took, if you just took readings forever and ever and ever. But again, for this application absolutely makes no difference, because it changes again in 30 seconds.

2:38:52 - Leo Laporte
And, as you pointed out, HMAC is a pseudo-random number. It's pseudo-random hash right. So there are probably biases built into HMAC too. No, that's the beauty of.

2:39:01 - Steve Gibson
SHA-1. It's pseudo random hash right.

2:39:02 - Leo Laporte
So there are probably biases built into HMAC too. No, that's the beauty of SHA-1. It's truly random.

2:39:05 - Steve Gibson
It has never shown any bias Interesting.

2:39:07 - Leo Laporte
Not at all.

2:39:08 - Steve Gibson
So mixing things in there I mean, they really did the work there, that's cool will only ever get long. Division of all possible available bits of entropy not because it necessarily matters to you, but because it's the most correct solution, which is what makes it matter to me, and you're the only implementer, yes, so you know you can do it correctly and there's no onus on you to make sure that a million other people could do it correctly, and I do not disagree, that making a simple, maximally easy implementation matters.

And if that was their goal, just take the first four bites you suckers.

2:39:57 - Leo Laporte
They didn't make it the simplest. That's the irony. They could have made it much simpler.

2:40:01 - Steve Gibson
They mixed in some mumbo jumbo. That cannot have any benefit.

2:40:06 - Leo Laporte
Just take the first four bites, that's all you need.

2:40:10 - Steve Gibson
It cannot make a difference.

2:40:11 - Leo Laporte
That's pretty funny, but I guess maybe it made them feel better.

2:40:15 - Steve Gibson
Maybe it's spookier or something, I don't know that is really worrisome.

2:40:20 - Leo Laporte
I really do wonder why they did know. That is really worrisome. I really do wonder why they did that. That is very strange. It is a concern.

2:40:25 - Steve Gibson
Yeah, Okay. So now let's return all the way back to Max's original question of any perceivable bias in the resulting numbers that might cause more identical digits than we would expect Knowing what we know now. Is that possible? No, oh, it is not possible. Okay, Because we've examined the algorithm At its heart. It takes a sufficiently large, entirely pseudo-random binary value, from which we take one of 2.147 billion values and divide that number by 1 million. The dividend of the division, while not an even multiple of the divisor, is large enough than the divisor that the remainder of that division the number varying between 0 and 999999, will be an extremely evenly distributed value within that range. And that in turn means that when converted into a decimal number, the values individual constituent digits will also be extremely evenly distributed, without any possible interaction or relationship to one another. Now I should say I too have observed the same illusion that Max and his mom have and that you did before the show, leo.

But I'm certain that this must be classic observational bias, where we tend to notice much less all the times when the digits do not form any sort of pattern and tend to notice more those times when they do pattern and tend to notice more those times when they do. But that aside, it is provable, and we just proved it, that there cannot be any non-uniform pattern, and we know that all authenticators must be using the same algorithm which we've just examined, otherwise they would not be producing the expected result. Now I asked ChatGPT I said quote is there a term for the tendency of we lowly humans to perceive a pattern where none actually exists, unquote? And it replied yes. The general term for this is apophenia, the tendency to perceive meaningful connections or patterns between unrelated things.

A more specific example of this phenomenon, limited primarily to visual or auditory stimuli, like seeing faces in clouds or hearing hidden messages in music, is called periodolia. Yes, I knew that. One thing, leo, I am quite certain of is that there is definitely a pattern to these podcasts. Is that there is definitely a pattern to these podcasts. They routinely appear every Tuesday, come rain or shine, so everyone should expect another one next week.

2:43:53 - Leo Laporte
And you might even see a face in these podcasts if you squint your eyes a little tiny bit. That is fascinating. Now, of course, I'm looking at my authenticator and there are 33 different codes in here and I've already found two that are not repeating. I think it's probably about 15% if you really and you validated that it should be about 15%, because these six digits are truly random, yeah.

2:44:16 - Steve Gibson
Even if they're calculated in a completely absurd way. Oh God I love it that.

2:44:23 - Leo Laporte
And now you take the offs, subtract the nibble, take the offset of the lower nibble and you go into the thing and you get those four bytes and you just take any four bytes, it doesn't matter.

2:44:35 - Steve Gibson
Take the first four bytes Cannot matter and it's like the guy who designed his own crypto algorithm. Oh, this scrambles the bits up so good they're never going to unscramble them.

2:44:47 - Leo Laporte
It's a fundamental misunderstanding of how SHA-1 works, yes, and of the generated value, yes. Which is scary if somebody's writing code that uses SHA-1. Yes, but fortunately they screwed it up in the right way, not the wrong way.

2:45:09 - Steve Gibson
Fortunately, because it's all pseudo-random, they couldn't unscrew it up.

2:45:14 - Leo Laporte
They couldn't really.

2:45:15 - Steve Gibson
I mean, there's no way to do something that was like really bad. It's just no better.

2:45:22 - Leo Laporte
Take the hash, take the first four bytes, you're done. Would have been a lot easier. Yeah, that's hysterical, but if you really care, you do it Steve's way and you do some division and blah, blah, blah. Take the remainder and you divide it some more. Take the remainder, divide it some more. You're pretty funny.

Perfect Paper Passwords is a perfect example of Steve's monomania. My friends, to make sure that you are secure, go to GRCcom. It's there still. Here we are 17 years later. It's still there, along with a lot of other great stuff. It's all fascinating.

There is, of course, the bread and butter, the thing that Steve did not mention this week Spinrite, the world's best mass storage, maintenance, recovery and performance-enhancing utility. And I say mass storage because it's not just spinning drives, it's SSDs as well. If you've got mass storage and you don't have spin right, what are you thinking? Go there right now. 6.1 is the current version. Get spin right. Uh, there will be something else coming soon your DNS benchmark, the pro version. I'm looking forward to that. Uh, you'll also find the podcast there.

Steve has two versions that are unique. He, of course, has the canonical, shall we say, 64-bit audio version that we have that too. That's everywhere, but he makes for some reason. He runs an ffmpeg script and makes a 16 kilobit version of the same thing. It it sounds like Thomas Edison on a cylinder. But it has one main virtue it's small, and that means if you have a limited bandwidth you can get security. Now, a tiny little version of it. There's also a text version, a very nice. It takes a few days, but Elaine Ferris does a wonderful transcription of these.

That Steve pays for Not an AI, but an actual human. That Steve pays for Not an AI, but an actual human, although I do want to name my AI, elaine. I think that's a good idea. We can't replace her, but we can honor her. How about that? Those are both at his website. We have 64-kilobit audio. At our website, twittv slash sn.

We also have video, which Steve doesn't have because Steve thinks no one wants to see. Everybody can see the face in the waveforms, so they don't need the video. Right, you don't need video, but we do offer video. If you want to see Steve's mustache at twittv slash sn, when you're there you'll also see a link to the YouTube channel. That is a great thing to know about, uh, because if you want to share a clip. If you want to like fry your best friend's brain, you could send this last little thing here and make them listen to it, something, something like that. That youtube makes that very easy to clip out stuff. And there's a nice thing if you do that, it kind of promotes the show and helps spread the word. So we really want you to do that. But the best way to get the show and helps spread the word so we really want you to do that. But the best way to get the show subscribe in your favorite podcast player to either audio or video. Just search for Security. Now, we've been around for a long time now. Every podcast client knows about us and that way you'll get it automatically every single week.

You can watch us. Do it live if you've got to get the absolute freshest version. As Steve said, we do it every Tuesday about 1.30 to 2 pm Pacific. It's right after MacBreak Weekly. That's 5 pm Eastern, 2200 UTC. The live streams are, of course, discord for our club members, but there's also Twitch, twit, tiktok for the time being anyway Xcom, facebook, linkedin, kick eight different ways you can watch us live and I see the chat from all of them. So it's great to see you all, uh, thank you for being here, thank you for watching. A special thanks to our club members for making this show possible and the biggest thanks of all to this guy right here, mr steve gibson, who continues to blow our minds every Tuesday.

2:49:21 - Steve Gibson
Thank you, Steve. Thank you, my friend. I'll see you next week for some more Security Now.