The answer is obviously to require all users to change their passwords and make them stronger. 26 minimum characters; two capitals, two numbers, two special characters, cannot include ‘_’, ‘b’ or the number ‘8’, and most include Pi to the 6th place.
Great! Now when I brute force the login, I can tell my program to not waste time trying ‘_’, ‘b’ and ‘8’ and add Pi to the 6th place in every password, along with 2 capitals, 2 numbers and 2 other special characters.
Furthermore, I don’t need to check passwords with less than 26 characters.
Sorry, I don’t understand. Do you mean there have to be 6 digits of Pi in there, or the sixth character must be π? I’m down either way.
We won’t tell you, and the rule gets re-rolled every 14 seconds. It may stay the same or it may change.
The modern direction is actually going the other way. Tying identity to hardware, preventing access on unapproved or uncompliant hardware. It has the advantage of allowing biometrics or things like simple pins. In an ideal world, SSO would ensure that every single account, across the many vendors, have these protections, although we are far from a perfect world.
SSO means you only need to compromise one piece of hardware to get access to everything.
Effectively, the other option is passwords, and people are really, really, bad at passwords. Password managers help, but then you just need to compromise the password manager. Strong SSO, backed by hardware, at least makes the attack need to be either physical, or running on a hardware approved by the company. When you mix that with strong execution protections, an EDR, and general policy enforcement and compliance checking, you get protection that beats the pants off 30 different passwords to 30 different sites, or more realistically, 3 passwords to 30 different sites.
