← 02 — Articles

How long should a passphrase be? It depends on where the hash ends up

Hardening8 min read

Most password guidance ends at “use a long passphrase”. That is the right direction, but it does not answer the question an administrator actually has to settle: how long is long enough for this account? Four words and seven words are both long passphrases. Against one kind of attacker the difference is irrelevant; against another it is the difference between a quarter of an hour and millions of years.

The deciding factor is not the password. It is where its hash ends up and whether an attacker can test guesses against it without asking your servers. This article explains the entropy math behind diceware passphrases, shows where offline attacks happen on an ordinary Windows network, and turns both into concrete length requirements. The numbers come from arithmetic you can repeat; the generator we use for the examples is passwd.entropywatch.dev, and it runs entirely in your browser.

What “bits of entropy” measures

Entropy counts how many equally likely secrets a generator could have produced, as a power of two. A passphrase with 64 bits of entropy is one of 2⁶⁴ possibilities. Each extra bit doubles the number of guesses an attacker needs. On average, an attacker finds the secret after searching half the space.

The number only means something when the secret was chosen at random, and it assumes the attacker knows exactly how. That is the useful property of diceware: the wordlist is public, the method is public, and the passphrase is still strong, because the only secret is the random choices.

The EFF Large Wordlist has 7776 words, one for every result of five six-sided dice. Each word picked at random adds log₂(7776) ≈ 12.9 bits:

Words Entropy
4 51.7 bits
5 64.6 bits
6 77.5 bits
7 90.5 bits

Capitalizing each word, or separating words with a hyphen, adds nothing if it is always done the same way — the attacker knows the method. Randomizing it does add bits: a random capital-or-not per word adds one bit per word, a random digit between words adds log₂(10) ≈ 3.3 bits per gap.

Human-chosen passwords do not have a meaningful entropy number. Summer2026! and correct horse battery staple look long, but neither was drawn at random, and cracking tools try phrases, song lyrics, keyboard walks and known breach lists long before they try random strings. Everything below assumes a generated passphrase.

The question that decides the length: online or offline

An online attack sends guesses to a login prompt: the VPN portal, Outlook on the web, an SSH server. Every guess is a request your infrastructure answers. Account lockout, rate limiting and conditional access cap the attacker at a handful of guesses per account per hour. Against that, even four random words are far out of reach.

An offline attack happens after the attacker has a copy of something derived from the password: a hash from a database, an encrypted vault, a Kerberos ticket. Guesses are tested on the attacker’s hardware. No lockout applies, nothing reaches your logs, and the only limit is how expensive one guess is to compute.

That cost varies by many orders of magnitude, depending on the algorithm that protects the password:

  • Fast, unsalted hashes. The Windows NT hash (what NTLM uses) is MD4 over the password, with no salt and no iterations. Identical passwords produce identical hashes across every account and every domain. A rig of eight current high-end GPUs tests on the order of 10¹² guesses per second against it, according to public hashcat benchmarks.
  • Deliberately slow hashes. bcrypt, scrypt, Argon2 and high-iteration PBKDF2 are designed to make each guess expensive. bcrypt at cost 10 on the same rig is closer to 10⁴–10⁵ guesses per second.

Average time to find a generated passphrase, assuming the attacker knows the method:

Passphrase Fast hash, ~2×10¹² guesses/s bcrypt cost 10, ~5×10⁴ guesses/s
4 words (51.7 bits) about 15 minutes about 1,200 years
5 words (64.6 bits) about 80 days about 9 million years
6 words (77.5 bits) about 1,750 years about 7×10¹⁰ years
7 words (90.5 bits) about 13 million years effectively never

Treat the guess rates as orders of magnitude, not benchmarks. Hardware gets faster, and attackers rent more of it. What matters is the shape: against a slow hash, five words are plenty; against a fast one, four words fall in an afternoon and six words are the comfortable minimum.

Where offline attacks happen on a Windows network

The table would be academic if offline attacks were rare. On a Windows network they are the normal second step after initial access.

The domain database. Every account’s NT hash is stored in NTDS.dit on each domain controller. An attacker with domain admin rights, or with the right to replicate directory changes, can extract all of them. From that point every password in the domain faces the fast-hash column above, and every shared password is visible because identical passwords give identical hashes.

Kerberoasting (T1558.003). Any authenticated domain user can request a Kerberos service ticket for any account that has a Service Principal Name (SPN). Part of that ticket is encrypted with a key derived from the service account’s password, so the attacker can take it offline and guess. No special rights are needed and, from the domain controller’s point of view, the request looks like normal service access. When the ticket uses RC4 (encryption type 0x17 in event 4769), the key is the account’s NT hash, and guessing runs at fast-hash speed. AES-encrypted tickets derive the key with PBKDF2 at 4096 iterations, which is slower but still far from bcrypt territory.

Local credential stores and caches. Cached domain logons, browser password stores and local SAM databases on a compromised workstation are all offline material.

Encrypted files and vaults. A password manager vault, a backup archive or a disk encryption volume is protected by whatever key derivation function the product uses. The good ones use a slow function; the attacker still has unlimited time once the file is copied.

The pattern is consistent: anything that can be copied can be attacked offline, and on a Windows domain the most valuable copies — NTDS.dit and service tickets — are protected by fast algorithms.

What to require

People, behind MFA and lockout only. Accounts that can only be attacked online — a SaaS login with MFA, an internal portal with lockout — are not where length buys much. Five random words is a reasonable floor because the same password often ends up somewhere offline later.

People with domain accounts. Assume NTDS.dit will leak one day. Six random words (77.5 bits) keep a fast-hash attack in the thousands of years. Privileged accounts — domain admins, tier-0 operators — should use seven.

Master passwords and encryption keys. A password manager master password, a disk encryption passphrase, an SSH key passphrase or a backup archive password protects data that can be copied and attacked for as long as the attacker likes. Seven words. These are also the passwords people type often enough to remember seven words.

Service accounts. Nobody needs to remember a service account password, so it should not be a passphrase at all. Prefer a group Managed Service Account (gMSA): Active Directory generates a 240-byte random password and rotates it every 30 days by default, which removes Kerberoasting as a practical attack. Where a gMSA is not possible, use a random password of 25 characters or more from a password manager, and disable RC4 for the account (msDS-SupportedEncryptionTypes) so tickets are issued with AES.

Policy. Length is the requirement that matters. Current NIST guidance (SP 800-63B, revision 4) requires a minimum of 15 characters when a password is the only factor (eight when it is part of MFA), recommends accepting at least 64, and forbids composition rules and forced periodic changes. Instead, new passwords are checked against a blocklist of common and known-compromised values. A six-word passphrase clears the length requirement comfortably and is easier to type than a 15-character random string.

Testing it yourself

Check the entropy math. The numbers in this article come from one formula. In Python:

import math

words, list_size = 6, 7776
bits = words * math.log2(list_size)
for rate in (2e12, 5e4):            # guesses per second
    seconds = 2 ** (bits - 1) / rate  # average: half the keyspace
    print(f"{bits:.1f} bits at {rate:.0e}/s: {seconds / 31_557_600:.3g} years")

Change words, list_size or the rates to match your own assumptions. The generator does the same calculation live, including the exact count for random passwords that must contain one character from each selected set.

Find the accounts that can be Kerberoasted. With the Active Directory PowerShell module, read-only:

Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
  -Properties ServicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes |
  Select-Object SamAccountName, PasswordLastSet, msDS-SupportedEncryptionTypes

Every user account in the output is a candidate for gMSA migration or a long random password. A PasswordLastSet from years ago usually means a human chose it and nobody has touched it since. An empty msDS-SupportedEncryptionTypes means the account falls back to the domain defaults, which on many older domains still include RC4.

Watch for RC4 service tickets. On domain controllers, event 4769 (A Kerberos service ticket was requested) records the ticket encryption type. A ticket with type 0x17 for a service account that supports AES is worth a look, and a burst of 4769 events from one user for many different SPNs is the classic Kerberoasting pattern. This requires the Audit Kerberos Service Ticket Operations subcategory (under Account Logon in Advanced Audit Policy Configuration) on the domain controllers.

Limitations

  • Entropy assumes a truly random choice. A passphrase someone regenerated until they “liked” it, or edited to be memorable, is weaker than the number says.
  • The crack-time table covers guessing only. Phishing, malware that logs keystrokes, and password reuse across sites bypass length entirely. MFA and unique passwords per service matter more than an extra word.
  • Guess rates change. The rates here are deliberately rounded; recompute with current hardware and your own assumptions before using them in a policy document.
  • A strong password does not fix a fast hash. If an application stores passwords with an unsalted fast hash, fixing the storage is the real remediation.

Adapting this to your environment

  • ADAPT the word counts to your threat model: if NTDS.dit compromise is in scope for your risk assessment (it should be), size domain passwords for the fast-hash column.
  • ADAPT the service account guidance to what your applications support. Some older software cannot run under a gMSA; record those accounts, give them long random passwords, and review them on a schedule.
  • ADAPT the minimum length in your password policy to what your systems accept. Some legacy systems truncate or reject long passwords. Test before you enforce.

Generate passphrases and check the math at passwd.entropywatch.dev: no network requests, no storage, and a self-test that shows what the browser blocks. If something here is wrong or missing, write to hello@entropywatch.dev and we will correct it in the open.