Daniel sent us this one about passwords. Specifically, what happens when you're stuck with a service that only does password authentication — no two-factor, no hardware key, nothing. Just a password between you and whoever wants in. And the core question is: if that's the hand you're dealt, how long does that password actually need to be before brute-forcing it becomes computationally absurd? And once quantum computing shows up, does any length save you?
This is one of those questions where the numbers are genuinely surprising. Most people think a twelve-character password is fine, and for a lot of cases it actually is, but the gap between "fine" and "mathematically immune to brute force" is narrower than you'd expect, and also wider, depending on what you're defending against.
Narrower and wider. You're already in peak form.
Let me set the table properly. When we talk about brute-forcing a password, we're not talking about someone sitting at a login screen typing guesses. We're talking about an attacker who has obtained the password hash — the scrambled, one-way cryptographic representation of your password — through a data breach. They've got the hash file on their own machine, and they're running specialized software against it, often with absurd hardware.
The threat model here is: the service gets breached, the password database gets dumped, and now it's a race between how fast they can crack your hash and how fast you can change your password.
And the speed at which they can try guesses is the number that makes this whole conversation worth having. A single RTX 4090 — that's a consumer graphics card from NVIDIA, not some government supercomputer — running hashcat against NTLM hashes, which is what Windows uses, can attempt roughly three hundred billion guesses per second. Three hundred billion. With one card.
I assume people who do this for a living aren't stopping at one card.
They're not. You can build an eight-card rig for somewhere in the neighborhood of fifteen to twenty thousand dollars, and now you're looking at north of two trillion guesses per second. And if the hash algorithm is something weaker, like MD5, which some older systems still use, those numbers go up by another order of magnitude. You're talking hundreds of trillions of guesses per second on consumer-adjacent hardware. Not state-level. Just a motivated person with a budget.
When someone says "just use a long password," what we're really saying is "make the search space large enough that even hundreds of trillions of guesses per second doesn't get them there in a human lifetime.
That's it. And the math is elegant in a terrifying way. Let's say you're using a truly random password generated by something like 1Password — so we're not dealing with dictionary words or predictable patterns, which is its own disaster. Each character in your password is drawn from a set of possible characters. If you're using uppercase, lowercase, digits, and the standard special characters, you've got about ninety-five possible values per character.
Ninety-five to the power of however many characters you have.
So a password of length L has ninety-five to the L possible combinations. On average, an attacker finds it after searching half the space. So the question becomes: at what L does half of ninety-five to the L exceed the number of guesses an attacker can make in whatever time window you care about?
Walk me through some concrete lengths. What does eight characters actually buy you?
An eight-character random password from a ninety-five-character set gives you about six point six quadrillion possible combinations. That's six point six times ten to the fifteenth. Divide by two for the average case. At three hundred billion guesses per second on a single 4090, that's... roughly three hours. Three hours to crack an eight-character random password on one consumer GPU.
And most people's passwords aren't random.
Most people's passwords are "P@ssword1" with the requisite capital, symbol, and number that the password policy demanded, which means they're not even in the random-search space. They're in a dictionary-attack space that gets cracked in under a second. But even the person who uses a password generator and picks eight random characters — they're getting three hours of protection against one graphics card. Against an eight-card rig, it's minutes.
Eight characters is effectively nothing. What about twelve?
Twelve characters gets you to ninety-five to the twelfth, which is roughly five point four times ten to the twenty-third. Half of that, at three hundred billion guesses per second — we're looking at about twenty-eight thousand years on a single 4090.
That's more like it.
Remember, the eight-card rig is doing over two trillion per second. So that twenty-eight thousand years drops to about four thousand years. Still effectively uncrackable for any single human adversary. But we haven't talked about the hash algorithm yet, and that's where this gets nuanced.
Explain that part, because I think most people assume a password is a password.
The hash algorithm is everything. NTLM, which I used for those numbers, is fast. It's designed to verify your password instantly when you log into Windows, and that speed is the enemy of security once the hash is stolen. But if the service is using something like bcrypt with a high cost factor, the cracking speed drops from hundreds of billions per second to maybe thousands per second. That turns a twelve-character random password from "crackable in a few thousand years" to "crackable after the heat death of the universe.
The strength of your password is only half the equation. The other half is whether the service you're using chose a hash algorithm that isn't garbage.
You have no way of knowing what they chose. That's the maddening part. A service can have a beautiful login page and a competent-looking mobile app and be storing your password as unsalted MD5 from 1998. You'd never know until the breach notification lands.
Which brings us back to Daniel's question. If you're stuck with a password-only service and you want to be as safe as possible regardless of what hash they're using, what length makes you essentially immune?
Here's where I'll give a number that I think is defensible. If you generate a truly random password of twenty characters from the full ninety-five-character set, the search space is ninety-five to the twentieth, which is about three point five times ten to the thirty-ninth. That is a number so large that even if every computer on Earth were dedicated to cracking it, and even if the hash algorithm were catastrophically fast, you're looking at timescales measured in billions of billions of years.
Twenty random characters is the "stop worrying about it" threshold.
For classical computing, yes. And honestly, even sixteen gets you to a space of about four point four times ten to the thirty-first, which is already in "not in your lifetime or your great-grandchildren's lifetimes" territory against any realistic hardware. But twenty gives you margin. It accounts for the hash being fast, the attacker being well-funded, and the possibility that someone figures out a clever optimization. Twenty random characters, from a generator, not from your brain — that's the answer I'd give.
Daniel mentioned the character set question. Does adding special characters actually matter, or is it mostly about length?
Length dominates, but the character set is the base of the exponent, so it's not nothing. If you only use lowercase letters — twenty-six possibilities per character instead of ninety-five — a twenty-character password gives you twenty-six to the twentieth, which is about two times ten to the twenty-eighth. That's still enormous. Still uncrackable for practical purposes. But a twelve-character lowercase-only password is twenty-six to the twelfth, which is about nine point five times ten to the sixteenth. On a fast hash, that's within reach.
The real takeaway is: use the full character set because it's free security, but length is what's doing the heavy lifting. Going from twelve to sixteen characters matters far more than going from lowercase-only to the full set at twelve characters.
The math is unforgiving that way. Each additional character multiplies the search space by ninety-five. Adding special characters to the mix multiplies it by about three or four, once. Length is exponential. Character variety is a linear multiplier.
This is why password generators are non-negotiable. A human being cannot produce a random twenty-character string. We're pattern-matching machines. Even when we think we're being random, we're gravitating toward keyboard walks and memorable sequences and the same three special characters everyone uses.
There was a great analysis a few years back looking at passwords from actual breaches. The exclamation point is overwhelmingly the most common special character, and it almost always appears at the end. The number one appears at the end even more often. Humans are predictable in ways they don't notice, and password-cracking tools are explicitly designed to exploit those patterns. They try all the common substitutions first — "at" sign for "a," three for "e," zero for "o" — before they ever bother with a brute-force search. So even a long human-generated password is weaker than a shorter random one.
Like adopting a feral cat. You think you've tamed it, but it's still got instincts you don't see coming.
actually a reasonable analogy. I'm unsettled.
Let's talk about the quantum part of the question. Daniel asked whether quantum computing makes any password length unsafe. What's the actual threat there?
This is where we need to distinguish between two things that often get conflated. Quantum computing poses a catastrophic threat to public-key cryptography — the kind that secures your connection to a website, the kind that encrypts your emails in transit. Algorithms like RSA and elliptic-curve cryptography are built on mathematical problems that are hard for classical computers but can be solved efficiently by a sufficiently large quantum computer running Shor's algorithm. That's the post-quantum cryptography panic, and it's real.
Passwords aren't public-key cryptography.
They're not. Password hashing relies on symmetric algorithms and one-way functions, which are much more resistant to quantum attacks. The best known quantum algorithm for searching an unstructured space — which is what brute-forcing a password essentially is — is Grover's algorithm. Grover's algorithm can search a space of size N in roughly the square root of N steps, rather than the N-over-two steps of a classical brute force.
Instead of cutting the search time in half, quantum cuts it to the square root.
And that sounds terrifying until you do the math. If your password has a search space of ninety-five to the twentieth — that's three point five times ten to the thirty-ninth — the square root of that is about six times ten to the nineteenth. Which is still six billion billion. Even if a quantum computer could evaluate a hash in a single operation, which it can't, you're still looking at a time horizon that exceeds the age of the universe.
The quantum threat to passwords is... not a threat.
For sufficiently long random passwords, it's not. If your password is eight random characters, with a search space of about six quadrillion, the square root is about eighty million. That's suddenly very achievable. So quantum computing does lower the bar, but it doesn't eliminate the bar. It just means that the minimum safe length gets pushed up. Where sixteen random characters was safe before, maybe you want twenty or twenty-four to account for quantum. But the principle holds: make it long enough, and even Grover's algorithm can't save them.
Which is the most reassuring thing I've heard all episode. The physics of computation still has limits.
And there's another factor that doesn't get enough attention. Quantum computers that can actually run Grover's algorithm on real-world hash functions at scale don't exist yet, and when they do, they won't be running at gigahertz speeds like classical processors. Quantum operations are slow and error-prone. The clock speed gap is enormous, and error correction adds massive overhead. So the practical quantum threat to password hashing is even further out than the theoretical one.
The advice holds: twenty random characters from a generator, and you can sleep at night even if the service has no two-factor, even if their hash algorithm is MD5 from the Clinton administration, even if quantum computing arrives on schedule.
I'd go to twenty-four if you want to be truly luxurious about it. 1Password's default generator length is, I believe, twenty characters, and you can bump it up. But even their default is already in "functionally uncrackable" territory.
Now let's talk about the elephant in the room, which is that none of this matters if the service itself is compromised in a way that doesn't involve cracking hashes at all.
Brute-forcing a password hash is one attack vector. It's the one Daniel asked about, and it's an important one, but it's not the only one. If the attacker gets into the service's live systems and intercepts passwords before they're hashed, or if they compromise the session tokens after you log in, or if they phish the password directly from you, the length of your password is irrelevant. You could have a two-hundred-character random password and it wouldn't matter.
Which is why two-factor authentication exists in the first place. The password is something you know. The second factor is something you have or something you are. If the password gets compromised through any of those channels, the second factor is supposed to stop the attacker from actually getting in.
That's what makes Daniel's scenario so uncomfortable. When a service doesn't offer two-factor, you're stripped of that layer. You're back to the password being the single point of failure, and you have to hope that the failure mode isn't one that cares about password strength.
In the specific case of a hash breach — the database gets dumped, the hashes get cracked offline — password length is exactly what protects you. And that's the most common large-scale breach scenario. It's not some targeted attack on you personally. It's some company's S3 bucket getting left open and half a billion hashes walking out the door.
And in that scenario, the difference between an eight-character password and a twenty-character password is the difference between "your password is in the attacker's hands within hours" and "your password will never be cracked by anyone, ever.
Which brings me to something I've been wondering. Given how much of the security burden falls on the user in these password-only services, should there be some kind of regulation requiring two-factor as a baseline? The way we require seatbelts in cars?
It's an interesting question. The EU's revised Payment Services Directive — PSD2 — already mandates strong customer authentication for payment services in Europe, which effectively requires two-factor. But that's payments. For general online services, there's no equivalent. And the adoption numbers are not great. Depending on whose survey you look at, somewhere between thirty and fifty percent of websites that handle user accounts still don't offer any form of two-factor authentication.
Thirty to fifty percent. In an era where we've been talking about two-factor as the baseline for what, a decade?
At least a decade. And it's not just tiny hobby projects. There are major financial services, healthcare portals, government services — things where the sensitivity of the data is extremely high — that still run on password-only authentication.
That's the part that keeps me up at night. Not the random forum that doesn't have two-factor. The thing that has my medical records or my tax information.
In those cases, if you're forced to use a password-only service, the advice we've been giving applies doubly. Generate the longest random password the service will accept. Some services have absurdly low maximum lengths — I've seen ones that cap at twelve or even ten characters — and that should make you angry, because they're essentially preventing you from being secure.
What do you do in that case? If the service caps you at twelve characters?
You use all twelve, random, full character set, and you hope their hash algorithm is good. There's nothing else you can do except agitate for them to fix it, or find an alternative service. A twelve-character random password with a strong hash is actually fine. A twelve-character random password with a weak hash is crackable in days or weeks on modest hardware. You're rolling dice you can't see.
That's the thing about this whole conversation. The user is making decisions in the dark. You don't know what hash they're using. You don't know if they're salting properly. You don't know if their database is even hashed at all — there are still services storing plaintext passwords.
There absolutely are. And you find out when the breach happens and someone posts your actual password on a forum. It's a special kind of violation.
Let's summarize the practical advice for someone who's stuck with a password-only service. Step one: use a password generator. Not your brain, not a system you invented, not a pattern you think is clever.
Step two: use the longest password the service will accept, up to about twenty-four characters. Beyond twenty-four, you're well past the point of diminishing returns for any foreseeable computing paradigm.
Step three: use the full character set — uppercase, lowercase, digits, special characters. It's free security. The generator handles it for you.
Step four: store it in a password manager so you never have to type it or remember it. The password manager also protects you from phishing, by the way, because it won't autofill on a lookalike domain.
Step five: if the service eventually adds two-factor, turn it on immediately. The long password is your backup plan; two-factor is your primary defense.
Step six, which is the one nobody wants to hear: if the service is important — financial, medical, legal — and they don't offer two-factor, consider whether you can use a competitor that does. The market pressure matters.
Let's pivot slightly. Daniel mentioned that he occasionally sees developer tools without two-factor, which feels especially egregious because developers are supposed to know better.
Developer tools are a fascinating case because they often hold the keys to everything. A compromised npm token or GitHub account can be used to inject malicious code into packages that millions of people use. The blast radius is enormous. And yet, some of these tools were built in an era when two-factor wasn't standard, and they've never been updated.
Is that a technical limitation or just inertia?
Adding two-factor to an existing authentication system isn't trivial, especially if you have legacy API clients that don't support it, but it's not rocket science either. The bigger issue is usually organizational. The person who built the auth system left three years ago. Nobody wants to touch it. It works until it doesn't.
The "works until it doesn't" approach to security. The official philosophy of the internet.
It really is. And it's worth noting that even when two-factor is available, the implementation quality varies wildly. Some services offer two-factor but only via SMS, which is vulnerable to SIM swapping. Some offer authenticator-app-based two-factor but don't enforce it. Some offer it but bury it three menus deep so most users never find it.
None of this even touches on the user experience problem, which is that the average person finds two-factor annoying, so they don't turn it on even when it's available.
That's the adoption gap in a nutshell. The services that don't offer it are a problem, but so is the fact that on services that do offer it, something like ten to fifteen percent of users actually enable it, according to various studies. Google published numbers a while back showing that less than ten percent of active Google accounts had two-factor enabled.
Less than ten percent. The company that has been pushing two-factor harder than anyone.
That was several years ago — I believe the numbers have improved, especially after they started pushing passkeys and making two-factor the default for new accounts. But the point stands. The biggest security win available to most people is just turning on the features that already exist.
Which circles back to passwords because for the foreseeable future, even with passkeys and two-factor and all the rest, passwords are going to be the fallback. The thing that's there when everything else fails. And a lot of services are going to be password-only for years to come.
Passkeys are the long-term answer here. They're phishing-resistant by design, they don't require the user to generate or remember anything, and they're cryptographically tied to the service. But adoption is slow, and for every service that supports passkeys, there are a hundred that don't.
The long-random-password advice has a long shelf life.
And I want to add one more dimension to this that I think gets overlooked. When you generate a long random password for every service, you're not just protecting that service. You're preventing credential-stuffing attacks across services. If Service A gets breached and your password is cracked, and you've reused that password anywhere else, the attacker now has access to every other service where you used it. Unique random passwords per service eliminate that entire category of attack.
Which is the password manager's real superpower. It's not just about remembering things. It's about making credential reuse impossible because you literally don't know any of your passwords.
I don't know a single one of my passwords. I couldn't log into my email without my password manager. And that's the point. If I don't know it, I can't be phished for it, I can't accidentally type it into a lookalike site, and I can't reuse it.
There's a certain freedom in not knowing your own secrets.
That's very philosophical for a sloth.
I contain multitudes.
Alright, let's put a bow on the quantum question before we wrap. Daniel asked whether post-quantum cryptography changes the password calculus, and I think the honest answer is: not for the scenario he's describing. Post-quantum cryptography is about replacing the asymmetric algorithms that secure the connection between your browser and the server. It's about the TLS handshake, not the password hash. Your twenty-character random password is safe against quantum computers for the same reason it's safe against classical ones: the search space is just too big.
The people panicking about quantum computers cracking their passwords are panicking about the wrong thing.
They're panicking about the wrong thing. The thing to worry about with quantum is that all your encrypted communications — your emails, your messages, your VPN traffic — could be decrypted retroactively if someone is storing them now and waiting for a quantum computer to break the key exchange. That's the "harvest now, decrypt later" threat. Your password hash, sitting in some breached database, is not the target.
That's a useful distinction. The password protects the account. The encryption protects the data in transit. Quantum threatens the latter, not the former, at least for any password worth using.
Even for the latter, the post-quantum cryptography standards are already being finalized and deployed. NIST published the first post-quantum standards in 2024. Major browsers and operating systems are implementing them. By the time quantum computers are big enough to break RSA, the migration will largely be done. The password problem is actually stickier because it depends on individual services updating their authentication systems, which as we've established, they're terrible at.
The password is both the weakest link and the hardest one to fix at scale.
That's the paradox of authentication security in one sentence.
Let's do a quick lightning round of misconceptions we haven't addressed yet. First one: does changing your password regularly help?
If your password is strong and unique, changing it adds no meaningful security. If it's weak or reused, changing it to another weak or reused password doesn't help either. The only time changing passwords makes sense is when you have reason to believe the current one is compromised. The old ninety-day rotation policies were actively harmful because they encouraged people to choose weaker passwords they could remember and modify incrementally.
Second misconception: are password-strength meters on websites reliable?
They're directional at best. Most of them check length and character variety and not much else. They don't check against known breached passwords. They don't account for the hash algorithm. They don't know if you've used that password elsewhere. A meter that says "strong" is telling you the bare minimum. Don't trust it.
Third: does adding an emoji to your password help?
If the service accepts Unicode characters, technically yes, because it expands the character set dramatically. But many services don't handle Unicode consistently, and you might find yourself locked out when their backend chokes on it. I wouldn't rely on it.
Fourth: is "correct horse battery staple" actually good advice?
The XKCD method — four or five random words strung together — is better than a short complex password, but it's not as good as a truly random string of equivalent length. A five-word passphrase drawn from a ten-thousand-word dictionary has a search space of ten thousand to the fifth, which is ten to the twentieth. That's about the same as a ten-character random password from a ninety-five-character set. It's fine, but a twenty-character random string is orders of magnitude stronger. The XKCD method's real advantage is memorability, and since you should be using a password manager, memorability doesn't matter.
It was good advice in a pre-password-manager world.
It was good advice for the specific problem of "I need to remember my passwords," which is a problem you should solve by not remembering your passwords.
Let's land the plane. Someone's listening to this, they've got an account on some service that doesn't offer two-factor, and they want to know exactly what to do.
Open your password manager. Generate a new password for that service. Set it to twenty characters, or whatever the service's maximum is if it's less than twenty. Use the full character set. Never think about it again. That password is now, for all practical purposes, uncrackable.
If the service has a maximum length that's absurdly low — like eight or ten characters?
Then you generate the longest random string it will accept, and you write to their support team asking when they plan to join the current decade. And you start looking for an alternative.
The email to support is the real power move. Not enough people do that.
Companies track feature requests, and "add two-factor" and "increase password length limits" are the kind of requests that eventually bubble up if enough people make them.
If quantum computing arrives and everything changes?
If quantum computing arrives in a form that can actually run Grover's algorithm against password hashes at scale, we'll have bigger problems than your individual account security. But even then, the math says: make it long enough, and you're still safe. Twenty-four random characters. That's the "heat death of the universe" tier. Quantum or not.
There's something almost comforting about that. The universe will end before someone brute-forces your password. It's the closest thing to permanence we get.
It's the cryptographic equivalent of "this too shall pass," except it won't.
Now: Hilbert's daily fun fact.
Hilbert: In the late sixteen hundreds, naturalists studying cuttlefish in the Yukon River basin gave the animal its common name by combining the Old English "cudele," meaning "cushion," with "fish," because a cuttlefish looks like a small floating pillow that somehow ended up in a river and got very confused about its life choices.
...right.
I have several follow-up questions I will not be asking. This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the show running. If you enjoyed this episode, leave us a review wherever you get your podcasts — it helps more people find the show. We're Corn and Herman. See you next time.
