Perpetual IT

Deciphering Microsoft’s official Update Guide web pages is not for the faint-hearted.

Most of the information you need, if not everything you’d really like to know, is there, but there’s such a dizzing number of ways to view it, and so many generated-on-the-fly pages are needed to display it, that it can be tricky to find out what’s truly new, and what’s truly important.

Should you search by the operating system platforms affected?

By the severity of the vulnerabilies? By the likelihood of exploitation?

Should you sort the zero-days to the top?

(We don’t think you can – we think there are three zero-days in this month’ list, but we had to drill into individual CVE pages and search for the text “Exploitation detected” in order to be sure that a specific bug was already known to cybercriminals.)

What’s worse, an EoP or an RCE?

Is a Critical elevation of privilege (EoP) bug more alarming than an Important remote code execution (RCE)?

The former type of bug requires cybercriminals to break in first, but probably gives them a way to take over completely, typically getting them the equivalent of sysadmin powers or operating system-level control.

The second type of bug might only get the crooks in with the lowly access privileges of little old you, but it nevertheless gets them onto the network in the first place.

Of course, while everyone else might breathe a sigh of relief if an attacker wasn’t able to get access to their stuff, that’s cold comfort for you, if you’re the one who did get attacked.

We counted 75 CVE-numbered bugs dated 2023-02-14, given that this year’s February updates arrived on Valentine’s Day.

(Actually, we fond 76, but we ignored one bug that didn’t have a severity rating, was tagged CVE-2019-15126, and seems to boil down to a report about unsupported Broadcom Wi-Fi chips in Microsoft Hololens devices – if you have a Hololens and have any advice for other readers, please let us know in the comments below.)

We extracted a list and included it below, sorted so that the bugs dubbed Critical are at the top (there are seven of them, all RCE-class bugs).

You can also read the SophosLabs analysis of Patch Tuesday for more details.

Security bug classes explained

If you’re not familiar with the bug abbreviations shown below, here’s a high-speed guide to security flaws:

• RCE means Remote Code Execution. Attackers who aren’t currently logged on to your computer could trick it into running a fragment of program code, or even a full-blown program, as if they had authenticated access. Typically, on desktops or servers, the criminals use this sort of bug to implant code that allows them to get back in at will in future, thus establishing a beachhead from which to kick off a network-wide attack. On mobile devices such as phones, the crooks may use RCE bugs to leave behind spyware that will track you from then on, so they don’t need to break in over and over again to keep their evil eyes on you.
• EoP means Elevation of Privilege. As mentioned above, this means crooks can boost their access rights, typically acquiring the same sort of powers that an official sysadmin or the operating itself would usually enjoy. Once they have system-level powers, they are often able to roam freely on your network, steal secure files even from restricted-access servers, create hidden user accounts for getting back in later, or map out your entire IT estate in preparation for a ransomware attack.
• Leak means that security-related or private data might escape from secure storage. Sometimes, even apparently minor leaks, such as the location of specific operating system code in memory, which an attacker isn’t supposed to be able to predict, can give criminals the information they need to turn an probably unsuccessful attack into an almost certainly successful one.
• Bypass means that a security protection you’d usually expect to keep you safe can be skirted. Crooks typically exploit bypass vulnerabilities to trick you into trusting remote content such as email attachments, for example by finding a way to avoid the “content warnings” or to circumvent the malware detection that are supposed to keep you safe.
• Spoof means that content can be made to look more trustworthy than it really is. For example, attackers who lure you to a fake website that shows up in your browser with an official server name in the address bar (or what looks like the address bar)are much likely to trick you into handing over personal data than if they’re forced to put their fake content on a site that clearly isn’t the one you’d expect.
• DoS means Denial of Service. Bugs that allow network or server services to be knocked offline temporarily are often considered low-grade flaws, assuming that the bug doesn’t then allow attackers to break in, steal data or access anything they shouldn’t. But attackers who can reliably take down parts of your network may be able to do so over and over again in a co-ordinated way, for example by timing their DoS probes to happen every time your crashed servers restart. This can be extremely disruptive, esepcially if you are running an online business, and can also be used as a distraction to draw attention away from other illegal activities that the crooks are doing on your network at the same time.

The big bug list

The 75-strong bug list is here, with the three zero-days we know about marked with an asterisk (*):

NIST ID Level Type Component affected
--------------- ----------- ------ ----------------------------------------
CVE-2023-21689: (Critical) RCE Windows Protected EAP (PEAP) CVE-2023-21690: (Critical) RCE Windows Protected EAP (PEAP) CVE-2023-21692: (Critical) RCE Windows Protected EAP (PEAP) CVE-2023-21716: (Critical) RCE Microsoft Office Word CVE-2023-21803: (Critical) RCE Windows iSCSI CVE-2023-21815: (Critical) RCE Visual Studio CVE-2023-23381: (Critical) RCE Visual Studio CVE-2023-21528: (Important) RCE SQL Server CVE-2023-21529: (Important) RCE Microsoft Exchange Server CVE-2023-21568: (Important) RCE SQL Server CVE-2023-21684: (Important) RCE Microsoft PostScript Printer Driver CVE-2023-21685: (Important) RCE Microsoft WDAC OLE DB provider for SQL CVE-2023-21686: (Important) RCE Microsoft WDAC OLE DB provider for SQL CVE-2023-21694: (Important) RCE Windows Fax and Scan Service CVE-2023-21695: (Important) RCE Windows Protected EAP (PEAP) CVE-2023-21703: (Important) RCE Azure Data Box Gateway CVE-2023-21704: (Important) RCE SQL Server CVE-2023-21705: (Important) RCE SQL Server CVE-2023-21706: (Important) RCE Microsoft Exchange Server CVE-2023-21707: (Important) RCE Microsoft Exchange Server CVE-2023-21710: (Important) RCE Microsoft Exchange Server CVE-2023-21713: (Important) RCE SQL Server CVE-2023-21718: (Important) RCE SQL Server CVE-2023-21778: (Important) RCE Microsoft Dynamics CVE-2023-21797: (Important) RCE Windows ODBC Driver CVE-2023-21798: (Important) RCE Windows ODBC Driver CVE-2023-21799: (Important) RCE Microsoft WDAC OLE DB provider for SQL CVE-2023-21801: (Important) RCE Microsoft PostScript Printer Driver CVE-2023-21802: (Important) RCE Microsoft Windows Codecs Library CVE-2023-21805: (Important) RCE Windows MSHTML Platform CVE-2023-21808: (Important) RCE .NET and Visual Studio CVE-2023-21820: (Important) RCE Windows Distributed File System (DFS) CVE-2023-21823: (Important) *RCE Microsoft Graphics Component
CVE-2023-23377: (Important) RCE 3D Builder CVE-2023-23378: (Important) RCE 3D Builder CVE-2023-23390: (Important) RCE 3D Builder CVE-2023-21566: (Important) EoP Visual Studio CVE-2023-21688: (Important) EoP Windows ALPC CVE-2023-21717: (Important) EoP Microsoft Office SharePoint CVE-2023-21777: (Important) EoP Azure App Service CVE-2023-21800: (Important) EoP Windows Installer CVE-2023-21804: (Important) EoP Microsoft Graphics Component CVE-2023-21812: (Important) EoP Windows Common Log File System Driver CVE-2023-21817: (Important) EoP Windows Kerberos CVE-2023-21822: (Important) EoP Windows Win32K CVE-2023-23376: (Important) *EoP Windows Common Log File System Driver CVE-2023-23379: (Important) EoP Microsoft Defender for IoT CVE-2023-21687: (Important) Leak Windows HTTP.sys CVE-2023-21691: (Important) Leak Windows Protected EAP (PEAP) CVE-2023-21693: (Important) Leak Microsoft PostScript Printer Driver CVE-2023-21697: (Important) Leak Internet Storage Name Service CVE-2023-21699: (Important) Leak Internet Storage Name Service CVE-2023-21714: (Important) Leak Microsoft Office CVE-2023-23382: (Important) Leak Azure Machine Learning CVE-2023-21715: (Important) *Bypass Microsoft Office Publisher CVE-2023-21809: (Important) Bypass Microsoft Defender for Endpoint CVE-2023-21564: (Important) Spoof Azure DevOps CVE-2023-21570: (Important) Spoof Microsoft Dynamics CVE-2023-21571: (Important) Spoof Microsoft Dynamics CVE-2023-21572: (Important) Spoof Microsoft Dynamics CVE-2023-21573: (Important) Spoof Microsoft Dynamics CVE-2023-21721: (Important) Spoof Microsoft Office OneNote CVE-2023-21806: (Important) Spoof Power BI CVE-2023-21807: (Important) Spoof Microsoft Dynamics CVE-2023-21567: (Important) DoS Visual Studio CVE-2023-21700: (Important) DoS Windows iSCSI CVE-2023-21701: (Important) DoS Windows Protected EAP (PEAP) CVE-2023-21702: (Important) DoS Windows iSCSI CVE-2023-21722: (Important) DoS .NET Framework CVE-2023-21811: (Important) DoS Windows iSCSI CVE-2023-21813: (Important) DoS Windows Cryptographic Services CVE-2023-21816: (Important) DoS Windows Active Directory CVE-2023-21818: (Important) DoS Windows SChannel CVE-2023-21819: (Important) DoS Windows Cryptographic Services CVE-2023-21553: (Unknown ) RCE Azure DevOps 

What to do?

Business users like to prioritise patches, rather than doing them all at once and hoping nothing breaks; we therefore put the Critical bugs at the top, along with the RCE holes, given that RCEs are typically used by crooks to get their initial foothold.

In the end, however, all bugs need to be patched, especially now that the updates are available and attackers can start “working backwards” by trying to figure out from the patches what sort of holes existed before the updates came out.

Reverse engineering Windows patches can be time-consuming, not least because Windows is a closed-source operating system, but it’s an awful lot easier to figure out how bugs work and how to exploit them if you’ve got a good idea where to start looking, and what to look for.

The sooner you get ahead (or the quicker you catch up, in the case of zero-day holes, which are bugs that the crooks found first), the less likely you’ll be the one who gets attacked.

So even if you don’t patch everything at once, we’re nevertheless going to say: Don’t delay/Get started today!

READ THE SOPHOSLABS ANALYSIS OF PATCH TUESDAY FOR MORE DETAILS

Apple has just released updates for all supported Macs, and for any mobile devices running the very latest versions of their respective operating systems.

In version number terms:

• iPhones and iPads on version 16 go to iOS 16.3.1 and iPadOS 16.3.1 respectively (see HT213635).
• Apple Watches on version 9 go to watchOS 9.3.1 (no bulletin).
• Macs running Ventura (version 13) go to macOS 13.2.1 (see HT213633).
• Macs running Big Sur (version 11) and Monterery (12) get an update dubbed Safari 16.3.1 (see HT213638).

Oh, and tvOS gets an update, too, although Apple’s TV platform confusingly goes to tvOS 16.3.2 (no bulletin).

Apparently, tvOS recently received a product-specific functionality fix (one listed on Apple’s security page with no information beyond the sentence This update has no published CVE entries, implying no reported security fixes) that already used up the version number 16.3.1 for Apple TVs.

As we’ve seen before, mobile devices still using iOS 15 and iOS 12 get nothing, but whether that’s because they’re immune to this bug or simply that Apple hasn’t got round to patching them yet…

…we have no idea.

We’ve never been quite sure whether this counts as a telltale of delayed updates or not, but (as we’ve seen in the past) Apple’s security bulletin numbers form an intermittent integer sequence. The numbers go from 213633 to 213638 inclusive, with a gap at 213634 and gaps at 213636 and 213637. Are these security holes that will get backfilled with yet-to-be-released patches, or are they just gaps?

What sort of zero-day is it?

Given that the Safari browser has been updated on the pre-previous and pre-pre-previous versions of macOS, we’re assuming that older mobile devices will eventually receive patches, too, but you’ll have to keep your eyes on Apple’s official HT201222 Security Updates portal to know if and when they come out.

As mentioned in the headline, this is another of those “this smells like spyware or a jailbreak” issues, given that the all updates for which official documentation exists include patches for a bug denoted CVE-2023-23529.

This security hole is a flaw in Apple’s WebKit component that’s described as Processing maliciously crafted web content may lead to arbitrary code execution.

The bug also receives Apple’s usual euphemism for “this is a zero-day hole that crooks are already abusing for evil ends, and you can surely imagine what those might be”, namely the words that Apple is aware of a report that this issue may have been actively exploited.

Remember that WebKit is a low-level operating system component that’s responsible for processing data fetched from remote web servers so that it can be displayed by Safari and many other web-based windows programmed into hundreds of other apps.

So, the words arbitrary code execution above really stand for remote code execution, or RCE.

Installjacking

Web-based RCE exploits generally give attackers a way to lure you to a booby-trapped website that looks entirely unexceptionable and unthreatening, while implanting malware invisibly simply as a side-effect of you viewing the site.

A web RCE typically doesn’t provoke any popups, warnings, download requests or any other visible signs that you are initiating any sort of risky behaviour, so there’s no point at which attacker needs catch you out or to trick you into taking the sort of online risk that you’d normally avoid.

That’s why this sort of attack is often referred to as a drive-by download or a drive-by install.

Just looking at a website, which ought to be harmless, or opening an app that relies on web-based content for any of its pages (for example its splash screen or its help system), could be enough to infect your device.

Remember also that on Apple’s mobile devices, even non-Apple browsers such as Firefox, Chrome and Edge are compelled by Apple’s AppStore rules to stick to WebKit.

If you install Firefox (which has its own browser “engine” called Gecko) or Edge (based on a underlying layer called Blink) on your Mac, those alternative browsers don’t use WebKit under the hood, and therefore won’t be vulnerable to WebKit bugs.

(Note that this doesn’t immunise you from security problems, given that Gecko and Blink may bring along their own additional bugs, and given that plenty of Mac software components use WebKit anyway, whether you steer clear of Safari or not.)

But on iPhones and iPads, all browsers, regardless of vendor, are required to use the operating system’s own WebKit substrate, so all of them, including Safari, are theoretically at risk when a WebKit bug shows up.

What to do?

If you have an Apple product on the list above, do an update check now.

That way, if you’ve already got the update, you’ll reassure yourself that you’re patched, but if your device hasn’t got to the front of the download queue yet (or you’ve got automatic updates turned off, either by accident or design), you’ll be offered the update right away.

On a Mac, it’s Apple menu > About this Mac > Software Update… and on an iDevice, it’s Settings > General > Software Update.

If your Apple product isn’t on the list, notably if you’re stuck back on iOS 15 or iOS 12, there’s nothing you can do right now, but we suggest keeping an eye on Apple’s HT201222 page in case your product is affected and does get an update in the next few days.

As you can imagine, given how strictly Apple locks down its mobile products to stop you using apps from anywhere but the App Store, over which it exerts complete commercial and technical control…

…bugs that allow rogues and crooks to inject unauthorised code onto Apple phones are highly sought after, given that RCEs are about the only reliable way for attackers to hit you up with malware, spyware or any other sort of cyberzombie programming.

Which gives us a good reason, as always, to say: Don’t delay/Do it today.

Last week, we wrote about a bunch of memory management bugs that were fixed in the latest security update of the popular OpenSSL encryption library.

Along with those memory bugs, we also reported on a bug dubbed CVE-2022-4304: Timing Oracle in RSA Decryption.

In this bug, firing the same encrypted message over and over again at a server, but modifying the padding at the end of the data to make the data invalid, and thus provoking some sort of unpredictable behaviour…

…wouldn’t take a consistent amount of time, assuming you were close to the target on the network that you could reliably guess how long the data transfer part of the process would take.

Not all data processed equally

If you fire off a request, time how long the answer takes, and subtract the time consumed in the low-level sending-and-receiving of the network data, you know how long the server took to do its internal computation to process the request.

Even if you aren’t sure how much time is used up in the network, you can look for variations in round-trip times by firing off lots of requests and collecting loads of samples.

If the network is reliable enough to assume that the networking overhead is largely constant, you may be able to use statistical methods to infer which sort of data modification causes what sort of extra processing delay.

From this, you many be able to infer something about the the structure, or even the content, of the original unencrypted data that’s supposed to be kept secret inside each repeated request.

Even if you can only extract one byte of plaintext, well, that’s not supposed to happen.

So-called timing attacks of this sort are always troublesome, even if you might need to send millions of bogus packets and time them all to have any chance of recovering just one byte of plaintext data…

…because networks are faster, more predictable, and capable of handling much more load than they were just a few years ago.

You might think that millions of treacherous packets spammed at you in, say, the next hour would stand out like a sort thumb.

But “a million packets an hour more or less than usual” simply isn’t a particularly large variation any more.

Similar “oracle” bug in GnuTLS

Well, the same person who reported the fixed-at-last bug timing bug in OpenSSL also reported a similar bug in GnuTLS at about the same time.

This one has the bug identifier CVE-2023-0361.

Although GnuTLS isn’t quite as popular or widely-used as OpenSSL, you probably have a number of programs in your IT estate, or even on your own computer, that use it or include it, possibly including FFmpeg, GnuPG, Mplayer, QEMU, Rdesktop, Samba, Wget and Wireshark.

Ironically, the timing flaw in GnuTLS appeared in code that was supposed to log timing attack errors in the first place.

As you can see from the code difference (diff) below, the programmer was aware that any conditional (if ... then) operation used in checking and dealing with a decryption error might produce timing variations, because CPUs generally take a different amount of time depending on which way your code goes after a “branch” instruction.

(That’s especially true for a branch that often goes one way and seldom the other, because CPUs tend to remember, or cache, code that runs repeatedly in order to improve performance, thus making the infrequently-taken code run detectably slower.)

But the programmer still wanted to log that an attack might be happening, which happens if the if (ok) test above fails and branches into the else { ... } section.

At this point, the code calls the _gnutls_debug_log() function, which could take quite a while to do its work.

Therefore the coder inserted a deliberate call to _gnutls_no_log() in the then { ... } part of the code, which pretends to log an “attack” when there isn’t one, in order to try to even up the time that the code spends in either direction that the if (ok) branch instruction can take.

Apparently, however, the two code paths were not sufficiently similar in the time they used up (or perhaps the _gnutls_debug_log() function on its own was insufficiently consistent in dealing with different sorts of error), and an attacker could begin to distinguish decryption telltales after a million or so tries.

What to do?

If you’re a programmer: the bug fix here was simple, and followed the “less is more” principle.

The code in pink above, which was deemed not to give terribly useful attack detection data anyway, was simply deleted, on the grounds that code that’s not there can’t be compiled in by mistake, regardless of your build settings…

…and code that’s not compiled in can never run, whether by accident or design.

If you’re a GnuTLS user: the recently-released version 3.7.9 and the “new product flavour” 3.8.0 have this fix, along with various others, included.

If you’re running a Linux distro, check for updates to any centrally-managed shared library version of GnuTLS you have, as well as for apps that bring their own version along.

On Linux, search for files with the name libgnutls*.so to find any shared libraries lying around, and search for gnutls-cli to find any copies of the command line utility that’s often included with the library.

You can run gnutls-cli -vv to find out which version of libgnutls it’s dynamically linked to:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- my Linux distro got the update last Friday (2023-02-10)

Popular social media site Reddit – “orange Usenet with ads”, as we’ve somewhat ungraciously heard it described – is the latest well-known web property to suffer a data breach in which its own source code was stolen.

In recent weeks, LastPass and GitHub have confessed to similar experiences, with cyercriminals apparently breaking and entering in much the same way: by figuring out a live access code or password for an individual staff member, and sneaking in under cover of that individual’s corporate identity.

In Reddit’s own words:

Reddit systems were hacked as a result of a sophisticated and highly-targeted phishing attack. They gained access to some internal documents, code, and some internal business systems.

We’re not sure quite how suitable the adjective “sophisticated” is here, not least because Reddit quickly goes on to state that:

As in most phishing campaigns, the attacker sent out plausible-sounding prompts pointing employees to a website that cloned the behavior of our intranet gateway, in an attempt to steal credentials and second-factor tokens.

After successfully obtaining a single employee’s credentials, the attacker gained access to some internal docs, code, as well as some internal dashboards and business systems. We show no indications of breach of our primary production systems (the parts of our stack that run Reddit and store the majority of our data).

In other words, this attack almost certainly succeeded not because it was sophisticated, but because it wasn’t.

Someone, perhaps in a hurry, arrived at what they thought was the frontier, handed over their passport to a fellow-traveller instead of to an official border agent, and then found themselves trapped in nowhere-land without any ID while the imposter sailed through the border crossing in their name.

The single most important factor in an identity-hijacking attack of this sort is not sophistication but, as Reddit rightly pointed out above, plausibility, making it easy even for well-informed and cautious individuals to “coast through” based on habit and experience.

The risk posed by habitual behaviour is why official British road signage includes a bright red rectangle containing the words NEW ROAD LAYOUT AHEAD that’s used when a busy piece of road gets reorganised. The sign isn’t there to protect old-timers from nervous new road users who might find a big junction or roundabout complicated. It’s there to protect those new users, who have no choice but to work cautiously from first principles, and are therefore likely follow the road rules just fine, from old-timers who think they “know” how traffic will behave at that location, and therefore sail through carelessly, based on incorrect assumptions and “learned-but-now-improper” behaviour.

How far did the crooks get?

As already stated, some of Reddit’s own internal systems were accessed by the attackers.

In addition to the mostly-harmless-sounding “docs” and “code” listed above, Reddit has admitted that information about past and present employees and “contacts” (we’re assuming this includes, but is not limited to, contractors and other non-permanent staffers) was stolen, along with information about advertising customers.

Reddit hasn’t stated publicly what sort of data fields were included in the stolen information, merely that the breach was “limited”.

But the word limited might be a good sign (e.g. name and email address, and no other data), but could just as easily be a bad thing (e.g. “only” two data items: your social security number and a scan of your driving licence).

Signed-up users of the Reddit service, it seems – Redditors, as they as known – can stand down from Blue Alert, with Reddit saying that its investigation so far shows no indication that what it calls “non-public data” (in other words, stuff that you didn’t post for the world to see anyway) was accessed by the cybercriminals.

And, as mentioned earlier, the Reddit systems themselves – the operating systems, code and networks that run the Reddit services you interact with, whether as a user or a visitor – don’t seem to have been breached.

From this, we infer that the crooks are unlikely to have made off with data such as login records, system logs, location information or password hashes.

The company also stated, in its notification, that it is still investigating this incident (which happened on Sunday 2023-02-05).

Given its reasonably quick response so far, we’re guessing that Reddit will follow up in due course to say whether it found any further evidence of compromise.

What to do?

To be honest, unless you’re a Reddit staffer or advertiser, it doesn’t look as though there’s much you can or need to do right now.

(We’re assuming, if you do work for or advertise with Reddit, that the company will already have contacted you personally if your data was amongst the “limited” information stolen, which we would consider a better short-term response than telling the whole world first.)

Reddit itself has made three suggestions, namely:

• Protect against phishing by using a password manager. This makes it harder to put the right password into the wrong site, because the password manager isn’t deceived by the look-and-feel of a site, but works unemotionally with the exact name of the web page it sees in the address bar. Ironically, this seems to be advice that Reddit itself didn’t follow, given that the attackers used a plausible look-alike site to steal login credentials, which a password manager would presumably have rejected as unknown.
• Turn on 2FA if you can. This means you need a one-time code that changes at every login, which makes a stolen password useless on its own. We agree that this is a great idea, but note that Reddit’s own mechanism for 2FA (two-factor authentication), based on a regularly-changing six-digit code generated by an app on your phone, apparently didn’t help here, because the attackers phished both a current password and a valid-right-now 2FA code.
• Change your passwords every two months. We disagree with this advice, as does the US National Institute of Standards and Technology (NIST). Change for change’s sake is rarely a good idea, because it tends to enforce habitual behaviour that, in the words of Naked Security friend and colleague Chester Wisniewski, “gets everybody in the habit of a bad habit“.

BUSTING PASSWORD MYTHS

Even though we recorded this podcast more than a decade ago, the advice it contains is still relevant and thoughtful today. We haven’t hit the passwordless future yet, so password-related cybersecurity advice will be valuable for a good while yet. Listen here, or click through for a full transcript.

In short: we continue to recommend password managers, especially if you tend to drift into the habit of picking obvious, identical or even similar passwords for multiple sites without one.

We also recommend password managers as a helpful tool for pulling you up short on imposter sites that look visually perfect to you, but that don’t match the plain and emotionless expectations of your password manager.

And we advise you to turn on 2FA wherever you can, even though we know it’s a bit of a hassle.

We nevertheless remind you that 2FA codes (such as those one-time 6-digit SMS or app-based messages) can still be phished, as happened here to Reddit, so they are not a cure-all for caution.

But we don’t agree with forcing yourself regularly to change all your passwords on an algorithmic basis.

Much better to change your passwords right away whenever you genuinely think it’s worth doing so, than to rely on “I’ll be changing it sometime soon anyway, so I’ll just wait until the process tells me to do it.”

(We’re not saying you mustn’t change your passwords all the time if that makes you happy, but doing it as what you might call a “procedural requirement” will give you a false sense of security, and uses up time you could spend on other tasks that directly improve your online safety.)

As we’ve said before, we may be heading towards a passwordless future, but we suspect we’ll all be juggling passwords for at least some important online service for many years yet.

CAN YOU GET HACKED AND THEN PROSECUTED FOR IT?

Cryptocurrency crimelords. Security patches for VMware, OpenSSH and OpenSSL. Medical breacher busted. Is that a bug or a feature?

With Doug Aamoth and Paul Ducklin

Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT