One of the most storied rites of passage computer touchers have in their journey to adulthood is the writing of a curmudgeonly, more-than-slightly-condescending article with an incendiary title practically guaranteeing placement on the first page of the Orange Site. The custom began with Dijkstra's foundational Go To Statement Considered Harmful, was followed by Coda Hale's How To Safely Store A Password, and today I join my surly forebears in a spot of droll bombthrowing.
TL;DR randomly-generated passwords should be 12 alphanumeric characters. Have to use a special character? Pick your favorite and stick it on the end whenever you need to comply with some password policy.
Considering I've been running in information security circles for the better part of two decades now, I know I've met people on both sides of this conversation:
"Typing 20-character passwords with all these specials into a phone sucks so much"
"I know that feel, my passwords are all 40 characters"
"Well, all my TOP SECURITY accounts have 64-character passwords"
"Oh yeah, I use 100-character passwords for all my accounts I CAN'T LOSE"
This isn't security theater per se, but people who say their passwords are some absurd length are most certainly performing. Perhaps you're one of them, and you're not taking security advice from some internet chucklefuck with 30% of Matt Levine's writing skill but thinks he has 80% - generally a smart move, but if you'll follow me on a short journey I'll show you why such an instinct will lead you astray this time.
Let's consider the typical infosec bro^H^H^H enthusiast - we can assume they have a slightly outsized sense of self with perhaps more paranoia than is generally warranted, and therefore assume nation states are out to get them. Since they need to protect themself from the NSA for whatever reason, they "need strong passwords". As they are a typical infosec bro^H^H^H enthusiast, in lieu of creating an actual threat model or putting any thought into the amount of actual effort the NSA might expend on cracking a password they decided to turn up the generated password length in LastPass and hit the bars at DEF CON. But how much effort could we expect the NSA to expend in cracking a password?
Let's also assume this is the Mildly Worse Place and all websites store their passwords as single-round MD5 hashes. Basic research into the most powerful single box you could buy for password cracking today led to the Terahash Inmanis. I tried searching for some hashcat benchmarks but everything I found was out of date or not entirely relevant, so this hypothetical approximates the power of the Inmanis with *checks notes* a cluster composed of 44 Inmanis boxes and one Brutalis box, comprising 448 Nvidia RTX 2080s in total. I guess that's close enough. If the NSA is willing to spend the million dollars plus to buy the boxes, to say nothing of the ridiculous amounts on energy needed to cool and run them, and we take the benchmarks in the corporate tweet at face value, this gives them over 17 trillion MD5 hashes per second of compute power - but since we're in the Mildly Worse Place let's round that up to an even 2^45 hashes per second.
"But the NSA can put a million-dollar cluster on a P-card; they won't stop there" the enthusiast replies - and I don't disagree; government officials love burning budget like they love requiring forms be filled out in triplicate, so let's up the ante by assuming the NSA wants a billion-dollar cluster and buys 1024 copies of the above cluster, taking their compute power up to 2^55 hashes per second.
While we're in the Mildly Worse Place, let's even give the NSA an additional fudge factor to account for software and hardware improvements since the tweet was posted and take their compute power up to 2^59 hashes per second.
At this point we ask our enthusiast how long they would want their password to survive such an attack. "I think a year is long enough," our enthusiast opines in their closest approximation to reasonableness, "but I want it to last a year on average so it needs to survive two years max." Okay, let's go with that - a year has 31556925 seconds , so for a password to have a worst-case crack time of two years at 2^59 hashes per second, the number of candidate hashes the NSA would have to generate would be:
and the corresponding password would thusly need 85 bits of entropy. So how many characters is that? The grand total comes to:
In case you missed it, this hypothetical favored the NSA at every turn - specifying the password was stored in pretty much the worst possible fashion, rounding up their compute power AND giving them an extra fudge factor, giving them a billion-dollar cluster and two years to work on a single hash - and they still lose against 15 numbers and letters, you don't even have to include those specials which make adding a new phone or TV to your home WiFi such a character-building experience. Hell, this hypothetical even assumes the NSA tests 15-character alphanumeric passwords only - if they don't know the password length or topology a priori and start testing shorter ones with specials first it'll take even longer.
"I guess I don't need such long passwords," the enthusiast finally relents, "I'll switch to 15-character alphanumerics instead". Not so fast! This hypothetical was a ridiculous overexaggeration - in a "more reasonable" scenario where the NSA has only a single ridiculous million-dollar cluster and a password only has to last a year max, a password of sufficient strength only needs:
"But that fails to meet my arbitrary security goals against my adversary whose ability isn't based in reality!" the enthusiast pleads. I have three points of response:
- If the organization running the website storing the password hash is at least mildly competent, they are (hopefully) hashing passwords with a more suitable algorithm like bcrypt which is many orders of magnitude slower to crack
- If access to the account the password protects is the primary concern and not the content of the password itself, using a security key would deny access to someone who cracked the password as well as provide fringe benefits like phishing protection (which our enthusiast finds useless, as they could never be phished)
- If the NSA really wanted access to an account and couldn't hack the server, they'd get a judge to rubber-stamp a court order and get the data that way.
"Well, I have to use a computer that won't accept a password without special characters", the enthusiast retorts. Since the rest of the password is sufficiently strong, they don't need special characters to provide additional entropy and therefore can add their favorite to the end of their password whenever a computer would get mad otherwise.
Perhaps this was enough to convince you, dear reader - but if it wasn't how about I throw in an appeal to authority to sweeten the pot? If you still think I don't know what I'm talking about, how about Hashcat developer, Terahash founder and DEF CON Password Village staffer Jeremi Gosney? "Founder of password cracking company wants people to use shorter passwords" you may retort, but the math doesn't lie - a password with 20 random full-keyboard characters, or 22 alphanumeric characters, has more entropy than the TLS key used to encrypt it in transit. Probably more than the public key in the TLS certificate as well, so an attacker sufficiently powerful to mount a feasible attack on said password would likely choose to attack that instead, and then everyone's fucked, regardless of password length.
And with that, my article comes to an end. I hope this has convinced you that you do not need to make your bank password 64 characters with specials and emoji, even if you'll always use your password manager to enter it. This article didn't even touch on the possibility of websites (or algorithms) silently truncating long passwords, which makes your long password even more pointless. Regardless, even if you leave slightly insulted, I hope you also leave more informed.
|||Somehow out of all the work that went into this post, the question "How many seconds are in a year?" required the most research and the largest weighing of tradeoffs. I decided to make my calculations using the tropical year, with a mean length of 365.24219 days in 2000, but considered considered the siderial year (365.2564 d) as well. If you're a fan of Julian (365.2500 d) or Gregorian (365.2425 d) years, do you even calendar? Check Wikipedia to see how deep this rabbit hole goes.|
|||Calculation images from codecogs.com|