Roll for Security

Password Rant

2026-10-08

Your passwords suck and I can mathmatically prove it

Okay, maybe not YOUR passwords, dear reader, but the vast majority of passwords do. In fact the concept of passwords is pretty bad. But like democracy, it is the best of a bad system.

The average person has difficulty remembering lots of different passwords so they don’t. They use one. Maybe they have a “base” password that they apply some “transformation” to that they can then have 3 or 4 different passwords for all their accounts. I do not know about you, but I have something like 30-40 accounts for work, and 40-50 accounts for personal use. Everything needs a stupid account. Sure the bank make sense. My mastodon account. But for health insurance there’s like 3 different portals, then each of the doctor’s offices has a portal, then you end up with like 10 accounts just to go to the doctor and get some medicine.

Password managers help with this but not much. The cognitive burden of adding a new piece of software, a new workflow to creating and managing accounts, and remembering to get it on all your devices, potentially paying a subscription, and so on is difficult for people. Even people who should know better. So people stick with their far too short, far too easy to guess and far too reused passwords. In addition to this, you can still do everything right, generating unique long random passwords for all 6 billion accounts you have and you can still be beaten. Wily thieves phish you, or site admins fail to secure their stuff and attackers abscond with your accounts anyway.

Education, awareness, and better computer literacy can only take us so far. I am strongly advocate that like with reading, we should be encouraging people to become more computer literate but the answer should not be that everyone just has to become expert IT System Administrators and Cybersecurity Gurus to safely use computers in 2026. Because as previously mentioned, that sometimes still is not good enough.

It is clear that in cybersecurity, there is a culture of “toxic max security” that ends up confusing or being extradinorily difficult for the average person. Before the new NIST password requirements (which I will get into here), the 8-character minimum, at least 1 uppercase letter, 1 lowercase letter, a special character, your favorite character from Gilligan’s Island, the current phase of the moon, your dog’s birthday (but not that date, that one is reserved), so on and so forth password policies drove people crazy. And with forced periodic rotation, people default to as simple of a password that meets those requirements as possible. This ends up creating the exact ruleset that allows dasterdly computer-burglars to craft hashcat masking rules and construct rainbow tables of common patterns in common hashing schemes that allow them to more quickly and efficiently crack passwords than ever before!

It is easy for a security practioner to look at a set of requirements and go “Ah Ha! We require 12 character minimums, complexity (1 uppercase, 1 lowercase, 1 number, and 1 special character, but remember if you just use the built-in Windows password GPO, you only need 3 of 4) and we allow all standard keyboard characters. Putting that into the Password entropy formula gets us the following: (95)log2(12) or ~78 bits. That would take 200 million years to guess all the passwords if attackers could guess 10 million passwords a second!”. This is the naive take.

First off, that 78 bits of entropy are if each and every one of the passwords are completely random and equally likely. They are not. Second, attackers with modern GPU password cracking rigs can hit billions of passwords per second. The costs of certain scales of attacks are dropping (as long as the hardware is available that is!). Even far more complicated hashing schemes, attackers can brute force well over 100,000 hashes per second that a decade ago would have taken high end rigs and server farms of the day minutes to do. Third, as mentioned previously, users pick terrible passwords. Users reuse passwords. User passwords get leaked in data breaches and hacks that happen left and right. The attackers do not even have to guess, they instantly get access. But even if your users do not reuse passwords ever, they still follow common enough patterns that you do not need to iterate through the whole quadrillions and quadrillions of possible combinations. You just write a hashcat mask that meets all the password requirements. And at organizations with enough users, they only need one hit really. 1,000 accounts is 1,000 possible dice rolls where the user ends up using an easily guessible or already leaked password.

If I have not made my point clear, just looking at password entropy is not the complete story. Helpful to gauge some aspects of crafting a password policy but again, not fully realistic for how password cracking works. There is not a lot of brute forcing. The top 10,000 is enough in most cases, and by having a vary particular set of password rules, you help the attackers craft the hashcat rules necessary if they want to go that route.

New NIST Requirements

NIST 800-63

Long and short of it:

Require minimum of 15 characters (change from 8)

Recommends Multi-factor authentication

SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords. (change from requiring upper, lower, specials, and numbers in all passwords)

SHALL NOT require subscribers to change passwords periodically (change from forced password rotation recommendations). However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.

No more security questions or hints allowed, among some other details

These new recommendations were published alongside the NIST Cybersecurity Framework 2.0. As my company has adopted the NIST CSF 2.0 as our guiding cybersecurity framework, I set about developing a new password policy that matches the requirements laid out in NIST 800-63.

What I did at my work

“In place of the Dark LordPassword Policy you will set up a Queena different Password Policy. …All shall love me and despair!

There are no rules. Well no actually, there are a lot of rules. It is actually quite complicated to fully explain, but long story short, if you meet the minimum criteria, you could have a 15 digit number string as your password. Or 15 lowercase letters. Technically I think 15 exclamation marks (!!!!!!!!!!!!!!!) could be possible. That is not a good password, but completely within the ruleset.

The ultimate goal of the new password policy that I implemented was to eliminate the possibility of the top 10,000 terrible passwords that those damnible rapscalions that seek to ruin your day, utilize. The ones from known breaches, common passwords, and things far too easy to guess. The true strength of the password policy comes from its ability to balance two separate needs. Ease in which users can craft easy to remember and hard to guess passwords. Easy to remember requires giving users more freedom and less arbitrary rules. Hard to guess requires preventing them from doing certain things. It is this prevention that makes the rules complicated. But have no fear dear reader, once a user crafts a solid password in my environment, I do not require them to change it. Only if they want to (or we suspect that some scoundral has absconded with their account).

Our Requirements are thusly:

15-character minimum

Password cannot contain username

Password cannot be too similiar to previous 24 passwords

Password cannot use any of the banned words (Company name, address, States, Sports teams, Months, etc.)

Password has at least 1 lowercase character

Password has at least 1 uppercase character

Password has at least 1 number

Password has at least 1 special character

Password cannot be part of the HaveIBeenPwned breach password list (checks hash against top 10,000)

But the only truly mandatory requirements are the first and last ones. At least 15 characters long, and not on the HIBP list. They have to otherwise meet 4 out of the other 7 requirements. If you don’t use your username in your password, don’t repeat a previous password, don’t use any of the banned words, then you already meet 3 out 4 of those requirements. Meaning you just need some kind of 15-character string. Whatever you want. 30 spaces and the letter ‘Q’. A sentence, a poem, a song, whatever. Standard L33t Sp3@k, sure. Do whatever you want as long as it passes the HIBP check.

But still, because of the GINA integration with the tooling we have to implement this fine grained password controls (Microsoft why do not have a better password policy system for Windows? It’s been like 25 years!), users are presented with all the different requirements, that they only need to meet 4 of technically, but they see the red X’s and build “fully compliant” passwords that they say are down right novels to have to type in. 15 characters, a novel!

The math however, is strongly in favor of longer passwords. And starting at 15-characters, this unlocks a lot of special properties.

First, if for whatever reason you still have LANMAN in your environment (Look I work in manufacturing, I understand), 14 character or less passwords get LANMAN hashes. 15-characters plus, do not. It is possible to generate a complete LANMAN rainbow table for all possible hashes for all password lengths and fit that on a single computer. It would be dozens of TB’s in size but it would allow you to instantly crack any LANMAN hashed password in a second. Read more about why LANMAN hashes and sub-15 character passwords are a bad idea here: https://cromwell-intl.com/cybersecurity/password-breaking.html

And secondly, looking at research provided by Hive Systems, we can see that modern password cracking techniques still are no match against long passwords.

Hive Systems are an MSSP with 6 years of publishing their password cracking research. I don’t swear by the methodology, but like Backblaze, they publish a report on their efforts that is at least illustrative and helpful for demonstrating my point here.

And according to their chart, the full entropy space of a 15-character, all lowercase letters password would be iterated through in roughly 383 million years using their rig. 229 years for a 15 numbers only password. Even if all my users used only 15-number passwords, it would take them years to get a hit. Possibly decades. And that is good enough for me. Not everyone is going to use just numbers so that will be rare to boot.

I don’t need to protect the passwords for centuries. I need to protect them for days or weeks. Long enough to be alerted to the attack. In my experience, there are really 2 types of online attacks against passwords. Low and slow, and fast and hard.

Low and slow attacks are where computer sabatouers make only a few guesses before backing off. Possibly even only once per hour, if they are patient enough. Possibly 2 or 3 guesses every 15 minutes. They may only do this for only high value accounts. Hopefully generic accounts (that you have disabled or changed the name too right? Right?), but if they are aware sites like LinkedIn work and can predict your usernames (Employee numbers as usernames don’t seem so bad right?), they may be going after executives, HR, and increasingly, IT staff. But the point is they are playing the long game. The slow drip drip drip. If they only try the top 10,000 and can hit dozens of accounts (or possibly the entire environment at once), they will eventually get a hit with enough targets to make this viable.

Fast and hard is just slamming and jamming away. 100 guesses per second per account? Yes. Guess until lockout then wait half an hour? Also yes. They hit hard and fast. They spray and pray. Speed is more important than stealth. IT admins who don’t have proper logging can only see this if users start complaining about account lockouts.

Both attacks can be detected with simple rules. For low and slow, tune your SIEM/logging to look for repeated bad password attempts but NO lockouts within a 4-5 hour period. I use about 1 bad password attempt for each hour, for 6 hours. Some tools make this easy to track, others not so much. But you want to use a number that is higher than what you think a user would do without locking themselves out (3 or 4 times a day possibly) but still catch these attacks. And if you get more than 1 user with this state in the same 6-8 hour period? Definitely a high value, actionable alert should be thrown. For fast and hard, a simple 5 account lockouts in 4 hours type of rule. Users will lock themselves out a lot in a day, but no user will get their password wrong 20 times in 3 hours. Even if they invent a user who can, that is someone who needs to get some gentle training. Or a new password. Or both. For your environment it might make sense to have them be over 12 hours or only pay attention to overnight/after-hours as almost no users have a good reason to be logging into the VPN at 3 AM from 2 States over.

But my point is, I only need the password to be strong enough to last a week. I should be able to catch the attacker trying to steal the password database or making all the bad guesses within a week. But with my password policy, we should still have decades. It is more likely they find a fatal flaw in the authentication protocol or bypass the need for a password or phish the user before they crack it.

So how do you make a good password?

Diceware. No seriously that is pretty much all I do. I love to roll dice what can I say?

But really, if we check the password cracking formula against diceware passwords and full keyboard character-set passwords we can see advantages emerge quickly (or go read the original diceware post, its really good).

Password cracking formula: ((((((2^(E-1))/10,000)/60)/60)/24)/365)

(2^(E-1)) : computers work in binary and the password guess is either correct or not. Not sure why the wisdom is to take the total entropy and subtract it by 1 (cutting the space in half) but if it takes 100 quadrillion years to only iterate through half of all possible passwords, even 1 ten thousandth of 1 ten thousandth of that is still 100’s of thousands of years, that matters little. 10,000 : is an upper bound on high end password cracking rigs in 2026 to crack Argon2id hashes using Hive System’s research. Supercomputers in 2026 are “exascale” or capable of doing 10^18 64-bit double precision floating point operations (FP64), or 1 Exaflop. Thus it would not be unreasonable to assume at somepoint in the not too distant future an “exahertz” or 10^18 executions would be possible for computers that a well resourced criminal outfit could get their hands on for password cracking purposes. 1 Hz is an operation per second, 60 seconds in a minute, 60 minutes in an hour, and 365 days in a year, and that gives us the time it takes to guess a password of a given entropy in years.

Thus to crack a 4-word diceware password (79) using a high end 2026 password cracking computer it would be the following formula: ((((((2^(79-1))/10,000)/60)/60)/24)/365) = ~958 Billion years 15-character, all lowercase = ~1.8 Billion Years

Some more ‘Password Math’: 15 x log2(26) = 70 15 x log2(95) = 98 15 x log2(65) = 90 4 x log2(1,000,000) = 79 8 x log2(1,000,000) = 159 24 characters (full keyboard) to match

There are hundreds of thousands of words in English alone, and even sticking to 4- to 6-letter words, if you use multiple lanugages you can easily start to hit the 100’s of thousands. Each time you also do character substitution (L33T SP3@K), you double, triple, even quadruple the “character set” because with Diceware, each individual word is your character. To me it is far easier to remember 4 to 6 short words than some 20+ random character sequence.

So use diceware. And if you can, make your own custom diceware list. If you can, then for every word you include in your diceware list that an attacker does not know about, you can generate over 3 quadrillion passwords that they would not be generating. Billions and Billions of incorrect, impossible passwords for each word they include but you don’t. So if you can come up with a diceware list that is 100,000 words long, randomly shuffle that into 6^6 and cut the rest (I use 6 instead of 5 dice diceware lists) then you could possible have hundreds of billions of unique passwords, easy to type, easy to remember, that an attacker would have one hell of a time guessing even if they knew your list.

Passkeys

Passkeys seem to alievate this but if not set up correctly, we end up with a kafka-esque vendor lock in. Without the device that has the passkey, you do not have access to your accounts.

I can get into this later but suffice to say, there is at least weekly, a post on Mastodon from librarians about how actively user hostile many services and websites are if you are ever in a position that you do not have the blessed cell phone with the passkeys. Again, see the CIA triangle and if you cannot make the service available through some fallback mechanism, you are failing your users.

This is improving with things like EVP or Email Verification Protocol (read more here, but still. It has a long way to go.

Passkyes make sense in that they use Public key cryptography which is a tried and true method of incredibly strong security, are burned (or keyed, get it) to a single domain, and require a password manager. If they had the flexibility and portability of SSH keys with an easy to use UI/UX, then passkeys would be the greatest and we should never use passwords every again.

But that is not the future we live in. In concept I love them. In practice they are frustating, and in some cases, outright user hostile.

Conclusion

This was a rant about passwords. If you can only do 1 thing, adopt the new NIST standard for your password policy. Don’t force arbitrary rotation with a dumb composition ruleset. Use diceware where you have to and SSH keys for everything else. Thank you and good luck out there.

-kemotep