A leaked hash table isn't a leaked password table — that distinction is the entire reason password hashing exists. But it's not nothing, either, and treating "we hashed them" as the end of the incident is exactly how a breach at one company quietly becomes a second breach at several others. What actually happens next depends on one question first, and then on what everyone involved does in the days after.
The question that decides everything: how were they stored?
The same word — "hashed" — covers a huge range of actual exposure, and the gap between the best and worst case is the difference between an inconvenience and a five-alarm fire:
- Plaintext, or reversible encryption. Every password is exposed immediately, in full, the moment the table is stolen. There is no cracking step — this is the worst case by a wide margin, and unfortunately still a real one; see Password Hashing Explained for why reversible encryption belongs nowhere near password storage.
- A fast, general-purpose hash — raw SHA-256, MD5, or SHA-256 applied more than once. Not immediately exposed, but close: a single consumer GPU computes billions of guesses per second against these, and the common, weak, or previously breached passwords in the table — often a large fraction of any real user base — fall within hours. See Why SHA-256 Should Not Be Used for Passwords for the actual throughput numbers.
- A real password-hashing algorithm — Argon2id, bcrypt, or scrypt at a reasonable cost factor. Cracking is real but slow, six to seven orders of magnitude slower than the fast-hash case for the identical attack — see How Long Does It Take To Crack A Password? for what that gap actually looks like in hours versus centuries. Slow is not the same as safe, though — the weakest, most common passwords in the table are still the first casualties, regardless of algorithm.
Password Hash Inspector identifies which of these a given hash actually is in seconds — the first thing worth doing in a real incident is confirming which scenario you're actually in, not assuming.
What an attacker actually does with a stolen table
Not brute-force everything — that's rarely necessary and rarely how it starts. How Long Does It Take To Crack A Password? covers this directly: the top entries from breach-derived wordlists are tried first, against every hash in the table simultaneously, and land instantly regardless of the hashing algorithm — a slow hash doesn't protect password123, it just makes the attacker's next several thousand guesses more expensive. What's left after the easy wins get cracked is the genuinely random, unique passwords — the ones a real cracking effort, at whatever rate the hash algorithm allows, is spent on.
Every successful crack produces the same output: a confirmed, correct username-and-password pair. That pair is worth something regardless of whether the attacker cares about your specific service at all — which is the part that makes this everyone's problem, not just yours.
Why this becomes a problem for other companies, not just you
A cracked password from your breach is immediately useful against every other account the same person has, anywhere, if they reused it — and Credential Stuffing Explained covers exactly how that gets automated: the exact attack that made your breach significant to begin with is the same one that now runs the cracked pairs from your table against completely unrelated sites, at scale, with no further guessing required. Password reuse rates run 50-65% in the research cited there, which means a meaningful share of your cracked accounts are now live ammunition against services that were never touched. This is the actual shape of the downstream damage — not one company's incident, but a supply of fresh, confirmed credentials feeding attacks against everyone else's users for months afterward.
What the breached organization should actually do
- Force a reset — even with a strong hash. Password Hash Migration Strategies is explicit about this: a confirmed or suspected breach of the table itself calls for a forced reset, not a rehash. You can't know how much progress an attacker already made before detection, and Argon2id or bcrypt only changes how long that progress takes — not whether it's already underway.
- Rotate a pepper, if one exists. If a pepper protected the table and it wasn't also exposed, the hashes alone are far less useful to an attacker — confirm that boundary held before treating this as lower-severity. Understanding Salt and Pepper covers why a pepper only helps if it lives somewhere the same compromise didn't reach, and how to rotate one without locking out every account at once.
- Notify affected users clearly and promptly. Beyond the legal obligations that may apply, users need to know specifically because of the downstream risk above — anyone who reused that password elsewhere needs to change it there too, not just with you.
- Check whether the leaked corpus reaches breach-checking services. Once a credential set is public or circulating, other sites' NIST-mandated breach-checking (see NIST Password Guidelines Explained) can only catch reuse of it once it's actually in that corpus — which is part of why responsible disclosure and cooperating with services like Have I Been Pwned reduces harm beyond your own user base.
Common mistakes
- Treating a strong hash as a reason to skip the reset. The algorithm affects the attacker's timeline, not whether a reset is warranted once the table itself is confirmed stolen.
- Fixing the vulnerability without addressing the exposure. Patching whatever let the table leak matters, but it doesn't undo the fact that a copy is already out — the two are separate problems needing separate responses.
- Assuming your own MFA makes this a non-event. MFA on your service protects your service. It does nothing for the same user's account on a different site that doesn't require it — which is exactly the account credential stuffing targets next.
- Going quiet instead of notifying quickly. Every day of delay is another day the credential-stuffing window stays open on sites that haven't been warned to expect it.
FAQ
If we used Argon2id, do we still need to force a reset?
Yes. A strong, slow hash raises the cost and the time an attacker needs — it doesn't establish that no progress has been made, and a confirmed table compromise is treated as a reset event regardless of algorithm.
Does this affect users who used a unique, strong password with us?
Far less than users who reused one — a truly unique, sufficiently long password is unlikely to be cracked before a reset can happen, and reuse elsewhere isn't a risk if the password was never used elsewhere. It's still correct to reset it, since "far less likely" isn't the same as safe.
How fast could our specific hashes actually be cracked?
Depends on the algorithm and cost factor — How Long Does It Take To Crack A Password? walks through real numbers by password style and attack scenario, and Password Cracking Time Estimator runs the same math for a specific length and character set.
Is a hashed-and-salted table basically the same as a leaked plaintext table?
No — that gap is the entire reason hashing exists, and treating them as equivalent undersells why the work matters. But "better than plaintext" isn't the same as "safe to ignore," which is the actual point of this post.
Try it yourself
Password Hash Inspector identifies exactly what algorithm and parameters a given hash uses, and Password Storage Checker grades a system's hashing, salting, MFA, breach-checking, and rate-limiting practices together against OWASP and NIST guidance — worth running before an incident, not just after one. Both run entirely in your browser.