Password Hashing and GPU Cracking Economics Lab (Interactive)
From MD5 to Argon2id: price attacker hash-rates against honest login latency. Model a GPU rig against bcrypt cost, Argon2id memory-hardness, password search space, salts, and peppers to compute median crack time and login cost.
Password KDF Cracking Economics
Tune the algorithm, work factors, password policy, and attacker GPU fleet — then read the offline-cracking bill.
Search space
2.2e+14
Cluster hash rate
3.20e+3 h/s
Per-GPU rate
4.00e+2 h/s
Login latency (server)
250 ms
Salts force a per-hash restart: rainbow tables (precomputed password→digest maps) collapse to uselessness, and identical passwords produce different digests.
Memory hardness is the point: each attempt wants 64 MB of fast RAM, so a 24 GB GPU holds only 384 parallel instances — the thousands of ALU cores starve.
No pepper: whoever steals the users table owns the offline cracking contest; a pepper stored outside the DB removes that single point of failure.
Rates are an educational model calibrated to the topic's figures (a single RTX-class card does ~1011 SHA-256 h/s; bcrypt cost 12 ≈ 250 ms/check). Hashing is one-way: unlike encryption, no key turns the digest back into the password — which is precisely why cracking is a search, not a decrypt.
How It Works Under the Hood
Password verification is a deliberate war of asymmetry: honest systems check one hash per login, attackers check trillions per second offline against a stolen table. MD5 on GPUs verifies around 440 billion guesses per second, bcrypt raises cost exponentially per power-of-two work factor, and Argon2id additionally demands megabytes of memory per guess so GPU fleets (1.2 trillion SHA-256 H/s) starve on memory bandwidth. A per-user salt kills rainbow-table amortization; a server-side pepper (an HMAC secret) helps only while that secret stays hidden. The simulator turns hash-rate math into median time-to-crack for your chosen length and charset, then shows the latency bill honest users pay for that defense.
Core Architectural Principles
- Attacker rate = GPU fleet x algorithm throughput scaled by bcrypt 2^cost or Argon2 memory per guess.
- Search space = charset_size^length; median crack time is half the space divided by the fleet rate.
- Salt forces per-user brute force; a pepper adds a hidden HMAC key the DB leak alone cannot supply.
Say passwords are hashed never encrypted, and pick a memory-hard function: Argon2id, or bcrypt with cost at least twelve. Quantify the threat: offline GPU cracking of a stolen table, rainbow tables defeated by per-user salts, and the login-latency budget (sub-300 ms) that caps the work factor. Mention pepper cautiously and rate-limiting verification endpoints as the operational companion.
Heavier KDFs slow offline attackers but tax every honest login, and pepper secrets reintroduce a key-management dependency.