Your Passwords Should Be Shorter

Sun 18 October 2020

EDIT: On tape delay from Las Vegas, it's me presenting this rant at BSides!

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 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 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 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 password cracking instance you can rent in the cloud today led to the EC2 P4d instance class. The data I've found suggests each P4d cluster can brute-force over 500 million MD5 hashes per second - but since we're in the Mildly Worse Place let's round that up to an even 2^39 hashes per second.

"But NSA can put a $100k AWS bill on a P-card; they won't stop there" our enthusiast objects - 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 NSA wants a billion-dollar AWS bill and 9709 P4d cluster, taking their compute power up to a bit over 2^52 hashes per second.

While we're in the Mildly Worse Place, let's even give NSA an additional fudge factor to account for software and hardware improvements since the announcement was posted and take their compute power up to 2^57 hashes per second.

At this point we ask our enthusiast how long they would want their password to survive such an attack. "I think four years is long enough," our enthusiast opines in their closest approximation to reasonableness, "but I want it to last four years on average so it needs to survive eight years max." Okay, let's go with that - a year has 31556925 seconds [1], so for a password to have a worst-case crack time of eight years at 2^57 hashes per second, the total number of candidate hashes NSA could generate would be:

Generating 2^57 hashes per second for eight years yields roughly 2^85 hashes.

and the corresponding password would thusly need 85 bits of entropy. So how many characters is that? I don't know about you, but every time I have to hit the special character button twice on my phone to enter a curly brace I die a little inside so let's stick to alphanumerics only. So how long do our passwords have to be when we handicap ourselves like this? According to the math:

2^85 bits of entropy can be stored in 15 random alphanumeric characters.

A picture of Diane Amos; the text "That's the power of exponentials, baby!" is superimposed.

In case you missed it, this hypothetical favored 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 AWS bill for eight 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 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 NSA has "only" ten ridiculous clusters for a million-dollar AWS bill, but we allow them twenty years to work on a single hash, a password of sufficient strength only needs:

Surviving an attack of 2^45 hashes per second for a year requires a password of 12 alphanumeric characters.

"But that fails to meet my arbitrary security goals against my adversary whose ability isn't based in reality!" the enthusiast objects again. I have three points of response:

  1. 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
  2. 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)
  3. 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 - this method also beats creating randomly-generated passwords with special characters since it means you can use special characters you know the computer won't get mad at.

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.

[1]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.
[2]Calculation images from codecogs.com