Password Cracking by the Numbers: Rates, Lengths, and Reuse
A password audit starts as a cracking problem and ends as a statistics problem.
You pull hashes off an engagement, and the whole job is turning them back into passwords: NTLM and the NTDS.dit dump from a domain controller, NetNTLMv2 off the wire, Kerberoast and AS-REP tickets from Active Directory, cached domain credentials, WPA handshakes from a wireless assessment, slow application hashes like bcrypt. What you recover is the finding, the proof of which passwords are weak and where they are reused. How much of it you recover depends on which attacks you run, in what order, and how much compute you point at them.
The console below is ARROW Decrypt, the self-hosted password-recovery platform in the ARROW suite. The corpus is a test set, so the specific numbers are a worked example, not a client finding.
The Dashboard: node and GPU status, jobs running, and live recovery across the cluster.
Run the attacks in the order that pays off
Cheap, high-yield work comes first: a wordlist run through a rule set. Rules mutate each candidate as it is tried, capitalize it, append a year, substitute symbols for letters, so one list expands into millions of realistic guesses. Against fast, unsalted NTLM, that pass finishes in minutes.
Masks come next: structured brute force over a defined pattern. In the run below, a single wordlist-and-rule job recovered 27,042 of 256,904 NTLM hashes in about four minutes. A seven-position mask over the full character set cracked 35. The keyspace of that mask is roughly 95 to the 7th, close to seventy trillion candidates, and each added character multiplies it by another 95.
The lesson is in the ratio: the cheap attack did the work, the exhaustive one barely moved the number. Decrypt benchmarks the cluster and scores every job on time, cost, and expected yield before dispatch, so an infeasible run is flagged or rejected before it ties up the fleet. A one-button Smart Crack mode walks that ladder automatically, corpus and wordlists first, then rules, then masks and Markov-ordered brute force. The same ladder runs against every one of those hash types, and the slower and saltier the hash, the more that feasibility gate earns its keep.
The Jobs console: attack, hash type, crack count, and run time per job. The wordlist-and-rule pass recovered 27,042 hashes. The exhaustive mask recovered 35.
Cracking scales sideways
Cracking is embarrassingly parallel. Split the keyspace, the wordlist, or the hash list across more GPUs and wall-clock time falls close to linearly. The constraint is coordination: one queue, one copy of the corpus, one benchmark across cards that are not identical.
Decrypt handles that. Name a node and it returns a one-line command. Run it on a box, a rig on your bench or a GPU instance you spin up in the cloud, and it installs the control plane and agent, joins the cluster, and registers its own address. The Nodes view shows each GPU’s utilization and temperature, and the cluster’s total VRAM and power draw.
Compute is set per job: on-prem, cloud, or mixed. For a cloud burst you pick a GPU model and count, and Decrypt rents the instances when the job starts, joins them to the cluster, runs the work, and tears every one down the moment the job finishes or hits its spend cap. You pay for the run, not the queue, and a rented node only ever touches its own job. That is what makes a slow-hash corpus tractable: rent a wall of cloud GPUs for an afternoon, then give them back.
What goes out is hashes, nothing else. Usernames are split from the hashes on ingest and paired back only on your own instance for the report, so a cloud worker only ever sees a hash to crack, never a name or anything that ties it to a client. The rented instances are ephemeral and run a stock public image, and they come down with the job. The platform itself is self-hosted and single-tenant: the corpus and the recovered passwords stay on your box, and every action is logged.
More cards mean more candidates per second, which moves the line on what is worth running at all.
The Nodes view: each rig, its GPUs, and live utilization, temperature, and power. A node joins the cluster with one generated command.
Read one engagement
Once the hashes fall, the distribution is the finding.
For a single engagement, the report gives you crack rate, unique versus reused, a length histogram, and a composition breakdown: how many recovered passwords carry a digit, a symbol, or an uppercase letter, how many are all lowercase, and how many simply end in a year. In the run shown: 27,343 cracked, 27,041 unique, a 1.3% crack rate, and 302 reused. Reuse is a lateral-movement signal: a password shared across accounts turns one crack into several.
Length is the other tell. Here the cracked set clusters at eight to ten characters, with a spike at eight and nine and a smaller, separate bump around sixteen. In real corpora the main spike tends to sit at the policy’s minimum length, where most users land; a longer cluster usually marks password managers or passphrases.
The most-reused list is where organization-specific patterns show up: onboarding defaults like Welcome@1 and Password123, and placeholder strings like a literal N0CHANGE, fixme, and testing. Because NTLM is case-sensitive, password and PASSWORD are counted as different hashes.
Every recovered password is paired back to its account and flagged as reused or weak, the run gets a letter grade and written findings, and it all exports: the per-engagement report as JSON, the per-job credential list as CSV. The deliverable exists the moment the jobs finish.
The Reports view: crack rate, unique against reused, the most-reused passwords, and a length histogram for one engagement.
From one engagement to every engagement
A single engagement is one data point. The numbers compound when you can read across all of them.
Every engagement is tagged with a client and an industry vertical, Finance, Healthcare, Technology, Government, and the rest. Decrypt aggregates cracked results across every engagement and breaks them down three ways: by client, by industry vertical, and by hash type, with the same reuse, length, and composition analysis applied to the whole book of work.
That is the input for annual and compliance reporting. Instead of one client’s crack rate in isolation, you can see which sectors and which hash types are actually falling across everything you have run.
Built for ARROW
ARROW Decrypt is part of the ARROW platform. It is releasing soon, exclusive and free for ARROW customers.
If you run a shared cracking box and want to see the audit and reporting side, we will walk your team through it.