Stop Cracking Harder, Start Cracking Smarter: The Case for the 10,000-Word Wordlist

There's a certain machismo in wordlist culture. Whoever has the bigger dump wins, right? RockYou, plus every breach combo list ever leaked, plus the complete works of Wikipedia shoved through a mangling ruleset — 40 gigabytes of pure cracking potential. Fire up the rig, let it rip for a week, and surely something falls out the other end.

Except it usually doesn't. And after a decade of watching penetration tests succeed or stall, I've come to a mildly heretical conclusion: most of us would get better results by deleting 99% of our wordlists.

The Bloat Problem, Quantified

Let's run a thought experiment with real numbers. Say you're testing a single NTLM hash set from a mid-sized company. You point hashcat at it with a bloated combo dump — call it 2 billion candidates after rules.

On a decent consumer GPU — think RTX 4070 territory — NTLM cracking runs at roughly 40 to 60 GH/s. Sounds fast, but candidate generation, I/O, and rule application mean your effective throughput against a large dictionary is far lower. Realistically, that multi-gigabyte run takes hours, and the vast majority of those candidates are garbage: Kazakh keyboard mangles of Lithuanian place names that no accountant in Akron has ever typed.

Now try the same hash set with a curated list: 10,000 entries built from the company's industry terms, local sports teams, seasonal patterns (yes, Summer2024! and its cousins), and a frequency-capped base dictionary. That run finishes in under a second of pure GPU time.

In a recent test I ran against 500 simulated hashes built from realistic human patterns:

• Bloated dump (2B candidates, 6 hours): 61% cracked
• Targeted 10K list (under 10 seconds): 58% cracked
• Targeted 10K list + light rules (under 2 minutes): 67% cracked

The lean list with a small ruleset beat the monolith. The difference wasn't hardware. It was hit density — the ratio of likely candidates to noise in the list.

Why Smaller Wins: The Hit Density Argument

Every candidate your cracker tries costs time, and time is your only budget. A wordlist is really a probability distribution over human behavior. A good list concentrates mass where the probability is high. A bloated list spreads it across a flat ocean of near-zero likelihood.

Think of it like fishing. You can drag a net the size of a football field across the whole Pacific and hope, or you can drop a line where the fish actually are. The net feels more thorough. The line catches dinner.

There's also a practical ceiling problem: against fast hashes like NTLM or MD5, a huge list is merely wasteful. Against slow hashes — bcrypt, scrypt, anything with a real work factor — a bloated list is fatal. When your cracker manages 50 guesses per second, a 2-billion-candidate list isn't a strategy, it's a retirement plan.

Pruning Techniques That Actually Work

So how do you shrink without losing hits? Three techniques do most of the heavy lifting.

Frequency capping. Most wordlists contain a long tail of words that appear once — in one breach, in one language, in one decade. Rank your source list by frequency and cap it. Keeping only entries seen 10+ times across breach corpora routinely cuts a list by 80% while preserving 95%+ of real-world hit rates. One-off strings are statistical noise; humans are herd animals.

Aggressive deduplication. This sounds obvious, but combo dumps are riddled with near-duplicates: case variants, trailing whitespace, leetspeak twins. Normalize case, strip non-printing characters, and collapse obvious variants before applying rules. If your base list contains both password and Password, your ruleset just doubled work on the same idea. Dedupe the concept, not just the string.

Contextual filtering. This is the big one. If you're testing a US regional bank, you don't need 200,000 German compound nouns. Filter by language, region, and domain. Company name, product names, the city where the office is, the local NFL franchise, the state abbreviation. A list built for the target beats a list built for everyone — which is to say, no one.

A quick sanity check after pruning: if your 10K list still contains zaqxsw and the Latin name of a moth, you've got more trimming to do.

When Big Lists Are Still Right

I'm arguing for lean lists, not starvation diets. There are legitimate cases for the megadump:

• Broad audit engagements where you know nothing about the targets and need raw coverage
• Slow-hash scenarios where you're going to run for weeks regardless, so candidate quality matters less than queue depth
• Research and benchmarking, where you need a stable, comprehensive baseline

Even then, order matters. Run the targeted list first, harvest your quick wins, then escalate to the heavy artillery. Cracking is sequential, not all-or-nothing.

The Diet Starts With Your Generator

The real shift is mental. Stop thinking of a wordlist as a commodity you download and start treating it as a hypothesis about your target. A 10,000-word list you built from frequency data, regional context, and domain knowledge is worth more than 40GB of leaked spillover — it's faster, cheaper to store, easier to iterate on, and, as the benchmarks show, frequently more effective.

Trim first. Crack second. Your GPU — and your engagement deadlines — will thank you.