Is that the case with all of these hacks? How many would be prevented, is what I'm wondering? My mother's hospital was hacked this week and now they can't even clock in but they're not running SCADA

SCADA's a good example of systems that are difficult to secure for complex reasons. There are many others.

You ask a very wise question. Unfortunately, I think it's unknownable. The best we know is that the answer is more than none and less than all. The more you get towards "all" the more prevention measures cost to implement. For instance, managing a mature backup and imaging operation at scale may be conceptually simple but is both complex in practice and far from free.

Hospitals in particular are the scene of some interesting conflicts between security and usability. There are a lot of stories about health staff doing things like jamming open medication dispensing machines so that they could get on with the job instead of dealing with security measures they experienced largely as obstacles.

Can you imagine throwing yubikeys into a scenario like that, where people already have an adversarial relationship with IT and security measures? What do you think is going to happen when someone forgets their key and can't send an x-ray to the remote radiology center? I have my guesses.

Adversarial relationship with security are very often created by very annoying security requirements which do very little to improve security. Like requiring users to change all passwords ever 2 or 3 months and requiring a new password to have characters from every class (see also [1]). While all you need in the most cases is just minimum length requirement and some guidance how to choose a good password.

If user will have to enter 16 charter password each time after HW key (like Yubikey) will be connected to a computer to unlock it, then users will leave it always inserted. Or password will be saved in a text file. If HW key will just work once inserted (or will require 4 digit pin) most users will comply. It is already 2nd factor in addition to some other password, it doesn't necessary need a strong password to use it.

[1] https://passwordfromhell.com/

Leaving a key inserted is still a vast improvement over the current situation. Yubikeys have to be pressed to generate a new code each time (as they expire after each use) and the situation you avoid is remote hacking especially via social engineering.

Not all u2f keys require being touched. That's an optional hardware implementation detail, rather than a mandatory trait across all u2f devices. Yubikey sells keys that are commonly used by plugging them in, leaving them, and never again touching them. This effectively turns the computer itself into the second factor.

Depending on the precise scenario, that may or may not represent an improvement. If the key is used as a second factor to authenticate to the network, then an infected Excel document will trivially ignore the involvement of a Yubikey as it uses the logged-in user's Kerberos ticket to spread.

You're completely right, though. Even this would definitely cut down on phishing attacks that send users to fake websites pretending to be internal systems.

We first start by moving all the non legacy stuff to MFA. There are so many easy targets in security that we can look in to first before declaring it impossible because of a handful of legacy apps.

You're absolutely right. There's often no shortage of low hanging fruit.

I'm not suggesting we should declare anything impossible. Far from it! I'm merely trying to suggest that we should appreciate that not all things as easily fixed as they may seem at first blush.

As all of us in software know, complexity can lurk in unexpected places.