How a Leaked Password Hash Actually Gets Cracked

When a service stores passwords, it almost never saves the characters a user typed. Instead, it runs those characters through a hashing algorithm and stores the fixed-length output — the hash. The assumption is that the hash cannot be reversed. That assumption holds mathematically: a hash function is a one-way operation. What it does not prevent is an attacker computing hashes independently and comparing them to stolen records until a match appears.

This piece covers the mechanics of that comparison process — how stolen hash files are structured, what tools and techniques allow offline cracking at scale, and where the protections built into modern hashing algorithms succeed or fail against determined offline attacks.

From Stolen Database to Recovered Plaintext: The Cracking Pipeline

A database breach typically exposes a table containing usernames, email addresses, and hashed passwords. The attacker downloads this table and works entirely offline. No further contact with the victim service is required, which means rate-limiting, lockout policies, and intrusion detection at the service have no effect on the cracking process.

The first stage is identification. Hashing algorithms produce outputs of predictable length and format. A 32-character hexadecimal string is characteristic of MD5; a 64-character string suggests SHA-256; a string beginning with $2b$ signals bcrypt. Automated tools identify the algorithm from these signatures, which determines which cracking strategy is applied.

The second stage is candidate generation. The attacker does not guess characters at random. Instead, a cracking tool generates candidate plaintext strings — words, common passwords, keyboard patterns, names with appended numbers — hashes each one using the identified algorithm, and compares the result against every hash in the stolen file. When a computed hash matches a stored hash, the plaintext is recovered. This is a dictionary attack when the candidates come from a wordlist, and a brute-force attack when every character combination within a defined character set and length is tried exhaustively.

The third stage exploits precomputed data. A rainbow table is a large file of pre-calculated hash-to-plaintext mappings. Rather than computing hashes on the fly, the attacker looks up a stolen hash directly in the table. Rainbow tables are effective against unsalted hashes — those produced by running the password through the algorithm alone, with no additional random data mixed in.

Modern GPU hardware accelerates all three stages dramatically. A single consumer graphics card can compute billions of MD5 hashes per second. Against a large breach file containing millions of unsalted MD5 hashes, a significant fraction of common passwords can be recovered within hours.

The Algorithms, Salts, and Hardware Involved

Fast cryptographic hash functions (MD5, SHA-1, SHA-256): These were designed for speed and data integrity verification, not password storage. Their throughput — measured in billions of operations per second on modern hardware — makes them poorly suited as password hashing primitives. A hash computed in microseconds can be attempted billions of times per second by an attacker.

Password-specific hashing algorithms (bcrypt, scrypt, Argon2): These functions are deliberately slow and memory-intensive. bcrypt includes a configurable cost factor that increases the number of internal iterations; scrypt and Argon2 add memory-hardness, requiring large amounts of RAM per computation. An attacker cracking bcrypt hashes with a high cost factor may manage only thousands of attempts per second rather than billions, which changes the practical scope of an offline attack substantially.

Salts: A salt is a random string generated per user and stored alongside the hash. Before hashing, the salt is concatenated with the password. This means two users with identical passwords produce different hashes, and precomputed rainbow tables become useless — each cracking attempt must be computed fresh for each unique salt. The salt is not secret; its purpose is uniqueness, not confidentiality.

GPUs and distributed cracking clusters: Graphics processing units execute thousands of parallel threads, making them far more efficient than CPUs for the repetitive arithmetic of hash computation. Distributed cracking distributes a hash file across multiple machines, each working on a different segment of the candidate space simultaneously.

Wordlists and rule engines: Cracking tools apply transformation rules to wordlist entries — capitalizing the first letter, substituting numerals for letters, appending common suffixes — multiplying the effective candidate space without exhaustive brute force. The quality and size of the wordlist, and the sophistication of the rule set, directly determine which passwords are recovered. The relationship between password entropy and resistance to this process is also relevant to how cryptographically random password generation produces strings that fall outside the coverage of any practical wordlist.

Where Protections Fail and Where Attackers Hit Limits

The most significant failure mode is legacy algorithm use. Many services built before 2010 stored passwords as unsalted MD5 or SHA-1 hashes. When those databases are breached — sometimes years after the fact — the hashes crack quickly because the algorithm was never designed to resist offline attack. A breach disclosed today may involve a database schema that has not changed in a decade.

A second failure mode is low-entropy passwords. Even bcrypt with a high cost factor does not protect a password like password1 or 123456. These appear at the top of every wordlist. The cost factor slows the attacker, but the candidate is found on the first pass regardless. The protection that memory-hard algorithms provide is proportional to how far the password sits from common patterns — a property that key derivation functions also depend on when stretching a master password into an encryption key.

A third failure mode is pepper mismanagement. Some implementations add a server-side secret — a pepper — to the password before hashing, so that a stolen database alone is insufficient to crack hashes without also knowing the pepper. If the pepper is stored in the same database, or hardcoded in source code that is also leaked, it provides no additional protection.

On the attacker side, limits emerge with high-entropy passwords and memory-hard algorithms. A 20-character random string hashed with Argon2 at high memory cost is not practically recoverable with current hardware within any useful timeframe. The attacker's constraint is the combination of hardware throughput and the size of the candidate space the password occupies. Fully random strings of sufficient length fall outside any wordlist and make brute-force exhaustion computationally infeasible.

Credential stuffing represents a downstream effect of successful cracking. Once a plaintext password is recovered from one breach, automated tools test that username-and-password pair against other services. Password reuse across services transforms a single breach into access across multiple accounts — a propagation that occurs entirely outside the original victim service's visibility.

What Breach Monitoring Detects and What It Cannot Show

Identity-monitoring services aggregate leaked credential data — email addresses, usernames, and sometimes plaintext passwords recovered from cracked hashes — from publicly circulated breach files and closed forums. When a monitored email address appears in a newly indexed breach, the service generates an alert. This tells the account holder that their credentials were part of a specific breach event; it does not indicate whether the hash was successfully cracked, or how quickly.

What monitoring cannot determine is the current state of an attacker's cracking effort. A breach file indexed today may have been circulating in private channels for months. The hashes in it may already have been processed. The gap between breach occurrence and public disclosure — which the FTC has documented as a significant and variable interval in enforcement actions involving data security — means that exposure and cracking may precede any notification.

Breach monitoring also does not capture what happened to recovered plaintexts after cracking. A plaintext password recovered from a hash may be sold in a credential market, used directly, or incorporated into future wordlists that improve cracking rates against other breach files. The downstream use of cracked credentials is not observable through any consumer-facing monitoring tool.

Standards such as NIST Special Publication 800-63B address the hashing requirements directly, specifying that password verifiers must use memory-hard functions with salting and recommending minimum cost parameters. Compliance with these standards is a matter of how a service was built; a breach audit may confirm whether the algorithm used met current guidance, but it cannot retroactively change the protection applied to hashes already stolen. The broader question of what records a service holds — and what gets removed when requested — is a separate mechanism from hashing, one that involves how stored records are actually deleted at the data layer.

The cracking of a leaked password hash is a deterministic computation problem: given enough candidate attempts and sufficient hardware, any password with low entropy will eventually match its hash. The variables are algorithm choice, salt presence, cost parameters, and the password's position in the candidate space — all of which are fixed at the moment the password is first stored, long before any breach occurs.

Note: This explains how digital privacy and security tools work technically. It is not legal or cybersecurity advice, and it is not a substitute for a reader's own judgment about a real security concern. Check the cited sources for current guidance.