Step 1: What the Database Should Look Like

When you set a password on a well-built service, your actual password — let's say MyDogIsMax99 — is never stored anywhere. Instead, the server runs it through a hash function: a one-way mathematical operation that produces a fixed-length fingerprint.

The same input always produces the same output, but you cannot reverse the process. Knowing the hash tells you nothing about the original password — like knowing the ashes of a document tells you nothing about what was written.

Why This Matters in a Breach

When an attacker steals a database, they get a list of hashes — not passwords. To use them, they must crack each hash: find an input that produces the same output. This is where the security model lives or dies.

The Rainbow Table Attack

Before modern hashing, lazy developers used fast cryptographic functions like MD5 or SHA-1. These were designed for file integrity checks, not passwords — they run in microseconds, meaning a GPU can test billions per second.

Attackers built rainbow tables: pre-computed databases mapping millions of common passwords to their MD5/SHA-1 hashes. The moment they steal a database, they look up each hash in the table. If your password is anywhere in the top 10 million common passwords, it is cracked in under one second — no GPU required.

The Fix: Salting

A salt is a unique random string generated for each user and stored alongside their hash. Before hashing, the salt is prepended to the password:

• User A: hash("xR7q2k" + "MyDogIsMax99")
• User B (same password): hash("mP4j9n" + "MyDogIsMax99")

Same password, completely different hashes. Rainbow tables become useless — every entry would need its own table. The attacker must crack each password individually, from scratch.

Modern Hashing: Slow by Design

The next level of defence is using a password-specific hashing algorithm that is intentionally slow and memory-intensive:

• bcrypt (1999): Still widely used. Configurable cost factor — you choose how slow it runs. 100ms per hash means a GPU cluster tests 10 passwords/second instead of 10 billion.
• Argon2 (2015 winner of the Password Hashing Competition): Requires large amounts of RAM, defeating GPU parallelism. The modern gold standard.
• scrypt: Similar to Argon2, memory-hard. Used by some cryptocurrencies.

The Attacker's Timeline After a Breach

Here is roughly what happens in the hours and days after a database is stolen:

1. Hour 0–1: Attacker identifies the hashing algorithm from the hash format or source code leaks.
2. Hour 1–6: If MD5/SHA-1 and unsalted — most passwords cracked via rainbow table lookup.
3. Hour 6–48: If SHA-1 with salt — dictionary + rules attack on GPUs. Weak passwords fall quickly.
4. Day 2–∞: If bcrypt/Argon2 — only the weakest passwords (dictionary words, short passwords) are cracked. Strong unique passwords remain safe indefinitely.

What You Should Actually Do

You cannot control how a company stores your password. But you can control the blast radius when they inevitably mess it up:

• Never reuse passwords. If one service gets breached and your hash cracks, attackers will try that password everywhere within hours. Credential stuffing attacks are automated.
• Use a password manager. A 20-character random password stored in a bcrypt hash is essentially uncrackable. A 20-character random password reused across 50 sites is only as safe as the weakest site.
• Check haveibeenpwned.com. It indexes billions of leaked credentials. If your email appears, change that password everywhere you used it.