Your Password Was Hashed and Salted. So Why Is It Still in the Breach?

Salted hashing is not a vault. It’s a speed bump — and for most attackers, not even a significant one.

when an attacker dumps a database, they get both the hash and the salt. The salt was never secret. It’s stored in plaintext right next to the hash. From that point, they run cracking completely offline — no rate limits, no lockouts, no logs — for as long as they want. What protects you (or doesn’t) is the algorithm used and the strength of your password. For millions of accounts in real-world breaches, neither is good enough.

That’s the short version. Here’s exactly how each piece breaks.

1. The Attack Runs Offline. Entirely.

This is the part most people don’t think through.

Once the attacker has your database dump, they leave your servers alone. They take the data home — or to a rented GPU cluster — and run this loop:

for candidate in wordlist:
    if hash(candidate + salt) == stolen_hash:
        # cracked

No lockout after 10 attempts. No CAPTCHA. No alerts firing in your SIEM. The attacker is on their own hardware, running at full speed, indefinitely. Every protection your login system has — rate limiting, 2FA prompts, suspicious login alerts — is completely irrelevant at this stage. Those defences protect your login endpoint. The data is already gone.

2. The Hash Algorithm Decides Everything

If the company used MD5 or SHA-256 to hash passwords, the salt barely matters.

MD5 computes 60 billion hashes per second on a single consumer GPU. At that speed, running every word in a large wordlist against one hash takes milliseconds. Running it against every hash in a 10 million user database is still done in hours.

MD5 was designed to be fast — for checksums, file integrity, data pipelines. Using it for passwords is an engineering mistake, not a configuration slip. The design goal is directly opposed to what password hashing needs.

Algorithms like bcrypt and Argon2id are slow by design. Argon2id is also memory-hard, meaning it requires significant RAM per computation. GPUs, which are fast at parallel compute, are crippled by memory bandwidth constraints. That’s the actual defence. Not the salt.

3. Weak Passwords Die First, Regardless of Salt

Salting cannot fix the password Summer2019!.

The RockYou dataset — 14 million real passwords from a 2009 breach — is still the first wordlist crackers use. It works because people keep picking the same passwords. Stack on rule-based mutations: capitalise the first letter, append a year, swap a for @, and you've covered the vast majority of passwords real humans choose.

If a user’s password follows a pattern that exists in any standard ruleset, it gets cracked regardless of whether you used bcrypt or Argon2id. The maths is sound. The input is the problem.

4. “Salted” Is Not Always What It Sounds Like

Not all salted implementations are equal. Several common mistakes make the protection nearly worthless:

Single global salt. One salt shared across all users defeats the entire point. An attacker can now build a rainbow table for that one salt and look up every user simultaneously.

Predictable salt. If the salt is derived from the username, email, or user ID, an attacker can precompute hashes for common values — admin, root, info@company.com — before the breach happens.

Salt too short. A 4-byte salt has only ~4 billion possible values. Precomputed tables covering all of them are feasible. Use at least 16 bytes from a cryptographically secure random source.

Broken randomness. Seeding a standard PRNG with the current timestamp is not cryptographic randomness. If an attacker can approximate when accounts were created, the effective salt space collapses.

If the salt generation doesn’t use os.urandom(), crypto.randomBytes(), or the platform equivalent — it's not a real salt.

5. The Hash Isn’t the Only Thing That Got Stolen

Even if every password in the database remains uncracked, the breach is still a serious event.

A typical user database also contains email addresses (enabling targeted phishing on other platforms), names, dates of birth, phone numbers, and security question answers. That’s enough for identity fraud and account recovery bypasses on services with weaker verification.

Then there’s credential stuffing. Most users reuse passwords. If that same user’s credentials appeared in any prior breach that was cracked, the attacker already has the plaintext — and they’ll try it against every service they can reach. The quality of hashing in the current database is irrelevant. The password was already known from somewhere else.

6. The Clock Works in the Attacker’s Favour

Cracking is not time-limited. An attacker who steals a database today can crack it over months or years.

A bcrypt hash configured for 2019 hardware might have been very strong then. As GPU performance doubles, the same hash becomes weaker — not because anything about the hash changed, but because the attacker’s compute budget did. This is why bcrypt and Argon2id have configurable work factors. The intent is that you increase the cost as hardware improves, forcing a re-hash at login over time. Static hashing parameters age badly, and most production systems never revisit them.

7. Sometimes There’s No Cracking Required

Some application failures hand attackers plaintext passwords without any cryptanalysis:

• Passwords included in URL query parameters, logged by load balancers or access logs
• Verbose error logs that echo the full request payload on a failed login attempt
• Crash dumps and heap captures taken while the password is in active memory
• Debug endpoints left enabled in production that reflect submitted form fields

These bypass the entire hashing layer. They’re uncommon in mature systems. They’re not uncommon in smaller applications.