I think it's worth mentioning what the attack surfaces are for passwords so people can better understand the implications of a password choice.
There are basically 5 ways that a bad actor a can use a password to breach a system.
1: The lucky guess. This is up there with the "try her cats name!" line of thinking. It's rare that it works, but then the number of companies I've found in this country with "samenwerken" as their wifi password (Dutch for working together) amazes me. Having a longer password largely mitigates this one.
2. Brute forcing. This is where you have a tool that will automatically try lots of different user name and password combinations until one works. This is not easy to pull off, and unless you have a very weak password on a system with an obvious to guess user name, it's not going to easy to pull off. Think a root password of password. This is largely mitigated against by having systems that throttle the number of tries you can make. Think of what happens on your phone if you put the wrong code in several times in a row. It says come back in 5 mins and try again. This provides for a certain amount of protection, but if your password is too weak, it's gonna get worked out eventually. Just making the password longer, can also mitigate most of this one.
3. Hash cracking. Rather than grabbing the password from the end user, you get it from the system that you want to compromise. If for example, i was to hack into yacf, and grab the user database with all the usernames and passwords (I'm not, don't worry), I can then look at those user names and passwords, and maybe be lucky that if a user used "banana" as their password for yacf, they also use that for their email, or their bank. Now, detail for those of you who aren't computer security nerds. On a well designed system a password should never be stored as simply the clear text of the password. Say my password is banana, the system I am logging in should never have "password = banana" in it's storage. What should happen is it is stored as a hash. This is a one way function that for a given input always produces the same result. You don't need to know any more detail than that to understand that password in -> hash function -> hash out. Sticking with banana as a password, and using the very common (tho not recommended for current systems) md5 hash, it produces "df3e129a722a865cc3539b4e69507bad". If we store that string in the system, and then when I want to login, I type banana on my system, it hashes it, and then the hashes are compared. The problem with this i comparing hashes is actually pretty easy, computationally. You can easily for not much money have a machine with a list of common words, and their hash, and then you compare the two. Realising that this makes it too easy to crack a password, modern systems do what's called salting the password. This is mixing the password with a predefined extra thingy, the salt. The salt can be stored in plain text along with the password hash (in fact kinda needs to be). A common salt is the user name. So say I am user1 and my password is banana, my salted hash becomes "9706e16132ea63848757424b5c92ad96". Why is this important? Because it means I can't precompute my hashes. So rather than comparing a list of hashes for common passwords, I have to compute for each password, the hash of it's salt and password. This is computationally more expensive. And how expensive goes up dramatically the longer the password is. The thing is, computing power is dirt cheap these days. You can get a GPU based machine in the cloud for pennies per hour, and apply that to a password hash, and for the price of a half decent bike, you can probably crack the password. Cost effective if there's money to be had.
It is in this area that the more complex your password, the harder it is to crack, and the more expensive it is. The aim is to make it too expensive for someone to bother. A 20+ character password is approaching the point it's not cost effective unless a lot of money is involved. I have one password that is 99 characters long. That's gonna take a long time to crack. The balance here is trying to come up with a long password that can be managed by the user, but also is secure. Correct hose battery staple is one approach, just using a password manager, and copy pasta is another. Each has pros and cons.
"But how am I expected to remember a 40 character passphrase?" people ask.
Humans have for millennia passed down information by memory and spoken language. People remember poems, and lyrics, and can quote whole sections of films and tv. Take these approaches and use them. Rhyming can help, using the first sentence of the 3rd paragraph of a book on your desk, use a list of the last 5 winners of Paris Roubaix. It's a lot easier for someone to remember a sentence or collection of words, than it is for them to remember CexsrrAPXiQg.
4. Phishing. If you can trick someone to entering their password into a fake site, you can then use that for the genuine one, an you have access. This is largely mitigated through awareness, and good 2FA. Sure you may have my username and my password, but without my yubikey, you're getting nowhere. Phishing is devastatingly effective, but simply making a password longer or full of symbols and numbers, doesn't defend against phishing. Good 2FA is the only way. TOTP (i.e. google authenticator), or SMS, is not good enough for this. We're talking TPM or yubikey as the only good options.
5. Ask. You would be amazed how often the best way to get someone's password is just to ask them. This is kinda a subset of phishing, but more blatant.
Soooo, what does this all mean in the context of going passwordless, as was originally suggested. Well if we use things like a yubikey, then it can do all sorts of cryptography and fancy hashing to do the authentication, meaning we don't have to. And because the yubikey is doing the authentication for you, you only need to unlock the yubikey. Which given that it's in your pocket most of the time, is a lot harder to brute force. *AND* you have to touch it every time you want to authenticate. So sure your pin can be 1234, and that means you only need 9999 guesses to find it. But you also need to trick the end user into touching the yubikey 9999 times when it's plugged in, and not being used for an intended authentication. That's a big ask.
J
