GIBSON RESEARCH CORPORATION		https://www.GRC.com/

SERIES:		Security Now!
EPISODE:	#1054
DATE:		December 2, 2025
TITLE:		Bots in the Belfry
HOSTS:	Steve Gibson & Leo Laporte
SOURCE:	https://media.grc.com/sn/sn-1054.mp3
ARCHIVE:	https://www.grc.com/securitynow.htm

DESCRIPTION:  Scattered Lapsus$ Hunters strikes (Salesforce) again.  Cisco actually (no kidding) sees the light.  Next week, Australia bans all underage social media.  The EU Parliament moves to replace U.S. computer tech.  When to use Passwords, Passkeys, or YubiKeys.  Do unpowered SSDs lose their data?  How about a "Joy of Coding" podcast?  A Bitwarden Passkeys integration glitch.  XSLT is sneaky; it's where you don't expect it.  We know where last week's picture came from.  The long-awaited return of a new Stargate series.  And a simple test to check for any LAN bot infection.

SHOW TEASE:  It's time for Security Now!.  Steve Gibson is here with some good news for Cisco users.  What's going to happen in Australia next week?  Steve's a little concerned.  When to use Passwords; when to use Passkeys; when to use hardware keys?  The return of "Stargate."  And a simple test to check your network for bot infections.  All that and more coming up next on Security Now!.

LEO LAPORTE:  This is Security Now! with Steve Gibson, Episode 1054, recorded Tuesday, December 2nd, 2025:  Bots in the Belfry.

It's time for Security Now!, the show where we cover your security and privacy and all that important stuff, with the man of the hour, the man of every Tuesday's hour, Mr. Steve Gibson.  Hi, Steve.

STEVE GIBSON:  The man who spent two days getting this podcast ready for our listeners.

LEO:  Wow.  You work really hard.  I don't know if people realize, they probably just assume, oh, you just show up and read some stuff and talk.  No, you work really hard all week to get this together.

STEVE:  Well, and the amount of effort varies.  Sometimes there's just a lot of material that I can't provide any better than the original source.  Or I want to be very careful to exactly quote the original source, so I'm not doing a lot of writing.  This one was a writing-heavy podcast.  I had a lot of fun.  It is also listener feedback heavy.

LEO:  Oh, good.

STEVE:  I read every single message that had been sent since the previous week's mailing.  I often replied to a bunch.  But a lot of them are here in the podcast because they were share-worthy. 

LEO:  Nice.

STEVE:  So we're going to do that.  And in fact the title of today's podcast, well, today's podcast is titled "Bots in the Belfry."

LEO:  I like it.

STEVE:  Comes from the GreyNoise Labs recent creation of a very interesting, and I would argue compelling new service, to allow anyone, all of our listeners certainly, to quickly check to make sure that their IP has never been seen evidencing any bot activity.  So I think it's grc.sc/botcheck is the URL I gave it.

LEO:  And don't all go at once, everybody.

STEVE:  I used GRC's URL shortener so that I can keep it current and also make it easy to find.  Anyway, so we're going to end by talking about that very cool service, and also why we get an unexpected, but nice benefit from NAT routing in this instance.  We'll go over all that.  But we're going to talk about Scattered Lapsus$ Hunters, that new amalgam group, once again striking Salesforce.  Oh, and Leo, Christmas came early for Steve.  Cisco actually, no kidding, has seen the light.

LEO:  Hallelujah.

STEVE:  No one will believe how clearly the guy in charge of what has to change has articulated what is going to change.

LEO:  Good.

STEVE:  I'm tempted to say that somebody's been listening to this podcast because, you know, I've taken them to task a few times.  And I couldn't have said it better than they have.  So we'll look at that.  Oh, and bizarrely, next week Australia, the country - I meant to look up what their population is.  I know that we're around 330 million in the U.S.  I mean, they're a large landmass, but a bunch of it is kangaroos.  So I'm not sure how many people they actually have there.  I'm curious because the entire country is banning all social media.

LEO:  I know, December 11th.

STEVE:  Yeah, on the 10th, I think it is.

LEO:  The 10th, yeah.

STEVE:  But it's like, what?  Like, what?  It's like they took the wrong lesson from Mississippi and said, yeah, let's do that nationwide.  Anyway, we'll talk about that.

LEO:  It's only 26 million people, by the way.  It's not the hugest.

STEVE:  Okay.  There are a lot of kangaroos.  So, yeah.  The EU Parliament is moving to replace all U.S. computer technology.  An interesting bit of feedback-driven response about when to use passwords, Passkeys, or YubiKeys.  XDA recently posted some surprise on some people's part, saying that unpowered SSDs lose their data.  Well, we've known that for a long time.  We talked about it a long time ago.  But it turns out it's not actually the unpoweredness of them, apparently.  We'll touch on that.  We have a - oh, I wanted to respond to a listener's suggestion of a Joy of Coding podcast event that we should talk about. 

LEO:  Ooh, okay.

STEVE:  You and I touched on it, and so I wanted to come back, circle back to that.  Also Bitwarden had a brief Passkeys integration glitch.  Also XSLT turns out to be a little sneakier than we thought.  That's that technology that's been around since the dawn, which is going to be sunset.  And also how it's not, like it comes up in places where you don't expect it.  We now know exactly where last week's Picture of the Week was taken.  One of our listeners provided the information.  So we will touch on that.

We've got a long-awaited, in many quarters, return of "Stargate" in a new series that was just announced.  And then we're going to touch on a very simple check to see whether anyone's residential SOHO, technically you could do enterprise, but enterprise probably has lots of public IPs, whether an IP that you're checking in from has ever seen any bot activity.  So I think, yeah, I think a fun podcast for this first beginning of December.

LEO:  There are 28 million people in Australia, 35 million kangaroos.

STEVE:  Ah.

LEO:  According to the Australian government.

STEVE:  I was right.  Who knew?

LEO:  So you were right.

STEVE:  Thought I was kidding.  Now, the 'roos won't care too much about the loss of access to social media.  But the 28 million people who now have to prove that they are...

LEO:  Is it all of them?  Or just people under - it's people under 16.

STEVE:  But remember you have to prove you are over 16.

LEO:  Oh, good point.

STEVE:  Which means everybody.

LEO:  Yeah.

STEVE:  That's the catch.

LEO:  How's that going to work?

STEVE:  It's insane.

LEO:  Well, this is what happens is these legislators who don't really understand what they're talking about make these laws that are not in fact enforceable.

STEVE:  The only flipside is that we know how reluctant technology is to move forward.

LEO:  Right.

STEVE:  So were it not for an insanely pressing need, eh, well, we're going to have another meeting, and then we're going to have some drinks.  And, you know, it's like the W3C, they had a - their most recent meeting was a meeting about the meetings.  We're going to have a meeting about our future meetings.

LEO:  What's the shape of the meeting table?

STEVE:  Exactly.

LEO:  That's the thing we really need.

STEVE:  What would we like to accomplish by the end of the 12th meeting?  It's like, guys, get on with it.  So I think that, like, having this actually be a very pregnant problem is probably a good thing.

LEO:  Yeah.  It's the shortest path to finding a solution, I guess.

STEVE:  And it gives Stina more leverage because she's been on this for a while now.  So that's good.

LEO:  Yes, of YubiKey fame.

STEVE:  I wouldn't want to get in her way.  Unh-unh.

LEO:  We will have more, in fact the Picture of the Week is just around the corner.  You're watching Security Now! with Steve Gibson.  All right.  Picture of the Week time, Mr. Gibson.

STEVE:  Okay.  So this is the return of desire paths.

LEO:  Okay.

STEVE:  We have a 12-frame cartoon that tells a story, essentially.  Now, the crux of the problem, as is always the case with these desire paths, is that the path that whoever it is who paved the path originally laid down does not correspond with where people want to go.  So it's like, it's a bad path; right?  I mean, a path presumes that it takes you where you want to go.  No.  So here we've got a - in the first frame we see a nice green lawn and a path going up to the sidewalk in the upper left.  The problem is nobody wants to go to the sidewalk on the upper left.  They want to go to the street corner, which we can see over on the upper right, where there's a bit of a crosswalk.

So inevitably, what happens is that as people are walking toward the end of the path that meets the sidewalk, they're looking more and more off to the right, which is like, well, I want to be going over there.  Why am I going over this way?  And so if you think about it, Leo, when you're starting off on the path at the beginning, where the path goes and where you want to go, they're pretty close together, from your perspective.  But as you walk along the path, where you're wanting to go begins to diverge.  It veers off to the right to at some point you're like not quite at right angles, but it's like, wait a minute.  I want to be over there.

So there's nothing preventing somebody from just walking across the grass, and so they do.  And inevitably you end up with a worn dirt trail through what would otherwise be nice grass because everybody wants to go to the corner for the crosswalk.  So after that has established itself, those in charge of this park say, well, we can't have this.  

LEO:  The authorities.

STEVE:  Yes.  So, and this brings us to frame three, where a park bench has been stuck on the place in the path where the foot traffic diverges to go where people actually want to go.

LEO:  That'll show them.

STEVE:  That's right.  And so we see the grass beginning to regrow a little bit in the wake of the establishment of this park bench.  It doesn't last long.  Fourth frame shows that people just said, oh, well, I'm going to go off the path sooner.  I'm going to go around the park bench and get to where I actually want to go, the corner with the crosswalk.

LEO:  I'll show you.

STEVE:  That's right.  And so somebody comes back and looks at this situation now and goes, well, we can't have that.  And so they stick a permanent trash can installation to this side of the park bench, where people have decided they're just going to take off early to get over to the corner they want to go.  So inevitably people are blocked.  Now, the trash can is far enough down path that people aren't getting anxious about heading to the corner by that point.  But by the time they get past the trash can and the park bench, they're like, I'm going in the wrong direction.  So sure enough, they start cutting across the grass after the park bench this time.  And so that brings us halfway through this to the sixth frame, where we've worn another dirt trail through this grass.  So the authorities finally say, okay, look, we're going to deal with this once and for all. 

LEO:  A hedge.  We'll put in a hedge.

STEVE:  We're putting a hedge.  We're going to just hedge our bets here.  So we've got a long linear hedge which is meant to say you have no choice.  You disobeyed the park bench, you disobeyed the trash can, you went around it, so now we have a hedge.  Unfortunately, hedges are not bulletproof.  I'm sure we've all seen people walking through hedges.  So we have the next frame showing that the hedge has become a bit damaged.  And in the following frame, well, the hedge has just given up.  It's basically been bisected into two hedges with another worn dirt trail running between it, going to where people actually want to go.  So finally the message gets through to management here.  It's like, okay, fine.  We're going to give you a paved trail to where you're telling us you want to go.

So we finally, in the tenth frame, the path comes up, it continues to go where no one wants to go, to the sidewalk on the street where nothing is happening.  But it also formally forks and veers off to the corner.  Everything is good for a while.  We get 10 and frame 11 look the same.  Everybody seems happy with that.  Oops.  But no.  Turns out the new trail doesn't actually go exactly where people want to go.  So we have another dirt path branching from the updated path, taking us to the crosswalk.  So...

LEO:  Oh lord.  I love that.  That's hysterical.

STEVE:  Yes, people are gonna do.

LEO:  People gonna do what people do.

STEVE:  Okay.  So Salesforce's name has been dragged back into the news again due to another of their customers - or I guess API affiliates is probably the best way to explain it.  Well, I'll explain all of how that works here in a second - whose security is not up to snuff.  Not Salesforce's, but the affiliates.  I'm sure Salesforce is very unhappy to have their name dragged back into the news.  So almost in response to their, like, well, this is not our fault, they posted a very limited, stiff acknowledgement.  It was under the heading "Security Advisory" - got to love this - "Unusual Activity Related to Gainsight Applications."  Gainsight being these apps that are causing the trouble.  So, yeah, unusual activity; right.  As in more than 200 customers had their Salesforce-stored data compromised.

Anyway, their terse posting reads:  "Salesforce has identified unusual activity involving Gainsight-published applications connected to Salesforce, which are installed and managed directly by customers.  Our investigation indicates this activity may have enabled" - may, right, we know how to read "may have enabled," may have for 200 customers who everyone knows - "unauthorized access to certain customers' Salesforce data through the app's connection.  Upon detecting the activity, Salesforce revoked all active access and refresh tokens associated with Gainsight-published applications connected to Salesforce and temporarily removed those applications from the AppExchange while our investigation continues.

"There is no indication that this issue resulted from any vulnerability in the Salesforce platform."  Eh.  We'll be coming back to that and giving that a little more attention in a minute.  "The activity appears to be related to the app's external connection to Salesforce."  So, right, blame the messenger.  "We have notified known affected customers directly and will continue to provide updates."

Now, all of the available evidence today supports everything technically that Salesforce has said, but TechCrunch provides a much more fulsome account, thanks to their reporting of Google's Mandiant security group, and also TIG, the Threat Intelligence Group.  TechCrunch's attention-getting headline was "Google says hackers stole data from 200 companies following Gainsight breach."  TechCrunch wrote:  "Google has confirmed that hackers have stolen the Salesforce-stored data of more than 200 companies in a large-scale supply chain hack."  Now, that's not the impression that you would get from reading Salesforce's, you know, sort of compulsory admission.

TechCrunch said:  "On Thursday, Salesforce disclosed a breach of 'certain customers' Salesforce data'"  without naming affected companies  "that was stolen via apps published by Gainsight, which provides a customer support platform to other companies."  So that's an important datum.  Remember, so this is Gainsight has apps which provide a customer support platform to the users of those apps.  "In a statement, Austin Larsen, the principal threat analyst of Google's Threat Intelligence Group (TIG), said that the company 'is aware of more than 200 potentially affected Salesforce instances.'

"After Salesforce announced the breach, the notorious and somewhat nebulous hacking group known as Scattered Lapsus$ Hunters, which includes the ShinyHunters gang, claimed responsibility for the hacks in a Telegram channel, which TechCrunch has seen.  The hacking group claimed responsibility for hacks" - now, here are a few of the 200 - "Atlassian, CrowdStrike, Docusign, F5, GitLab, LinkedIn, Malwarebytes, SonicWall, Thomson Reuters, and Verizon."  So not little people we've never heard of before.  These are not obscure entities.  TechCrunch said Google would not comment on specific victims, as well they shouldn't.

So TechCrunch did some more digging, writing:  "CrowdStrike's spokesperson Kevin Benacci told TechCrunch in a statement that the company is 'not affected by the Gainsight issue, and all customer data remains secure.'"  We'll see how that goes.  "CrowdStrike confirmed to TechCrunch" - oh, and this is a different story - "that it had terminated the employment of a 'suspicious insider' for allegedly passing information to hackers.  TechCrunch reached out to all the companies mentioned by Scattered Lapsus$ Hunters."  So Tech Crunch was going to go, you know, find out who would comment after Scattered Lapsus$ Hunters said, you know, we've got data on the following companies.

"Verizon spokesperson Kevin Israel said in a statement that 'Verizon is aware of the unsubstantiated claim by the threat actor,' without providing any evidence for the claim.  Malwarebytes spokesperson Ashley Stewart told TechCrunch that the company's security team is 'aware' of the Gainsight and Salesforce issues and 'actively investigating the matter.'  A spokesperson for Thomson Reuters said the company is 'actively investigating.'

"Michael Adams, the chief information security officer at Docusign, told TechCrunch in a statement that 'following a comprehensive log analysis and internal investigation, we have no indication of Docusign data compromise at this time.'  However, Adams said that, 'out of an abundance of caution, we have taken a number of measures including terminating all Gainsight integrations and containing related data flows.'"  And I'll just note that, because this is a breach of Gainsight, which is aimed at the Salesforce API, it might well be that there's no logging happening at the breached companies or in the breached companies' networks, which is not to say that their data stored at Salesforce did not leak.

So this all feels like, you know, like TechCrunch is asking right on the leading edge of investigations, and it's reasonable that this will take some time.  And also that they might be asking the wrong question because the companies are, oh, no, our networks are just fine.  Well, yes.  And that's - it still could be the case that your customer data was leaked from Salesforce.  So again, kind of a different question.

TechCrunch said:  "Hackers with the ShinyHunters group told TechCrunch in an online chat that they gained access to Gainsight thanks to their previous hacking campaign that targeted customers of Salesloft, which provides an AI and chatbot-powered marketing platform called Drift."  Remember we've talked about that.  That's an annoying thing that comes up on the lower right-hand side of your screen and says, "Hi.  Would you like to talk to me about support?"  And of course it's completely useless, but hey.  It pretends to be support.

"In that earlier case, the hackers stole Drift authentication tokens from those customers, allowing the hackers to break into their linked Salesforce instances and download the contents of their Salesforce stored data.  So the ShinyHunters group are saying that they got into in some fashion Gainsight, like tokens weren't rotated or refreshed, or maybe it was a different, you know, they may have gotten in and then made some lateral moves in order to maintain a grip.  That's what they're claiming.

"At the time, Gainsight confirmed it was among the victims of that hacking campaign.  So this begins to feel substantiated.  A spokesperson for the ShinyHunters group told TechCrunch 'Gainsight was a customer of Salesloft Drift.  They were affected and therefore compromised entirely by us.'"  That's ShinyHunters.  "Salesforce spokesperson Nicole Aranda told TechCrunch that 'as a matter of policy, Salesforce does not comment on specific customer issues.'  Gainsight did not respond themselves to TechCrunch's requests for comment.  On Thursday, Salesforce said there is 'no indication that this issue resulted from any vulnerability in the Salesforce platform."  And again, as I said, very likely true.  And TechCrunch said that effectively distanced them from its customers' data breaches.

"Gainsight has been publishing updates," they wrote, "about the incident on its incident page.  On Friday, the company said that it is now working with Google's incident response unit Mandiant to help investigate the breach, that the incident in question 'originated from the applications' external connection  not from any issue or vulnerability within the Salesforce platform,' and that 'a forensic analysis is continuing as part of a comprehensive and independent review.'

"'Salesforce has revoked active access tokens for Gainsight-connected apps as a precautionary measure while their investigation into unusual activity continues,' according to Gainsight's own incident page" - so that matches what Salesforce said.  And they also said that Salesforce is notifying affected customers whose data was stolen.

"In its Telegram channel, Scattered Lapsus$ Hunters said it plans to launch a dedicated website to extort the victims of its latest campaign by next week.  This is the group's modus operandi," writes TechCrunch.  "In October, the hackers also published a similar extortion website after stealing the victims' Salesforce data in the Salesloft incident."

And finally, TechCrunch finished their piece, writing:  "The Scattered Lapsus$ Hunters is a collective of English-speaking hackers made up of several cybercriminal gangs, including ShinyHunters, Scattered Spider, and Lapsus$, whose members use social engineering tactics to trick employees into granting the hackers access to their systems or databases.  In the last few years, these groups have claimed several high-profile victims, such as MGM Resorts, Coinbase, DoorDash, and more."

Okay.  So I wanted to share this story, not only because it's certainly important to those companies who are doubtless scrambling around trying to determine what of their customer data may now be in the hands of extortion-happy criminals who are not shy about bragging to the press, nor about releasing stolen data that they have managed to acquire.

The bigger message, I think, here is the steadily growing consequences which we keep seeing arising from outsourcing.  I'm not suggesting that the benefits do not outweigh the risks, only that risks which remain unseen and unappreciated cannot be hedged against nor planned for.  When Cloudflare goes down, as we saw two weeks ago, it takes an appreciable portion of the web down with it.  The same is true for AWS and Microsoft.  From the perspective of the individual customers who have outsourced their needs to those providers, this is an inconvenience for several hours while their critical infrastructure is completely off the Internet.

So collectively, the amount of pain is huge.  But on the other hand, it's very likely that many of those individual providers are positioned behind Cloudflare to obtain the 24/7 benefits of Cloudflare's bot attack prevention and mitigation.  And were it not for Cloudflare on an individual basis, those companies would be periodically blasted off the Internet at the whim of random unknown attackers using today's inexpensive DDoS-as-a-service facilities.

So what does this have to do with Salesforce?  The same principles are at play here.  In the case of Salesforce, the new model is known as BPO - Business Process Outsourcing - where significant pieces of a business's operational requirements, where there would be a lot of wheel reinventing without much value to add, are instead of being done in-house, developed and done and maintained in-house, outsourced to specialist providers.

While it makes sense from an operational standpoint to do that, we've just seen more than 200 of Salesforce's individual customers who were all using Gainsight's apps connected to Salesforce's backend API having the data of an unknown number of their customers exposed through no fault of their own.  Recall that long ago there was a story of all of the dental offices that were compromised when the managed service provider that they were all using to outsource a bunch of their dental-specific operations - you know, probably dental insurance and dental billing - and their internal networks were all, in turn, hacked because the MSP, the Managed Service Provider they were all using, got breached, and the bad guys crawled down the network connections to all of that company's clients.

This Gainsight/Salesforce event is an updated version of that, and it's happening at a much greater scale because the services that are being offered have become much more granular and much  more generic.  You know, sales support desk services.  Lots of people need that.  The general idea is, let's not have anything in-house that we can sub-contract for.  It makes companies much more dynamically resizable, and it's far easier to terminate a contract for an outside service that's no longer needed than it is to terminate the employment of a department full of employees with whom multiple birthdays have been celebrated.

So the unspoken of cost, the downside of that, is that our industry still has very significant operational security problems that show no sign of having been worked out.  The fact that Salesforce's reaction to the breach is to invalidate a provider's static access credentials, thus effectively excommunicating them and all of their users from having any access, strongly suggests to me that today's model of interacting networked applications is still far too crude to withstand the sort of scaling that demand is creating.

I'm not close enough to the problems to be able to propose any better solutions, but the way things are being done today feels wrong.  I hope those who are in the trenches are thinking about how to make this all work in a more secure and robust fashion.  The feeling is that these breaches are still being seen as exceptions that hopefully won't repeat.  But they are repeating. All the evidence suggests that this is the wrong way to think about them.  This feels sort of like - it's reminiscent of the Internet in the days before the concept of a firewall was introduced.  Which of course changed the whole landscape.

The general concept of widely distributed API-linked outsourced services seems to have proven itself.  That works.  But now the industry needs to figure out how to reduce the blast radius when something evil manages to crawl into the network.  What we know is that the more interlinked such complex systems become, the more fragile and vulnerable to malicious exploitation they are.  And that's what seems to be happening here.  So anyway, you know, another event of an API user of Salesforce having a breach which in turn allows all of the data stored on behalf of the customers of that API being obtained by bad guys.  And we need to prevent that from happening.  It's happening over and over and over, which suggests that the model is wrong.  The interaction model is, like, it's the obvious thing to do, but it's not robust enough.

And Leo, I am very excited to share this next piece of news, which was an early Christmas for me.  There's nothing, I mean, I'm astonished by what Cisco wrote.  But let's tell our listeners why we're here.

LEO:  Okay.

STEVE:  And then we're going to do that.

LEO:  You saw, I don't know if you saw this, Brian Krebs was able to kind of ferret out one of the guys running Shiny Lapsus$ Spider guy, whatever the name is.  He's a 15 year old living in, was it Jordan?  I can't remember.  Living in the Middle East somewhere.  His father's a pilot for the Royal Jordanian Airline.  And he had some, you know, he had some poor operational security and basically accidentally reused some account information.  So Brian has his name.  He contacted - he couldn't contact him, so he contacted the guy's father.  Always good, if you've got a hacker, talk to the dad.

Which he says his name is Saif Al-Din Khader.  And he is now corresponding with him on Signal.  And he says, yeah, I'm trying to get out of this.  This has gotten way out of hand.  He was one of three administrators on their Telegram channel, ran a hacking website, which seems to be responsible for distributing some of the software that they were giving to affiliates.  And of course one of the things...

STEVE:  The 15 year old.

LEO:  15 year old.  15 year old.  One of the things - and by the way, he was using his dad's computer.  Krebs says it was a shared Windows PC.  It was the family computers that the kid was using.  But you know that one of the real skills that Scattered Lapsus$ Hunters has is social engineering.  And I think a lot of times these kids are very good at making phone calls and saying, you know, I'm a little old lady, and I need some help, or whatever it is that they are able to do to get...

STEVE:  They are unabashed.

LEO:  They're unabashed.  I think that's part of the problem is that they don't have a frontal lobe yet.  They're not - they don't - they're not yet fully developed.  Anyway, he says he's already heard from European law enforcement.  He's been trying to extricate himself from Shiny Lapsus$ Hunters.

STEVE:  "He" meaning the 15 year old.

LEO:  The kid, yeah.

STEVE:  Oh, good.

LEO:  Well, yeah, we'll see.  But he was, you know, I mean, they're slowly rolling these guys up.

STEVE:  Yes, they are.  Yes.  And in fact I think it was a week or two ago that I reported on that.  I wanted to make sure people understood that people, you know, these kids were being caught.  It's not like, you know, they were getting away with all this.  And so it's important to recognize that...

LEO:  Well, and in fact Saif says that he's one of the reasons that they're getting caught.  He says, "I've been cooperating with law enforcement since June."

STEVE:  Ah.

LEO:  So it's an interesting, interesting story.  It's on Krebs on Security website.

STEVE:  Cool.

LEO:  Brian did some really good sleuthing to track this guy down.

STEVE:  And he does.  He's great at that.

LEO:  Yeah, yeah.

STEVE:  He ends up being, you know, often attacked as a consequence.

LEO:  Well, that's the other side of the story, yeah.  He becomes the enemy.

STEVE:  Yeah.

LEO:  All right.  We'll have more in just a little bit with Steve Gibson and Security Now!.  But first a word.

STEVE:  Oh, Cisco.

LEO:  A very happy Steve.  His Christmas came early.

STEVE:  And now...

LEO:  With the good news.

STEVE:  I would argue that it's important if in any way I might have influenced, this podcast might have influenced Cisco.  I don't believe so.  I'm sure that my observations are shared by many.

LEO:  But you were part of a general pressure campaign on Cisco; right?  I mean...

STEVE:  Well, I've pretty much been as hard on them as anyone could be.

LEO:  Deservedly so.

STEVE:  While also proposing solutions.  And it's not like I'm saying, oh, you're bad and evil.  It's like, no, they need to do this.  They need to do that.  Anyway, so we all know that I frequently find fault, tremendous fault, actually, with the apparently, from all outwardly observable evidence, this cavalier attitude that Cisco has always had toward security.  And we all know that change is difficult.  And I get it that Cisco, being an early and, like, the early pioneering commercial network equipment supplier, was building routers way before security was even appreciated as an issue.  As we know, the original Internet had no security.  It was just amazing enough that it worked.  And as I've noted earlier, their original, Cisco's original routers were running a large collection of often unneeded services by default.  They just had all this stuff turned on because, whew, it was cool.

And since those routers, Cisco's routers, treat all of their network interfaces equally, they're just numbered, there's no concept of a LAN or a WAN, the only way you imbue that onto an interface is the IPs and network range you give it, the declaration of it as a gateway, and the other characterizing that you do for the interface.  So as a consequence, all of those often unnecessary services were bound to and available on all of the router's interfaces.  I mean, it's the definition of insane lack of security.  And Cisco only slowly, and with seeming reluctance, has begun to change the behavior of at least not running all of those services by default.  Instead of saying, explicitly having to say, you know, no HTTP service in the config file to turn it off, now you have to say HTTP service in order to turn it on.

So there have been improvements.  But, I mean, they've just been inadequate, as evidenced by the fact that huge numbers of Cisco routers are being commandeered and penetrated when some random fault is discovered in the authentication of them, and they're wide open to the Internet.

So we're back here today because of a short blurb that I read which caught my eye.  The blurb was titled "Cisco's Resilient Infrastructure."  And I thought, okay, what's that?  This short little thing said:  "Cisco has announced Resilient Infrastructure, a project modeled after Microsoft's Secure Future Initiative program that aims to improve the security of its products."  Okay.  Maybe.  "This includes," this thing said, "increasing default protections, removing legacy insecure features, and introducing advanced security capabilities which reduce the attack surface and enable better detection and response."  Okay.  That's all the right words.  Never before have I been hoping that somebody in a position of authority inside Cisco may have gotten wind of my own thoughts about the problems with their approach to security.  Hopefully these are widespread.  So, you know, okay.

So anyway, I went looking then for what had triggered that short announcement capture.  In their Executive Platform section, Cisco's executive platform section I found the article titled "Doubling down on resilient infrastructure."  This was posted under the name of Anthony Grieco, a Cisco Senior Vice President and Chief Security & Trust Officer.  So the title's right.  The posting says:  "Global networks have faced relentless attacks for years with recent and dramatic increases in sophistication, scale, and speed.  The current dynamic requires urgent change.  Organizations must assess their current risk posture and use technology vendors' guidance and tools to securely implement, maintain, and operate their networks.  We recognize that the vast amount of information across products and services from different vendors can create insurmountable complexity for customers attempting to secure their infrastructure.

"To that end, we are simplifying our offerings so that secure configurations, protocols, and features are the default.  We are proactively alerting network administrators when insecure choices are being made and deprecating legacy methods that have served as operational mainstays for over two decades, all to create a more secure, resilient, and modern network."

Okay.  Please.  I could not have better expressed what they need to do.  They get more specific.  Anthony continues:  "At Cisco, we have spent years making technology that allowed our customers the ultimate flexibility in how to configure and deploy networks."  I would agree.  "We also have a long history of constant improvement in the design of our portfolio to be secure and resilient to evolving threats, remaining trustworthy and transparent throughout its lifecycle, and equipping our customers with the tools and information they need to manage risk.  This technology is useless if it is not deployed securely."  Okay.

"Running global networks is complex," he writes.  "While experts once thrived in this environment, today's" - okay, this is interesting.  "Running global networks is complex.  While experts once thrived in this environment, today's landscape has turned past complexity into vulnerability.  Network infrastructure that was designed, built, and deployed in decades past did not anticipate today's hostile security environment."  Again, it sounds like a digest of the podcast.  "This is further amplified by the fact that many organizations have not updated and maintained their network infrastructure, missing opportunities to fix known vulnerabilities and update configurations based on the latest security best practices."  100% there, Anthony.

"A new Cisco-commissioned report found that 48% of network assets worldwide are now aging or obsolete, creating significant technical debt that diverts budgets toward maintenance rather than modernization.  It is the equivalent of a city relying on a rusted, cracked bridge for all its traffic.  As dependence on global networks grows, failing to break the current cycle of escalating threats could have a significant impact on our ability to trust future digital systems."  Amen.

"We believe it is the responsibility of all trustworthy vendors, including Cisco, to inform customers when the use of certain technology" - oh.  "We believe," I'm going to repeat that, "it is the responsibility of all trustworthy vendors, including Cisco, to inform customers when the use of certain technology may expose them to potential risks."  This is all new.  "This is why we are doubling down on the model where security is the default and any reduction in security requires an explicit choice."  Wow.  Okay.  This sounds wonderful.  And as we've discussed, it is exactly the way to do it. 

He said:  "It moves our customers from facing unexpected risks to managing known and deliberate ones.  In some cases, we will completely remove the ability to do things insecurely regardless of choice."  Wow.  This, you know, this is Cisco's Senior VP, Chief Security & Trust Officer talking.  I just hope it happens.

He said:  "Today, we are announcing the next step in our security evolution focused on reducing the attack surface in our portfolio, increasing protection of sensitive data, and enabling the defender with more robust capabilities to monitor and detect threats in network infrastructure."  It's like they've awoken to security, which, while late, is certainly welcome.  He said:  "Resilient Infrastructure is a Cisco effort to strengthen network security by increasing default protections, removing legacy insecure features, and introducing advanced security capabilities which reduce the attack surface and enable better detection and response.  Simply put, we are making it incredibly obvious" - they actually said "incredibly obvious" - "when our customers are configuring insecure features that introduce new and unnecessary risks into their networks."  Oh, please be true.

He said:  "Initially, customers will receive increased security warnings that recommend discontinuing the use of any insecure features.  In subsequent releases, features will be disabled by default or require additional steps to allow for configuration. Eventually, insecure options will be removed entirely."

LEO:  Woohoo!

STEVE:  God, it's Christmas for security!

LEO:  What are you going to talk about?

STEVE:  "Most importantly," he said, "we are furthering our commitment to our customers, and the industry, to provide visibility in areas where customers and large network providers are exposed to risk.  We encourage all technology vendors to adopt the same approach to transparency.  Historically, network infrastructure has not received the same level of monitoring and scrutiny as other parts of the IT infrastructure."  He said:  "If it ain't broke, don't try to fix it.  That is no longer the case."

LEO:  Good.

STEVE:  "We want to emphasize the importance of, and make it even easier to perform, effective monitoring, detection, and response within network infrastructure when, not if, vulnerabilities and attacks manifest.  Addressing newly discovered vulnerabilities often requires patching or updating systems, which can create operational disruptions and cause unwanted downtime.  Instead of waiting for a patch or scheduling emergency upgrades, we will be designing features to deploy targeted real-time shields that protect against specific vulnerabilities soon after they are identified."  What?  Did everybody hear that?  He just said:  "Instead of waiting for a patch or scheduling emergency upgrades, we will be" - we, Cisco - "will be designing features to deploy targeted real-time shields that protect against specific vulnerabilities soon after they are identified."

LEO:  Shocking.

STEVE:  "This method allows teams to mitigate potential risks immediately, without the need to interrupt operations or perform unplanned maintenance.  It means faster responses to threats, fewer operational headaches, and a more resilient network, so critical services stay online, even as the threat landscape evolves."  Okay.  I'm just speechless now, except to say "Thank you, Cisco."

He finishes:  "We know security and trust in technology will look different in 2040, as it did 15 years ago."  Meaning 15 years from now is 2040; 15 years ago, we know about that.  He said:  "As we evolve the network to be secure today, we must prepare for the future.  It is crucial we get this right. The network is the foundational infrastructure that powers every aspect of our lives, enabling technologies like Artificial Intelligence.  We rely on the network to protect our most sensitive data, but quantum computing is poised to upend today's modern encryption algorithms; therefore, the network must evolve to support post-quantum cryptography and must be secure by default.

"This is not simply a switch to be flipped in the next decade as AI becomes the norm and quantum computing inches towards mainstream adoption.  Those that do not act now will unfortunately be doing so at their own peril."  I wonder if this guy just got hired.  I don't know what - how do you explain this?

"No measure," he writes, "can guarantee perfect security; but as the threat landscape evolves, so will our security practices.  To put that promise into action, we will continue to invest in innovation to help our customers effectively manage risk, overcome threats, and work to earn and maintain their trust.  We remain committed to raising the bar, giving defenders the tools they need to operate, detect, and respond securely, and doing so with trust, transparency, and accountability.  We urge all network operators to act now to comprehend and mitigate infrastructure risk.  Actively protect your organization by keeping systems up to date, using secure configurations, and planning for device lifecycle management.  Now is the time.  As an industry we must raise the collective bar for securing our global infrastructure.  Join us as we collectively move toward a more resilient future."

LEO:  Wow.

STEVE:  Okay.  Now I fully understand that it's one thing to say it and another thing to get it done.  But after reading this, I'm not feeling at all cynical.  This writing evidences an absolutely perfect grasp of the problem - which no one inside Cisco has ever shown, with their "But didn't you read our optional device hardening guide?"  What?

The huge sea change evident here is that Cisco is, for the first time ever, actually taking full and direct responsibility for the in-the-field, deployed, operational security of their products.  That is a switch from "Read our optional device hardening guide" to "We no longer publish a device hardening guide because we built it all into our systems from the start."  I couldn't possibly ask for anything more from them, and I hope that what they do, that the approach they take, will be seen and emulated by every other similar network equipment and services company.

You know, it's 2025, almost 2026, and "network security" is no longer a buzz phrase that's given some lip service.  Network security has become at least as important as performance, perhaps even more so.  So it's significant that anyone deploying any of this next-generation new "security first" Cisco gear, they will themselves directly experience Cisco's then demonstrated commitment to THEIR network security, you know, their company's network security.

So it occurs to me that in this era where now network security is truly important, experiencing Cisco's commitment when you're configuring their equipment and you're getting dialog saying, eh, I don't think you want to do that, that's got to be a sales-promoting feature.  So, you know, feeling that Cisco has your back and is demonstrating that fact during device setup, that's got to be good for Cisco's sales and for their reputation.  So what I think this means is that what Cisco is now doing is just good business.  The world has evolved to the point where device security trumps its features.

I'm so happy.  You know, the world has just received an early Christmas present.  Yes, deployed gear will stay out there.  But it's going to die over time.  It's going to need to be replaced.  Cisco is saying the replacement gear is going to have features unlike any of our previous approaches.  And when those devices are updated with a new version of IOS, it's going to take a whole different approach.  So bravo, Cisco.  Wow.  Wow.  Be fun to see it happen.

Okay.  So the headline of an announcement - which, Leo, you were already clued in on this; I was just like, what? - from the Australian government as legislators continue to lock down Internet content, was Twitch assessed as age-restricted social media platform.

So here's what Australia's eSafety Commissioner posted last week:  "eSafety has informed Twitch it is considered an age-restricted social media platform required to take reasonable steps to prevent under-16s from having accounts, in accordance with Australia's Social Media Minimum Age legislation."  And I should note that that legislation began back in 2021 and has been moving forward and going back and forth.  But it takes effect next Tuesday.  No, next Wednesday, sorry.

Okay.  So eSafety wrote:  "Following Twitch's own self-assessment, eSafety assessed Twitch as meeting the criteria for 'age-restricted social media platform' because it has the sole or significant purpose of online social interaction" - oh, the horror - "with features designed to encourage user interaction."

LEO:  What?

STEVE:  Oh, my god, Leo, who's ever heard of that, "...including through livestreaming content."  Okay.  So it's not about the nature of the content at all, it's that Australian legislators do not want people under the age of 16 to be able to capture, post, share, and interact about content.

The announcement continues, writing:  "Twitch is a platform most commonly used for livestreaming or posting content that enables users, including Australian children, to interact with others" - wow, we can't have that - "in relation to the content posted.  eSafety has also informed Pinterest it does not consider it subject to age restrictions on the basis it does not currently meet the criteria for an 'age-restricted social media platform.'  While Pinterest enables some online social interaction, it is not the significant purpose.  Pinterest is more commonly used by individuals collating images for inspiration and idea curation."  So apparently we're going to now have a new eSafety Commission that gets to decide who gets age restriction and who doesn't.

LEO:  Yeah.  Already Facebook, Instagram, X.com, you know, the usual suspects are already covered.

STEVE:  Yeah.  And in fact this commission said:  "From December 10th, Twitch and the previously announced Facebook, Instagram, Kick, Reddit, Snapchat, Threads, TikTok, X, and YouTube..."

LEO:  In other words, all the places we stream.

STEVE:  Yes, "...will all be required to take reasonable steps to prevent Australian children under the age of 16 from having accounts."  They wrote:  "Although it is ultimately a matter for the courts whether a service is an age-restricted social media platform, eSafety undertook these assessments to assist Australian families and industry prepare for December 10th."  Meaning next Wednesday, just so everyone is really clear on that.  You know, the day after our next podcast.

"eSafety expects all online platforms that operate in Australia" - which is to say all online platforms - "to assess their obligations under Australian law, including the social media minimum age.  eSafety has provided a self-assessment tool to help industry understand if they're required to comply with the social media minimum age and remains in ongoing discussions with platforms about their compliance obligations and their planned approach towards compliance.

eSafety, I mean, Leo, this sounds like some other world.  "eSafety has been assessing platforms against the criteria set out in the social media minimum age legislation and the Minister for Communications' legislative rules over recent months.  This work has occurred in stages, allowing eSafety to release information to the public as some preliminary assessments were completed, and while others were still underway.  There are no further assessments planned in the lead-up to 10 December."  Wow.  So much for Christmas in Australia.

Remember that the flipside, as we noted at the top of the podcast, the flipside of preventing anyone under the age of 16 from accessing Facebook, Instagram, Kick, Reddit, Snapchat, Threads, Twitch, TikTok, X, or YouTube is the implicit need to prove that anyone wishing to do so is at least 16 years old.  Starting December 10th, Wednesday after next, every Australian, all 35 million of them - wait, no.  It was 35 million kangaroos.

LEO:  That's kangaroos.

STEVE:  Oh.

LEO:  That's 27 million Australians.

STEVE:  27 million Australians.  Kangaroos, I'm sure they're excepted from this.

LEO:  I don't think they have to worry, yeah.

STEVE:  Yeah, they're exempt, yeah.

LEO:  Yeah.

STEVE:  All the Australians must prove their age.  And, you know, Grandpa must prove his age.  And the world lacks, as we know, any privacy-preserving way to do that at the moment.

So I went over to the eSafety self-assessment page to better understand what was going on.  I've got a link to that page in the show notes for anyone who's curious.  Under the topic "Definition of 'age-restricted social media platform,'" that page says:  "An age-restricted social media platform is an electronic service which meets all these conditions," and they list five.  "It has the sole purpose, or a significant purpose, of enabling online social interaction between two or more end-users."  So a web forum; right?

LEO:  Yes.

STEVE:  "It allows end-users to link to, or interact with, other end-users.  It allows end-users to post material on the service.  It has material which is accessible to, or delivered to, end-users in Australia.  It is not an excluded service under the Rules."  Okay, excluded service?  Excluded services are things like professional networking or professional development.  Maybe LinkedIn, for example.

LEO:  Yeah, LinkedIn's not on the list, yeah.

STEVE:  Yeah.  Support of education or health, facilitating communication between educational institutions and students and/or their families, and facilitating communication between health providers and people using those services.  So these rules are so ridiculous and over the top that it was necessary to carve out a whole bunch of qualifying under these ridiculous rules services that's not what they meant.  Oh, but not if you're a university.  Not if you use a service to communicate with your services.  You know, in other words, it is the intention of the Australian legislators to deliberately target what we all know as modern online social media.

In that sense, as I noted, what we have taking effect in Australia is tantamount to Mississippi's far-over-the-top blanket prohibition on access to any and all social media within the state of Mississippi.  But this is being applied, starting the middle of next week, to the entire country of Australia.  It's like, what's happening?  Wow.  So, you know, what?  Bluesky goes dark in Australia, the way they felt that they had to go...

LEO:  Well, it's an issue for me, believe it or not, because we have forums.

STEVE:  Yeah.

LEO:  And we have a Mastodon instance.  We have chat.  We stream in all these places.

STEVE:  GRC has web forums.

LEO:  Yeah.  I mean, I don't have any way of doing age verification.

STEVE:  Nobody does.

LEO:  So should I just block Australians?  I mean, if I could, I would.  We have a lot of Australian fans.  I'm sorry, guys, but it's not you.  It's your government.  I don't know what the answer is.  I'm just going to pretend I didn't know about it.

STEVE:  Yes.  I think that the answer is to do nothing until you receive a little note from the eSafety folks, and then say...

LEO:  Right, right.  Mastodon's already said we have no mechanism for doing this.

STEVE:  Who has?

LEO:  Mastodon.

STEVE:  Yeah.

LEO:  As a company.  Of course it's open source software, but the people who do the software say we have no way of doing this and have no plans to implement this.  So all I've done on our TWiT Social is I put a little thing, don't join if you're under 18.  You promise by joining that you're not under 18, that you're not under 18.  Anyone else can do it.

STEVE:  And unfortunately, we know that that does not - that no longer satisfies the law.

LEO:  Right.

STEVE:  You must actually get some form of identification.

LEO:  I don't know anything.  I know nothing.  What are you talking about?

STEVE:  I know, I know, I know.  It's wrong.

LEO:  It's really [crosstalk].

STEVE:  And, I mean, it's like, so a 15 year old can't hang out at GRC's forum and talk about...

LEO:  Can't watch YouTube?  What?

STEVE:  Yeah.

LEO:  I can only feel for teenagers in Australia who are - must be going crazy.  It's been very good for VPN providers.

STEVE:  It's going to be.

LEO:  [Crosstalk] mentioned last week, what's the next step?

STEVE:  Yeah.  Wow.  Wow.  Okay.  So speaking of messes, Politico reported last week that more of Europe is wishing to move away from U.S.-based computing solutions.  The beginning of Politico's reporting said:  "BRUSSELS," you know, as in Dateline Brussels...

LEO:  Dateline Brussels.

STEVE:  "A cross-party group of lawmakers will urge the European Parliament to ditch internal use of Microsoft's ubiquitous software in favor of European alternatives, according to a letter obtained by Politico.  The call comes amid fresh concerns that the dominance of a handful of U.S. tech giants has become too much of a liability for Europe's security and prosperity, and as the U.S. administration renewed demands for digital concessions at a meeting in Brussels on Monday."  That's what precipitated this.

"In the scathing letter," they wrote, "to be delivered to Parliament President Roberta Metsola on Tuesday, 38 lawmakers also list the screens, keyboards and mouses" - it said "mouses" - "from Dell, HP, and LG, in use across the chamber's IT systems, as technology that should be ditched.

"The letter reads:  'With its thousands of employees and vast resources, the European Parliament is best positioned to galvanize the push for tech sovereignty.  When even old friends'" - and this means the U.S.  "'When even old friends can turn foes and their companies into a political tool, we cannot afford this level of dependence on foreign tech, let alone continue funneling billions of taxpayers' money abroad.'  The lawmakers cite a broad range of European alternatives they argue are viable solutions, from Norwegian Internet browser Vivaldi, French search engine Qwant, and Swiss secure email suite Proton, to the German collaboration platform Nextcloud.

"The lawmakers wrote, praising the International Criminal Court's recent move to drop Microsoft over U.S. sanction fears" - and we talked about that recently - "they wrote:  'Our mid-term goal should be the complete phase-out of Microsoft products, including the Windows operating system.  It's easier than it sounds.  The Parliament's vehicle fleet,'" they wrote, "'is almost entirely made up of cars from European brands.  The same can be replicated for end-product computer hardware.'  They call to set up a task group of lawmakers and Parliament staffers to help and monitor that transition.  'With enough political will," they wrote, "we will have freed this institution from the danger of foreign tech dependency by the end of the mandate.'"

So I'm sure these very strong U.S. technology companies will survive, but interdependence creates stability, you know, global stability, because everything is about economics.  So I'm sorry to see Europe as a whole pulling away from the U.S., though it's hardly surprising given the way relations have been during the past year.  We, meaning the U.S., just need to be very sure that this is what we really want because it's what we're getting.  And I know what our listeners want, Leo, which is another break.

LEO:  More ads?  Really?  You think?

STEVE:  We're an hour and 15 in.  And we're going to switch to looking at some long responses and interesting, I think, to our listeners' feedback.

LEO:  Okay.  Back to you, Steve.

STEVE:  Yeah, we were early covering the whole birth of password managers.

LEO:  Yeah.

STEVE:  At some point in the early days of the podcast.  They were a new thing.

LEO:  I'm thinking the idea of using a Passkey instead of a master password is kind of like SQRL.  You probably have to put the Passkey on a device, I'm thinking.  And then you'll scan the QR code.  Because how else would you do it?  You can't do it with your password manager.  It isn't unlocked yet.  Right?  So you put it on your phone.

STEVE:  We have this first question was from a listener.

LEO:  Oh, perfect.

STEVE:  Brian Garland, who said:  "Steve, I've been using a password manager and long random passwords for some time now.  I'm seeing options for Passkeys and YubiKeys more frequently, and I realize I don't have a good feeling for the best practices for those options."

LEO:  Ah, good.

STEVE:  "Have you done a 'best practices' segment for passwords/Passkeys/hardware keys?  If so, please point me in the right direction.  If not, this might be a good segment for a future podcast.  Thank you.  Brian."

So it is a great question that we've never directly addressed.  I think that the optimal answer has been changing while we, A, waited for our chosen password manager to add support for Passkeys, which they didn't initially have, of course, because Passkeys didn't exist; and, B, while we waited for the FIDO association to follow-up the Passkeys functional specification with a Passkeys import/export specification.

So we don't yet, even now, have universal cross-platform Passkeys transport in any common format.  It's said to be coming.  The FIDO group are working on it.  But, you know, it's not yet available universally.  However, I would imagine that all of our listeners are using, because they're listening to this podcast, a single common password manager across all their platforms.  You know, both 1Password and Bitwarden completely support cross-platform Passkeys synchronization.  So the use of a password manager means that Passkeys support is now entirely practical, even though it doesn't - there isn't native import and export cross-platform.  If you're using a cross-platform password manager, problem solved.

So what does this mean for Brian's question of best practices?  It means that there is zero downside and only a significant upside, meaning good news, to the use of a Passkey, and the Passkey option should be chosen whenever it's presented.  Passkeys are clearly the future.  Usernames and passwords are the past.  So use a username and password when and until you have no other choice, but switch to authentication with a Passkey whenever it's offered.  There's just no reason not to, as long as you're doing this with a password manager that gives you ubiquitous access to that Passkey.

So what about YubiKeys?  As we've observed, security and authentication always requires keeping a secret of some kind.  It's by proving that one knows the secret that one's identity is asserted since the assumption is that the holder of the secret will have successfully prevented that secret's disclosure.  The problem with the username and password system is that the only way of proving that one knows the secret is by providing it in some form to the relying party.  This is the danger inherent with username and passwords.  The secret itself is disclosed to prove knowledge of it.

And that's exactly what makes public-key authentication systems so much more secure.  In a public key system like Passkeys, the relying party, the party that wants you to prove your identity to them, sends the authenticating party a unique piece of entropy to sign using their secret private key.  When the signed entropy is returned to the relying party, that signature is verified using the authenticating party's previously provided and stored public key.  Since only the holder of that public key's matching private key could have properly signed the entropy, the signer has proven their identity without ever disclosing their secret, which is their private key.

So this means that the protection of a Passkey's private key is paramount.  Secrecy still must be maintained, even when you're using Passkeys, as much as when you're using usernames and passwords.  It's just that you've not disclosing that secret every single time you use it.  So that's where YubiKeys enter the picture.  A YubiKey is an HSM - a hardware security module - which is capable of using previously stored private keys to sign a challenge in order to assert the identity of its holder.  The YubiKey itself performs the signing operation so that the user's private key never leaves the key, and it can never be obtained or compromised.  I mean, it is the last word in security for any public key system, original FIDO and now FIDO2 Passkey style.

But that's both a blessing and it can be an annoyance, since the only way to authenticate anything that depends upon a YubiKey is with the YubiKey.  That's what makes the YubiKey the most secure option available is you've got to have it.  But it also means that if you've left the YubiKey at home or at the office, and you're not there, it won't be available for authentication.  And the fact that there's no workaround for that is the entire point of using it.  You can't get around needing it.  Which can be the problem, too.  So depending upon the model of the YubiKey and its generation, it may also have a limited storage for the private keys of Passkeys.  Sometimes it's 25.  Sometimes it's 100.  There are some that have an unlimited mode, but that's a factor, too.  You want to take that into consideration.

So all of that, the issue of maybe not having it on your person when you need it, and the fact that it may have a storage limitation, that all argues for not using a YubiKey absolutely everywhere.  You probably don't need it, you know, that level of YubiKey security, to log into Uber or Facebook or Instagram.  They just don't matter that much.  But you might want to use it when accessing your online retirement investment accounts and anything you might be doing with your national government.  So protect the things that really need protection, but don't over-encumber yourself otherwise.

So I'd say, standing back, that the best practice today would be to always use a - obviously use a password manager to get the cross-platform connectivity that we all need.  Then always use a  Passkey whenever possible because it is more secure in all kinds of ways in favor of old-school username and password.  Only use them when you have no other choice.  And use a hardware token-based Passkey for the handful of sites that really do matter most and where having access to them being tied to the physical presence of your authenticating device won't become an annoyance and a usage handicap.  I think, you know...

LEO:  Well, the password manager's a perfect thing then for that.  You know, make that be...

STEVE:  Yes.

LEO:  ...how you unlock the password manager.

STEVE:  Yeah, exactly.  Thomas, a listener Thomas, said:  "I had a discussion with a colleague today about whether an SSD would survive long in an environment where it was expected to write data once and only be read occasionally, if ever, such as a media server."  He said:  "The web is filled with warnings about not leaving SSDs unpowered for long periods or the charge levels can degrade, and claiming that due to periodic maintenance by the controller, an SSD that is powered on and idle won't have this problem."  He said:  "I find this hard to believe because any controller programmed to maintain cell charge would be re-writing cells that tested marginal, and that would also solve (or greatly reduce) the now infamous read disturb problems.  Maybe some drives are doing this?"  He said:  "I don't think I've heard you talk about this in the past.  What do you think?"

Okay.  So, and I just - the XDA developers forum just had a big thing about this, which is what I thought Thomas - it may have been what stimulated Thomas's question.  A great deal of empirical evidence from SpinRite's users support the belief, which has become mine thanks to all the evidence, I mean, an overwhelming amount of evidence in the three years we were developing SpinRite 6.1, that keeping SSDs powered on does apparently nothing to prevent the gradual deterioration of their data over time.  It takes years.  But people who use their laptops daily still experience a slowing down over time due to softening bits, accumulating errors, and the need for SSDs controllers to perform time-consuming retries and also error correction.

And I recall very clearly having Allyn Malventano tell me, in no uncertain terms, that an SSD will never perform autonomous writes to its own media.  For those who don't recognize his name, Allyn - spelled A-L-L-Y-N - is about as high up in the pecking order of solid-state storage gurus as it's possible to get.  You know, that's his expertise.

The empirical experience from SpinRite's users who have run SpinRite over their SSDs at Level 3 to perform a single-pass rewrite of the drive's entire surface is that older drives had indeed slowed down over time and were completely rejuvenated by that one-time rewrite.  The only way to explain that is that those drives were not doing that on their own.  I've heard the rumors of self-repairing SSDs.  Maybe the rumors persist because it makes so much sense.  But Allyn says those rumors are not true.  And that tracks with SpinRite's before and after drive benchmark findings.

So one thing we do know is if you pull an SSD offline, the temperature at which it is stored matters a great deal.  Physics tells us that you will get much greater rate of charge drift - it's actually electron tunneling - in a hot environment than a cold environment.  So if you've got SSDs that have archival data on them, keep them cool.  Wrap them in a bag, stick them in a refrigerator or a freezer, and the data will be retained far longer than if they are stored in a hot environment.  The first time this surfaced, and we talked about it, was a study that showed SSDs in data centers where the presumption was they were warm, the data centers were warm, due to all these servers and the AC that was trying to keep up.  They tended to lose their data being stored in a hot environment than in a cold one.

So by all means do that.  But I don't think you can count on leaving them plugged in keeping them from having their data deteriorate.  There's no evidence that I've seen that does that.  Certainly it's not the same as just running a read-write pass over it.

Someone named Gorbash1370 said:  "Hi, Steve.  In Episode 1052 the Picture of the Week discussion pleasantly detoured into refactoring, and Leo floated the idea of a coding session or discussion."  He said:  "I just wanted to say how much I would love that!  I'm a middle-aged coding novice (now about three years of compulsive hobbying) who originally hoped to pivot into cybersecurity.  There's a real irony in how AI coding assistance enabled me to learn/build so much faster while probably also wiping out most of the entry-level opportunities that might once have made a related career switch possible."  He said:  "I addictively persist with building because I love the process of coding, the utility, and the self-sufficiency it affords me.

"Unfortunately, no one I know has much tech knowledge, let alone interest in code, so in human terms I'm learning largely on my own.  Obviously I don't trust AI's sycophantic reflections on what is 'normal' when I have a vent about how long coding tasks are taking me.  I'm embarrassed that a coding project that I thought would take me 'a couple of months' has siloed me into a code cave for nearly two years."  Hey, tell me about it.

LEO:  I was going to say, you don't know anything about that, do you.

STEVE:  That's right.  He said:  "I have zero real-world context for what's 'normal' in terms of how coding feels or how long things take."  Well, we could definitely make you feel better about that.

He said:  "Over the years, some of your offhand comments about coding have been unexpectedly important to me.  You've mentioned sometimes returning to old code to have nearly forgotten how it works; about the steep cost of context switching in your reflections on the DNS-benchmark revamp.  I thought I was just a crap coder for finding a few days away from a project to be such a wrench, and to take so long to decipher things I've written before.  I can't overemphasize what a huge relief hearing these things was.  I'd nearly convinced myself there was something wrong with me for having the same experience.  You and Leo have commented how some coders simply aren't suited to being employees, i.e., can only really dev as their own bosses.  Hearing that framed without judgment was another relief.

"All of that is why I'd be soooo grateful if you ever did a one-off episode or extended segment where you just 'chew the fat' about what it's like to code, drawing on that rare decades-long perspective and super rapport you guys offer.  You already do this so well for security each week.  Even a single focused conversation about coding itself - habits, mindset, tradeoffs" - he says, "OMG, timescales!" - "how it feels over a lifetime.  Anything, I'm sure, would be incredibly valuable for people like me.  Thank you both for everything you already put into the show.  It's a genuine highlight of my week seeing the Security Now! logo pop up on my podcast feed.  All the best, Gorbash1370."

So I'd be glad to participate in something like that.  And I was thinking it would be fun to grab a couple of other coders to join.  You know, Randal Schwartz and Father Robert come to mind.

LEO:  We have, by the way, in our Club some really accomplished coders.  I've mentioned names like - you know Paul Holder because he's in your forums regularly.

STEVE:  Of course.

LEO:  He's very good.  Darren Oakey is here.  We have Cyphase, Miguelphire.  And I know they're good because they do the Advent of Code with me every December.  And I'm always blown away by how good they are at writing code.  I think if you want, Steve, we could do this as a club, you know, right now we have an AI users group.  We could have a code users group.

STEVE:  Well, I can't do anything other than a one-time.  I mean, I just...

LEO:  Okay, one time only.

STEVE:  I'm giving this two days a week now.

LEO:  We did a show called Coding 101.  Father Robert hosted that.  The problem we found, I found, is [crosstalk] language?

STEVE:  Specific details?  Yeah.

LEO:  The details, yeah, how do you do it?  There are some really good YouTube coding videos.  In fact, if you like Advent of Code, there's a few people doing it live on YouTube that are really fun to watch, and interesting.

STEVE:  So maybe, I mean, the right thing to do is tell Gorbash to take a look around.  I mean...

LEO:  YouTube is incredible for this.

STEVE:  Yeah.

LEO:  There's one, the guy who wrote Vanilla JS, which was in itself a pretty amazing work of art, to take JavaScript and turn it into something useful.  But he has a - I don't know if anybody uses it anymore.  But he has a - I think it's called You Suck at Code.  And it's a really good YouTube.  Somebody mentioned it in our Club TWiT Discord.  Or You Suck at Programming.  This is the guy here.

Somebody mentioned this in our Club TWiT Discord for Advent of Code.  And it's really - so there is a lot of stuff, on YouTube particularly.  I think it might be hard to do a discussion thing because what are we going to discuss?  I mean, I think people would - I would love to interview you about, you know, your design patterns, your best practices, your experience, and what you've learned and stuff like that.  You know?  Or what we could do is we could give you an interview coding problem like FizzBuzz.  And we could watch you solve it.  That would be fun.

STEVE:  Yeah, I...

LEO:  I don't know.  What would you like to do?

STEVE:  I mean, I guess my thought is sort of a roundtable of people who are...

LEO:  Coders.

STEVE:  Who we like to hear from.  I mean, and that's why I think Randal Schwartz and Father Robert; you know.  I don't know, people who have some perspective on, you know, like, you know...

LEO:  After years, yeah.

STEVE:  Yeah, sort of the process of it.  I mean, I've said things like...

LEO:  You were on Coding 101, by the way, I didn't realize this, four different times.  Do you remember that?

STEVE:  No.

LEO:  2015, 10 years ago.

STEVE:  With Father Robert?  Probably.

LEO:  One was called - with Father Robert - "The Wisdom of Gibson."  "Steve Gibson's Entropy Harvester."  Yeah, you were - he interviewed you, and it looks like Lou Maresca was there, as well, who was also a coder for Microsoft.  We have...

STEVE:  Huh.  In that case, yeah.

LEO:  ...a large number of very good coders in our company, in our group; you know?

STEVE:  It would completely make sense that you would.  That's cool.

LEO:  Who else would watch this stuff?  I, you know, I love coding, but it is also kind of a solitary thing; isn't it.  It's like writers getting together to talk about writing.  You know.

STEVE:  It's actually why I love it.  I'm not collaborative by nature.

LEO:  Right.

STEVE:  I show my results, but I don't show the process.

LEO:  Right, exactly.  I did stream last year the first four problems in Advent of Code.  Which is quite fun.  I decided not to do it this year because it really - it slows me down a little bit.

STEVE:  Yeah.  Yeah.

LEO:  But - and I love the idea.  I just don't know what we can do with it.  Certainly take a look at what's on YouTube.  There's a lot.

STEVE:  Well, and I will feel...

LEO:  Think about it.

STEVE:  I will feel empowered to spend a little more time here talking about stuff.

LEO:  You know, if you talked about code every once in a while on this show, that would be fantastic.

STEVE:  Yeah.

LEO:  I would dig it, yeah.

STEVE:  That's good.  So Troy in Moncton, New Brunswick.

LEO:  Moncton, yes.

STEVE:  Moncton.  He said:  "Hi, Steve.  Thanks for the years of great content.  Been a listener since '06 and really enjoy the weekly roundups you put together for us listeners.  The latest update to the Bitwarden's Browser extension (2025.11.1) broke the Passkeys integration that's been working perfectly for quite a while now."  Speaking of Passkeys.  "At first, like many in the community forum, I thought it was a Firefox update that messed up Bitwarden's functionality, but it ended up being a bug on Bitwarden's end."  And he's got a link to the - it looks like the link is firefox-bw-extension-not-prompting-for-Passkeys-on-any-site.  So that was the - so it was a little glitch in the extension.

He said:  "The temporary solution brought forward by the moderators of the forum is to scale back to the previous version (2025.11.0), and turning off automatic updates for that extension.  That solution has fixed the problem in my browser as well."  And he's using Firefox on Linux.  And he said:  "Bitwarden is already working on the fix.  Maybe by next week's Security Now! this will all be resolved, but just in case other listeners ran into this issue and didn't understand what was happening, it might be worth a quick mention."  So there's the quick mention.  Just a heads-up.  I checked over on GitHub and found the comment about the fix, which read:  "Reverts some of the changes introduced by #17466 and takes a different approach to hiding the extension URL by injecting the script contents instead of linking to it."

I don't know what any of that means, but it does sound like there was, you know, some way that the extension did something that broke some things, and they are now going to do it in a different way to unbreak it.  So just anyway, if anybody might have hit that glitch with Passkeys, it's probably been fixed by now.  If not, check back.

Gregory Paul said:  "Hello, Steve.  Regarding the deprecation of XSLT support, I'd like to draw your attention to the fact that this technology is very useful in the context of RSS feeds, which can be used for podcasts.  Indeed, while RSS feeds are mainly used by RSS readers or podcast apps, if a user opens an RSS feed directly in their browser, a use case is to have an XSLT stylesheet that provides a preview of the feed.  A few years ago, browsers used to display XML feeds directly, but now they are downloaded instead, which makes them harder to view.

"I created an open-source project that lets you send a link to an RSS feed, which I use as a bookmark or to send links to family members.  There's a demo here."  And he gives us the URL, https://rsstodolist.eu.  He said:  "I used an XSLT to display a proper rendering.  I think I'll be able to use Google's suggested fallback (loading a library that emulates XSLT processing) or alternatively make two renderings:  one in HTML for users, with an alternate link tag pointing to an RSS feed."  He says:  "Thanks for your amazing work.  Gregory from Paris, France, a long-time listener, SpinRite owner, and member of the Club TWiT."

LEO:  Nice.  Hello, Gregory, thank you.

STEVE:  So since we talked about this week before last, and then I shared last week some of our listeners' chagrin over Google's planned depreciation and eventual elimination altogether of XSLT support, I was not aware of any intersection of XSLT in my own life.  But a couple of days ago...

LEO:  Oh.

STEVE:  Uh-huh.  While working on GRC's website changes to support the upcoming release of the DNS Benchmark, I was puzzled by an error Windows web server was producing.  Microsoft's IIS web server has become incredibly convoluted through the years as it's been mutated to retain backwards compatibility and a parade of features needed to remain, you know, like new features needed to remain competitive.  Microsoft invented their own server-side scripting language known as Active Server Pages.  Then of course PHP refused to die.  Then JAVA Server Pages became a thing.  And of course Microsoft needed to add their beloved and ever-evolving .NET whatever into the server just to keep anything from ever having a chance to stabilize.  And nothing that's ever come before has gone away; right?  So we have support for server side includes, the original CGI interface, and then the newer FastCGI.  Collectively it is a mess.

And of course each piece was then made into a module.  So there's now an exceedingly long and ever lengthening processing pipeline of modules that are sequentially invoked to process each web request.  So when nothing comes out the other end of the pipe, the quandary is "where in the pipeline did the request die, exactly?"  To answer this too-often-asked question, IIS has a feature called "Failed Request Tracing," which nicely does what its name suggests.  Through the years, I've needed to rely upon it from time to time to solve the sorts of mysteries that would otherwise be utterly impenetrable without a huge amount of trial and error.  It'd be like, okay, well, this works, but this doesn't work.  So how about this?  And okay, let me try this.  And ugh.

So having covered the planned demise two weeks ago of our browsers' XSLT-driven XML processing, I realized for the first time that IIS's own Failed Request Tracing logs are output in XML format, and that it is only thanks to the presence of an innocuous 100K .xsl, it's freb, F-R-E-B.  I'm sure it's, what, Failed Request something something, Failed Request Error, and then a B, .xsl file.  It's sitting quietly in the same directory.  Only if it's there does double-clicking on the XML file produce a beautiful series of explorable web pages that are even remotely legible.

So anyway, Gregory's note indicates that Google is suggesting a fallback, and it's clear that Microsoft themselves will be needing to do something about this by this time next year, since it seems likely that our browsers are going to be losing the ability to ingest, process, and display XSLT formatted XML files.  And it turns out even I will be a little inconvenienced by that.  Although maybe Microsoft, I mean, Microsoft's going to have to come up with some solution because it is - you need this thing in order to figure out where your request died in this lengthy pipeline of craziness.

Bryan Kirchen wrote:  "Hi, Steve.  Listener since Episode 1.  Thank you for 20 years of education and entertainment.  It's crazy to think that I've spent a couple of hours with you in my ear each week for almost 40% of my life."  He said:  "While I'm a long-time listener, my family doesn't get as excited about keeping up on the security news of the week or learning exactly 'how the Internet works.'  As such, I haven't been very successful moving them from their current password chaos to Bitwarden."

So Leo, we have a creation of Bryan which is a YouTube audio.  He wrote:  "I thought that AI might help me with my marketing better password practices to my family.  I had ChatGPT write the lyrics and style prompt, then Suno created the song."

LEO:  Oh, a song.  That's good, yeah.

STEVE:  "Inevitably, this attempt was also met with shaking of heads and," he said, "nearly audible eye rolls."

LEO:  I can just imagine.

STEVE:  Oh.  He said:  "Undaunted, I'm hoping to get a full family conversion to Bitwarden this holiday season.  Thanks again for everything you do.  I love the podcast.  Here's to another 20 years.  Best, Bryan in Deerfield, Illinois."  So Leo?

LEO:  Should I play a little bit?  Yeah?

STEVE:  Here, I think.  Play as much as - until you feel we've had enough.

LEO:  Okay.

STEVE:  Your judgment.

LEO:  "The Great Password Cleanup of 2025.  Gather up, my family, we have a quest today.  Our password life is chaos in a swirling disarray.  There are Chrome ones, Safari ones, Apple ones, too; and half of them are weak enough a baby could get through."  This is great.

"So welcome to Bitwarden, the tidy little vault.  It simplifies your universe and none of this is your fault.  You only need a master key to open every door, and Bitwarden makes the others - we never think of them anymore.  Sing it loud, sing it proud, all passwords in one place."

I'll send this along to our friends at Bitwarden, our sponsor, and see if they want to use it as their new jingle.  That's hysterical.  I will send it to Bitwarden.  They will love it.

STEVE:  Sing it loud, sing it proud.

LEO:  Sing it proud.  It's very, very funny.  Oh, my gosh.

STEVE:  Thank you very much, Bryan, for sharing it.

LEO:  Yeah, I'm sending it to them right now.

STEVE:  Robert Blaakmeer said:  "Hi.  The Picture of the Week (last week) is about what is known as (in the Netherlands) an 'elephant path.'"

LEO:  Oh, interesting.

STEVE:  You know, we call them "desire paths."

LEO:  Because they do look like the trunks of an elephant, yeah.

STEVE:  Or maybe it's that elephants don't bother to follow the curved line.

LEO:  That, too.

STEVE:  They just go in a straight line.  And, you know, then nothing you can do to stop them.  He said:  "And this particular one," meaning our Picture of the Week, "is located just outside the city of Tiel in the Netherlands.  An Instagram account published your picture five weeks ago.  After it went viral, the city of Tiel decided to fix it permanently - by removing the fence again."

LEO:  Oh, that's funny.

STEVE:  They took away the fence.  He said:  "The photo below," which he attached in his email to me, "is the same spot just one week later."

LEO:  They took out the fence.

STEVE:  Yup.  He said:  "And here is a Google Street View from 2009, showing that the elephant path has been there forever."  He gave me a link.  I have it in the show notes.  So he provided us with two photos, which I've grabbed both of them, actually, for the show notes.  So side by side at the top of page 16.  We have a photo of the same path after the city decided to remove the ridiculous barricade.  And then the actual, yes, the actual explanation for - remember that we couldn't see where the path, the official path, what happened to it.

LEO:  This is it over here, yeah.

STEVE:  Yes.  It veered out of the frame.  So what we now know, and this explains why it wasn't left in a straight line, is that there's actually a third path coming in from stage right.

LEO:  Right.

STEVE:  And so the...

LEO:  Knowing, by the way, that this is the Netherlands, this is a bicycle path.  You see the dotted line in there?

STEVE:  Ah.

LEO:  And those, let me tell you, in the Netherlands you take your life in your hands when you walk on these bicycle paths.  So this elephant path may merely be pedestrians dodging the speeding bicycles.

STEVE:  Right.

LEO:  I don't know.  No, this makes sense.  Why would you, if you're walking here, go all the way around?  You just go through.

STEVE:  Exactly.  Exactly.

LEO:  Yeah.

STEVE:  Exactly.  And so the ridiculousness of the gate apparently embarrassed the city officials, and so they yanked it out of the ground.  And now people - and elephants - are able to just go in a straight line.

LEO:  That is fantastic.  Wow.  Thank you for the effort there.

STEVE:  Thank you, Robert.  Appreciate that.

LEO:  He really put in a lot of effort to document the whole thing.

STEVE:  Yeah.  Guy Watkins said:  "Steve.  Listening to VPN blocking laws," he said, "I decided George Orwell was an optimist."  And that's all he said.  And I have to say I don't really believe, I just can't believe that wholesale VPN banning could ever come to pass.

LEO:  No.

STEVE:  I cannot imagine that an entire Internet technology which has many more applications, which is the point that the EFF made in what I shared last week, many more applications than just geo-relocation.  That's kind of a side effect of using a VPN.  That the whole technology could be banned because one of the many things it can do is geo-relocate.  And as we know, just bouncing traffic off a proxy server located elsewhere will have the same effect, meaning it's not even a VPN.  It's just a bounce.  So I just - we'll have to see what happens.  But that just seems crazy.

Ethan Stone said:  "Hi, Steve.  I listened to the latest Security Now!, and I thought I'd fill you in on what happens to people using VPNs right now.  First, it's important to know" - so he's a heavy VPN user.  "First, it's important to know that a lot of sites are currently screening for IP addresses that are associated with a VPN."  He says:  "I don't know how they're doing it."  And actually we're going to find out by the end of the podcast how.  "Although I suspect there are commercial services that try to keep track of the latest IP addresses of popular VPNs" - uh-huh - "and create continuously updated blacklists."  Uh-huh.  "But empirically," he says, "it's obvious that it's happening right now.

"Second, I think I have a different perspective on this because I'm almost always surfing the web on a VPN using a browser that has few or no cookies and is not logged into Google or anything else that would identify me.  As I've mentioned before, I'm one of your more paranoid listeners.  As a result, my experience on the web differs significantly from what most people encounter.  Given all of that, once a site has identified me as using a VPN, various bad things can happen.  I never use a VPN when I'm trying to log into to my account at a financial services company because they commonly refuse to let me log in at all.  But lots of other sites seem to be monitoring for VPN IP addresses and trying to exclude, or at least treat differently, any visitor coming from one.

"For example, I often have to cycle through several VPN servers when I want to see a YouTube video before I find an IP address Google hasn't blacklisted yet."

LEO:  Right, yeah.

STEVE:  "That probably doesn't happen to you because you watch YouTube while logged into a Google account."  That's true.  "But, as noted, that's not me.  So I guess I stand out and look suspicious to Google.  If I use a VPN Google can identify, the videos often either fail outright, or YouTube requests me to login so they can check my age or verify my identity.  But that's just one example.  It happens to me all the time to the point that, if anything on a website doesn't seem to be working right, my first instinct is to cycle to another server.  And at some point, before I contact customer service, I'll try dropping the VPN outright to see if that finally helps.

"It's worth noting that, for some weird reason, sites never tell you outright, 'We've identified you as using a VPN, please drop it.'  They just make things fail in unexplained ways.  I'm not sure why, but it's universal.  I don't think I've ever gotten a message telling me just drop my VPN.  So I thought it might be interesting to you to get a report from the tiny corner case where I spent my time online.  I love the show.  Thanks for everything you do.  Ethan Stone."  So very cool and valuable feedback, Ethan.  Thank you.

Oh.  I hadn't thought about it before, but sometimes when I'm doing a bit of research on a failed GRC web forums account creation, sometimes I look over and, like, see what bots are trying, you know, what's going on with bots trying to create accounts over there.  I'll see what's known about an IP that's being used in a failed attempt to log into GRC.  The XenForo forum software links to "WhatIsMyIPAddress.com," and I'll often see that it has identified an attempted login as a VPN.  So Ethan I'm sure is right in correctly assuming that there are available databases of VPN exit-point IPs, and that websites are treating such visitors who are able to determine that in some different way due to far higher incidents, for example, of fraudulent activity originating from VPN users.

LEO:  All right.  Back to the show we go.  Steve?  

STEVE:  So Jacob says:  "Hi, Steve.  I'm coming to you in search of a solution to a problem I have little experience with.  My grandmother frequently uses Apple IIGS programs for her piano studio.  She does not have copies of the disk, and they have an unknown copy protection on them."

LEO:  Oh.

STEVE:  "They are 3.5-inch floppies, and we only have one working drive for them.  I'm going to try to use ADTPro to get a .NIB copy of the disks.  But from what I've found, that is unreliable with the 3.5-inch disks.  I know you have a lot of experience with spinning media, and I was wondering if you had any suggestions for making copies or digitizing these disks.  Sincerely, Jacob.  P.S.:  I love the show.  Keep up the good work."  So this is a bit of an odd-ball question.

LEO:  Yeah.

STEVE:  But I thought our listeners might enjoy knowing of my reply to Jacob.  I replied:  "Hi, Jacob.  The problem is that the formatting of 3.5-inch diskettes is largely software defined."

LEO:  Oh, [crosstalk] like hard tracks or anything.

STEVE:  Yeah.  "As such, they can have any sort of bizarre physical formatting that would be impossible to duplicate without some sort of very specialized equipment.  Assuming that the diskette's copy protection details are unknown and undocumented, it would be impossible to even know where the protection was stored.

"For example, diskette media is self-clocking, where only the speed of the spindle and the frequency of the data being written determines the placing and spacing of the bits on the magnetic medium.  If a drive motor was spinning just a bit faster than normal while a track's data is being written, the end of one track might start to overwrite the start of that track because the too-fast spinning would bring the track's start back around too soon.

"This problem is not just theoretical.  To prevent this from happening, diskette tracks contain a 'dead zone' at their end.  This allows some 'slack' in case of a too-fast spindle motor.  Consequently, when looking for some sneaky place to place a bit of copy protection authentication information that would never be copied by duplication software, some copy protection systems write an additional small bit of data into that slack region.  Normal software doesn't know to look there, but the copy protection does.

"Another example is the use of an additional cylinder.  Diskettes determine where their head is by incrementally stepping inward or outward.  But anytime they cannot find the sector they're looking for, they seek to cylinder 0 to 'recalibrate' and then step back out again.  Most diskette drives contain an optical sensor to let the diskette controller know when the head has reached cylinder 0.  But Apple saved a dollar by eliminating that sensor.  Apple's drive just runs the drive's head back into a hard mechanical stop.  This is why Apple's drives made some disquieting noises when they were recalibrating their head positions.  Once the drive seeks to cylinder 0, it then counts cylinders as it moves inward.

"But who is to say that a drive can only record 80 tracks?  Sure, 80 is the official track count.  But why not 81?  If the 80th track is reliably read and written, chances are that the 81st track would be, too.  So the unofficial track 81 could also be where a copy protection system might choose to store its data.

"And one last trick might simply be some deliberately mis-written sectors.  Normal diskette software places checksums on sector headers and sector data.  Normal software won't read sectors with bad headers and data.  This might be what the ADTPro diskette copying software will read, if it can.  But writing deliberately damaged sectors again is another trick that diskette copy protection systems have used."  So anyway, my answer about Jacob's probably hopeless quest to back up some Apple IIGS programs that were copy-protected, I...

LEO:  The point is, you could image it, but then when the program ran it would try to read the malformed disk parts.  People used to put little holes in the disks, for instance, to make a bad sector.

STEVE:  Yes.  There was physical damage on media.

LEO:  Yeah.  And so then the software's going to run.  It's going to say, well, let me see if this is a legitimate disk.  And the thing is, your imaging software was unable to copy whatever weirdness the copy protection scheme put in there.

STEVE:  Exactly.

LEO:  However, I have to say, in my day I did this a few times with Atari disks.  Sometimes you can load the program into RAM, find the part that is doing the copy protection, and with a hex editor, jump around it.

STEVE:  Known as hacking, my friend.  Yup.  I think I may have mentioned that a very good friend of mine, the wife of a very good friend of mine had a computerized embroidery shop.  And so they had some dongles that had to be plugged into the parallel port.

LEO:  This sounds familiar, yeah.

STEVE:  Yeah.  And she - I don't remember what happened.  It was one of those, you know, dog ate my homework things.  The company refused to replace one that actually was damaged by a lightning strike on Newport Coast one day.  I mean, it was a, you know.  So it was like the computer needed to get rebuilt, and then Gary finally discovered that the thing, the dongle that had been plugged into the parallel port was dead.  And I think the software was, like, custom vertical, you know, embroidery stuff for thousands of dollars.

LEO:  Sure.  That's why they had a dongle.

STEVE:  Yes, exactly.  Yes.  And so anyway, he came to me, and he said, "Steve" - he called me "Gibson" for some reason, but he said, "Gibson, come on, you've got to help me out here."

LEO:  Help me, Gibson, help me.

STEVE:  It came at a time when I wasn't doing anything, so I said, oh, this'll be fun.  So anyway, I found it was one instruction, a jump instruction that I just NOOP'd, and then I saved the change.

LEO:  So it doesn't jump to the copy protection.

STEVE:  So it didn't, yeah.  Somewhere there is a decision point where it's should I run or not.  And so you just say, yeah, you should.

LEO:  And usually it's at the beginning.  So that's what I would say the best bet is.  If you can image it, do.  It won't run, an  image won't run.  Your next job is to go with a hex editor into that image and see [crosstalk].

STEVE:  Of course the knowledge base of people who know Apple, I mean, I do, from the light pen.  But I've forgotten everything I knew.  But, you know, there's just [crosstalk].

LEO:  6502 assembler.  It's going to be early on the thing.  It's going to be a jump, but there'll be a lot of jumps.  Yeah.  I don't know.  You might try.  It might be a fun little exercise.  You can't, I guess you could disassemble it, try to figure out what's going on, what it's doing.

STEVE:  And I also remember, the copy protection software, you would often hear the head going ch-ch-ch-ch-ch-ch-ch-ch.  It was like very busy doing, like, making sure that it was, you know...

LEO:  I bought a special floppy drive for my old Atari 800, it was very expensive, that had mechanisms to bypass copy protection.

STEVE:  Yup.

LEO:  And it was the weirdest-sounding device ever because it was doing all these little oddball things, yeah.  Yeah.  Well, that's [crosstalk] history.

STEVE:  Yeah.  Jason Egan said:  "Hey, Steve.  I recently came across this game and thought you might be interested."  And Leo, you're going to want to go to unflipgame.com.  He said:  "I like to imagine this is a way of conceptualizing efficiently flipping bits, but I could be way off.  Either way, my kids and I have enjoyed the challenges it presents.  Some can be really tricky.  The best part is watching my kids develop their brains' muscle memory as they start to discover patterns during the unflip process of each board."

LEO:  Oh, yeah, sure.

STEVE:  "Much like the Tower of Hanoi game.  Let me know your thoughts, and thanks for keeping us all informed and entertained."  So anyway, first of all, thanks, Jason.  Several of our listeners who know of my penchant for puzzles without a timer also saw this and thought of me.  So a thanks to everyone else who also sent me notes about this.  And again, it is unflipgame.com.

LEO:  Oh, this is fun.  I get it.  Yeah, yeah, yeah.

STEVE:  It is really fun.  So it's a toy that runs entirely within the browser, thanks to a bit of JavaScript, and I've already spent some enjoyable time with it.  The puzzle begins with an N by N grid of squares - N being a small number like 5 or 6.  And that square grid contains an initial starting pattern with some squares being black.  The goal is to turn the entire grid white.  This is done by dragging the mouse from one corner of your own square to the opposite corner.  Once you release the mouse, all of the squares contained within that newly drawn square invert, you know, black to white, white to black.  So it's an XORing puzzle.  You quickly learn that you're only able to invert square regions.  That's an important limitation.

LEO:  Yes.

STEVE:  The initial levels of the puzzle are nicely designed to teach the basics and to show some of the more important concepts.  The puzzle has a moves counter and a "best" and a "par" indication to show what's possible.  It's possible to just keep pounding on the poor thing, trying this and that and, you know, going around and around in circles, racking up moves.  But the fun is in using some planning and some finesse to always complete the "whitening" in the fewest moves.  Anyway, I like it a lot.  It's unflipgame.com, and I recommend it for our listeners.

LEO:  Level 6, I think I've met my match.  How far did you get?

STEVE:  Oh, I think I got up to 15, maybe.  And up there are the top left you can click on all levels, over on the left.

LEO:  Ah.

STEVE:  And that will show you.

LEO:  Oh, holy moly.  Oh, it gets really hard.

STEVE:  So you did the first five, and there's lots, lots to come.

LEO:  Clever.  Very nice.  And beautifully, simply designed, yeah.

STEVE:  Yeah, it is really neat, yeah.

LEO:  Yeah, I like it.

STEVE:  Bob Sudduth wrote:  "Long-time listener (before Episode 50), SpinRite owner, and," he said, "and old (about you and Leo's age)."

LEO:  Oh, that is old.

STEVE:  "But we're not old," he says.

LEO:  No, no.

STEVE:  "My question has to do with Passkeys and maybe digital IDs," he says, "I have none yet.  I'm a treasurer for a local church.  Many of the government sites want me to use Login.gov or ID.me, which is fine.  But I have two 'roles,' one as me and my personal accounts, and one as a treasurer.  I haven't figured out how to use a Passkey and have two roles.  I have purposely used my church's treasurer email for all church business so I can one day hand all of those accounts over to someone else."  He says:  "I use Bitwarden.  I even have two user accounts on my computer to separate what I do.  My bank is greatly confused and continually tries to link my personal account with the church's account.  I end up at the Social Security site for my information instead of being able to file tax information for the church.

"I get it that I'm one person, but that doesn't mean I own all the funds in my church's accounts."  He says:  "Are Passkeys so simple that I'm making this hard?  Am I missing something?  Will Digital IDs cause the same issue?"

Okay.  So first of all, Bob, I'm wondering whether the confusion at your bank might be due to remaining logged in with one identity when attempting to login with another.  I don't know what could be causing the linkage problem.  But for what it's worth, multiple Passkeys per single relying party, that is, the website, is a common need.  And as far as I know, all of the Passkeys implementations allow for multiple Passkeys to be associated with a single website and different user accounts.  So when you have two assigned - for example, one for you and another for your church's treasurer who happens to also be you at the moment - your Passkey authenticator should prompt you which one of the two you wish to use.

And note that this is different from wanting it to be able to use multiple different Passkeys to log into the same account.  The need that Bob explained is having different accounts wishing to have separate Passkeys all stored in the same device.  And that should be possible everywhere now.  But not all sites support multiple Passkey users logging in, authenticating to the same, for example, bank account.  Which, you know, sometimes Mom and Dad would want to be able to use different Passkeys to log into their shared account, not yet universally available.  But multiple Passkeys on the same authenticator for different accounts at the same website should be universally supported now.

Chad says:  "Hi, Steve.  AI" - oh, I like this.  "AI isn't all it's hyped up to be."  He said:  "I asked ChatGPT to help me identify the 12 disks in the JBOD" - Just a Bunch of Disks - "that I'd recently attached to this host.  The host already has a 16-disk JBOD attached.  It identified the two enclosures.  BUT" - he has in all caps, he's very indignant about this, Leo - "it literally reversed them.

"It told me to run a command to create a new zpool.  It only gave me disks from the 16-bay unit, not the 12.  Since the 12 had disks from a previous pool, I knew I needed a force parameter with zpool, thereby putting the data on my 16-disk enclosure at serious risk."  Meaning that he was going to use the force parameter, but on the misidentified 16-disk JBOD.  He said:  "Thankfully a wc -l command caught chat's screw up, and my data is still safe.  I had provided the command and output it asked for, yet a simple basic task it could not do without making a serious mistake.  I'm not worried AI will replace us humans anytime soon.  Signed, Chad."

Okay.  So one of the things I hear Leo and Leo's AI-informed hosts and guests noting frequently is that today's AI is only as good as the depth and breadth of its training data.  The key thing to appreciate is that today's AI doesn't actually understand anything that it is saying.

LEO:  No.

STEVE:  What's so frigging astonishing about what we have today is that just by being what Leo originally described as a fancy spelling corrector, today's AI is able to do as much as it can and to appear to actually know what it's talking about.  It does this so astonishingly well that it's easy to be seduced by it.

I have a perfect example from my own recent experience.  Last week, I needed to multiply a 64-bit integer by a 32-bit integer. Naturally, my language is Intel assembly code, and I could not assume that the user of the DNS Benchmark would have a 64-bit processor.  Could be a 32-bit chip, or a 32-bit OS.  So I needed to only use 32-bit instructions.  Anyone who has played with machine language knows that a 64-bit by 32-bit multiplication can be performed using a pair of 32-bit multiplies while saving the high-half of the first result and later adding that to the low-half result of the second multiplication. This is exactly what we do on paper when we multiply a two-digit number by a one-digit number.  Just the same.

I was curious to see what ChatGPT's best codesmithing model would suggest.  It was an almost comical disaster.  It was very sure of its result, which was utter nonsense.  It even added some helpful comments to the code which just added insult to injury.

So why can't AI do something so basic?  Because there is not a ton of preexisting Intel assembly language code on the Internet for the model to have previously trained on.  Sure, there's some.  So it spewed out some nonsense.  But that's all it was able to do.  Now, ask it something about Python or PHP or C...

LEO:  Or even Common Lisp.  And Emacs.  Yeah.

STEVE:  Yes.  And stand back because you often get near-perfect amazingly complex code.  But that same AI cannot produce the code to multiply a 32-bit integer by a 64-bit integer using 32-bit Intel instructions.  Not even close.

So my point here, Chad, is that you asked the AI something for which there is not a huge body of very specific knowledge and example.  Your question assumed that it actually understood what was going on in your system.  But it's just a pattern finder and pattern matcher.  It's an astonishingly good pattern finder and pattern matcher.  But for now, at least, that's all it will ever be.

And this is, of course, is the crux of the big multi, now it's a multi-trillion dollar question:  Can LLMs ever be more than this?  Is this the way forward?  Or is this a tantalizingly dead end on the way to more?  There are many AI researchers who, today, still consider all this to be a very, very expensive parlor trick.  Useful?  Yes.  Absolutely.  And, unfortunately, people whose employment is reducible to sophisticated pattern of finding and matching are in trouble today and tomorrow.  Those jobs are gone.  But this may be all there is.  This may be the end of the LLM trick, you know.  There may not be any further road for it to go down.  We'll have to see.

LEO:  Yeah.  My instinct is we've got a lot more to go down the road.  But who knows?  You just don't know.

STEVE:  Oh, I agree.

LEO:  Yeah.

STEVE:  This has clearly, I mean, when you pour this much money and this much focus in, my feeling is that LLMs are probably not the answer, but that we have - but we're going to find it.

LEO:  Yeah.

STEVE:  Because we've got - we have a sniff of it now.

LEO:  Right.  Somebody described it, and I found this very useful to remember, the knowledge of AI, its knowledge base as spiky.  In the sense that, you know, if you say this is our knowledge base, it has - it'll fill, but there'll be spikes.  There'll be areas it knows a lot about, maybe edge cases.

STEVE:  It's not uniform.  It's not uniform.

LEO:  And we're used to saying, well, if this is good in all these areas, it must be good in all areas.  No.  It's very clearly not.  So it's spiky.  It's not uniform, yeah.  It's good to remember that.

STEVE:  And so, and the good news is a lot of computer people, and especially coders, are asking it things that it's pretty good at.  

LEO:  Good at, yeah.

STEVE:  Yeah.

LEO:  And you learn.  That's the other thing, you learn where to trust it and where not as you use it.  

STEVE:  Not multiplication, it turns out.

LEO:  Yeah.  Isn't that funny.  Isn't that funny.

STEVE:  So we must have talked about the Stargate science fiction series through the 20-plus years of this podcast.  I've been a huge fan of the Stargate franchise through its many years.  It was often the case that it was the only good source of science fiction programming.  Part of that was a love of the various original cast members, who I really enjoyed; and part was an appreciation for the writing, which was also often great.  The strongest well-known personality on the Stargate SG-1 series, which was the original series, was Richard Dean Anderson, who many know from the roles that made him famous, which was, you know, as MacGyver.  He was known as MacGyver when he was very young.  And he maintains that same snarky sassy humor throughout the Stargate series, which I think works quite well.

So for those who may not know, and this is no big spoiler, the concept is that an ancient race of technologically advanced, brutal, and not very nice aliens created a massive network of circular portals which we humans dubbed "stargates."  We called them stargates because any pair of them can be interconnected by dialing the far gate's "gate code," sort of like an intergalactic IP address.

Wikipedia, which has an extensive page about Stargate, explains that the pair of stargates are linked by what is informally known as a "wormhole," but is technically an Einstein-Rosen bridge.  Anyway, what I always appreciated about this concept, you know, the concept of stargate as a vehicle for science fiction storytelling was that it very cleverly gave the writers an infinitely large blank canvas.  In "Star Trek," Kirk, Spock, McCoy, Scotty and the rest of the crew roamed around in the Enterprise, and stories were wound around whatever they might find on whatever planet they beamed down to.

Similarly, in Stargate, after first discovering a lone, abandoned, and long-buried Stargate on the Giza plateau in Egypt, after figuring out how to turn it on and discovering that there might be some very nasty aliens on the other end of the wormhole, a new military branch is formed to systematically explore the gate network.  So teams of explorers would dial gate codes consisting of a string of alien symbols that are related to constellations.  And then upon the entry of the seventh symbol, a silvery liquid-appearing "event horizon" would form across the gate's aperture, and then our intrepid explorers would plunge into the gate, not knowing what to expect on the other end.

So anyway, as I said, it gave the writers total freedom, and this thing went on and on.  The first series had - back then, seasons were long, 22 episodes, or 20 episodes later.  But 10 seasons of the first series, four seasons of "Stargate:  Atlantis," and two seasons of "Stargate:  Universe."

So if anybody of our listeners has any young kids of the right age, it's pretty kid-friendly sci-fi.  There's a lot of it, and it's a lot of fun.  Amazon has the rights to it.  And the reason I'm talking about it today is there was just the announcement that Amazon Prime and MGM are going to be doing a new series, and it's got the original creators behind it.  So, I mean, there are fandom sites, there's websites, there's forums, I mean, it was as big a phenomenon as Star Wars and Star Trek, you know, in its own right.  So we've got another series.  We don't know when.  No one's talking about it.  They've just announced it and started working on it.  But I'm hopeful that, you know, we might have some sci-fi fun coming up.  And Leo, we've got our final sponsor coming up.

LEO:  Yes, yes.

STEVE:  And then we're going to talk about Bots in the Belfry.

LEO:  Which you said maybe young people don't know that phrase, "bats in the belfry"?

STEVE:  I don't know.

LEO:  I don't know.  Do you?

STEVE:  Yeah, bats in the belfry.  Bots in the belfry?

LEO:  Yeah.  Let's finish up with Bots in the Belfry.  Steve?

STEVE:  So last Thursday, BleepingComputer brought us the news that the reputable and well-known security firm GreyNoise Labs was offering a new service to check - and even to optionally continuously check - user IP addresses for their association with known bot activity.  So here's what BleepingComputer wrote.

They said:  "GreyNoise Labs has launched a free tool called GreyNoise IP Check that lets users" - and anyone wants to jump ahead, grc.sc/botcheck, just all one word - "lets users check if their IP address has been observed in malicious scanning operations, like botnet and residential proxy networks.  The threat-monitoring firm," they wrote, "that tracks Internet-wide activity via a global sensor network says this problem has grown significantly over the past year" - that's important - "with many users unknowingly helping malicious online activity."  GreyNoise said: "Over the past year, residential proxy networks have exploded and have been turning home Internet connections into exit points for other people's traffic."

And I'll just note that this does track, you know, this statement tracks with some of the more recent reporting we've seen and shared here, regarding the number of IP addresses that have been involved in recent high-bandwidth and also scanning and probing attacks.  You know, we hear hundreds of thousands of bots, meaning bot IP addresses, are enlisted in attacks.  Those must all be somewhere, and running from someone's hardware.  This is not the attacker's hardware.

BleepingComputer continues, writing:  "Some folks knowingly install software that does this in exchange for a few dollars.  More often, malware sneaks onto devices, usually via nefarious apps or browser extensions, and quietly turns them into nodes in someone else's infrastructure.  While there are ways to determine if someone has become part of malicious botnet activity, like examining device logs, configurations, network traffic, and activity patterns, a tool that simply checks the IP address is the least intrusive method.

"Anyone visiting the scanner's webpage will get one of three possible results:  Clean:  No malicious scanning activity detected.  Malicious/Suspicious:  The IP has shown scanning behavior.  Users should investigate devices on their network.  Or, third, Common Business Service:  The IP belongs to a VPN, a corporate network, or cloud provider, and the scanning activity is considered normal for those environments."

Now, I'll just note that BleepingComputer kind of casually used the term "scanner," referring to GreyNoise.  GreyNoise is not a scanner.  You're not being scanned.  You know, a scanner scans, whereas what GreyNoise does is passively collect and collate Internet traffic from across their widely dispersed global sensor network.  That gets captured into a database.  So when I use their "GreyNoise IP Check" facility, I receive an instantaneous response, as will our listeners, that displays my network's public IP and a notification which in my case said "Your IP Is Clean.  Your IP has not been observed scanning the Internet or contained in the Common Business Services dataset."  Since this is a safe, quick, simple, and interesting test, I've given GreyNoise's service, as I've said before, the GRC shortcut of "botcheck."

So you can just enter grc.sc/botcheck into your browser's URL, and grc.sc will just bounce you over to GreyNoise's page, which is check.labs.greynoise.io, if you'd rather enter it the hard way.  And that will perform an instantaneous lookup of the public IP your browser's request is coming to GreyNoise from, against their dynamically updated database of known problematic IPs.

Now, something's interesting, there's something that is interesting about this.  As we've noted in the past, IPv6 gurus grumble incessantly about the ubiquitous presence of NAT routers, which they are quite certain have ruined the Internet.  They doggedly, and to this day, cling to the original concept of a vast network defined by "one IP for one host."  In this original conception of the Internet, there is no IP sharing because there are plenty of IPs to go around.  Well, we all know that's not what happened.  Even though IPv6 really was defined early enough to replace IPv4 and prevent what these gurus see as the scourge of NAT, we have all seen just how unwilling the world is at every level to change away from something that's already working.  The contrary view of the gurus is "Why change? NAT works great.  Everyone's using it."

I mention this because in the context of GreyNoise's very cool free "botcheck" facility, this means that NAT really is serving us as a huge boon.  Everyone's use of gateway NAT routers means that all of the random PCs and phones and tablets and NASes and wacky IoT gadgets we may have encrusting our networks will all be sharing a single common public IP.  This means that asking GreyNoise what they think of our single public IP address while we're sitting at one computer in our home LAN behind a common NAT router, automatically incorporates the collective behavior of every device we have perched on our LAN behind its router.  In other words, receiving a clean bill of health from GreyNoise's check automatically means that you can be reasonably certain that not a single one of the myriad devices on your network has been misbehaving.  Or at least has been seen to be misbehaving.

Now, of course, the flipside of this is that if GreyNoise comes back with the appraisal that your network's IP has been seen misbehaving and participating in some attacks, as a growing number of networks and devices have been, then the onus will be on you to determine what device, or possibly devices, behind your NAT router has been compromised.  But at least you'll know that you have a problem.  Given this, it is a no-brainer for me to recommend that everyone listening should go to grc.sc/botcheck to quickly confirm that none of the devices that are sharing their network's IP have been seen to misbehave.

BleepingComputer provided a bit more information, writing:  "When any malicious activity is correlated with the provided IP address, the platform will also include a 90-day historical timeline, which may help pinpoint a potential infection point.  For example, when the installation of a bandwidth-sharing client or a shady application precedes malicious scanning, strong correlations can be made that enable remediation action.  For more technical users, GreyNoise also provides an unauthenticated, rate-limit-free JSON API, accessible via curl, which can be integrated into scripts or checking systems.  If your scan results show 'Malicious/Suspicious,' it's a good idea to start the investigation by running malware scans on all devices on the same network, especially focused on devices like routers and smart TVs," they wrote.

So, you know, they conclude with the generic advice:  "Users are advised to update their devices to the latest available firmware, change admin credentials, and disable remote access features if they're not needed."  Which of course we all know.  So, grc.sc/botcheck.  And I expect this free and quick service to become quite popular.  It's a win.  And note also that if you do it from a small company, that's cool because this is not like running ShieldsUp!, where I'm actually doing a proactive scan of that IP, which can upset some people.  This is just checking a database to see whether that IP has ever been observed to be up to some funny business.  So I think it's very cool, grc.sc/botcheck.  Bye.

Copyright (c) 2025 by Steve Gibson and Leo Laporte.  SOME RIGHTS RESERVED.  This work is licensed for the good of the Internet Community under the Creative Commons License v2.5.  See the following Web page for details:  https://creativecommons.org/licenses/by-nc-sa/2.5/.