How should security teams reduce the risk of hashed passwords being cracked after a breach?

Why breached hashes crack in practice

A breached password database is not a finished object, it is an input to offline guessing. If the same password appears across many accounts, or if the hash is unsalted or weakly stretched, attackers can test common and reused passwords at scale until they find matches. The practical goal is to make each stored hash expensive and unique enough that bulk cracking stops being economical.

That is why password storage and password policy should be treated as one control plane. Long passwords slow guessing, unique salts prevent identical passwords from producing identical hashes, and breached-password screening stops users from choosing values that are already in attackers’ dictionaries. Together, these measures reduce the utility of a stolen credential store.

For teams modernising password policy, NHIMG’s Password Security and Password Manager Guide gives the broader policy context for length, reuse, blocklists and password manager adoption.

What salts, length and blocklists each do differently

Unique salts are the first line of defence against precomputation and hash comparison. A salt does not hide weak passwords on its own, but it ensures that two users with the same password do not share the same derived value, which breaks rainbow-table style reuse and makes mass cracking less efficient. Long passwords help by expanding the search space, while blocklists remove the most predictable candidates before they ever become stored secrets.

These controls solve different problems, so one should not be treated as a substitute for another. A salted hash can still fall quickly if the password is short and common, and a long password is still risky if the same value has already appeared in a prior breach. Screening against known-compromised passwords therefore matters at both account creation and password change time.

When you are deciding how strict the screening should be, NHIMG’s Breached password checks article is useful for the operational details of using breach corpora and blocklists in a login flow.

How to reduce crackability without creating user friction

The best implementation is usually policy-led rather than heroically cryptographic. Use a modern password hashing algorithm with per-password salts, enforce a sensible minimum length, and reject passwords that appear in known-breached or commonly used lists. That gives you a defensible baseline without forcing users through brittle complexity rules that encourage predictable workarounds.

Teams should also think about the surrounding process, not only the storage layer. If password resets, help-desk recovery, or reuse across services remain weak, attackers may bypass strong hashing entirely by targeting the account lifecycle instead of the database. Good password defence is therefore as much about preventing weak credential choices as it is about hardening the stored hash.

For teams evaluating the broader response if a password store or vault is exposed, NHIMG’s Password Manager Vault Breach Response Playbook is a practical companion on prioritising rotation and re-enrolment.

Risk and Threat Considerations

The main risk is not that every hash will be cracked, but that attackers can selectively recover the weakest and most reused passwords first, then reuse them for account takeover elsewhere. The more common the password, the more likely it is to be cracked quickly enough to matter operationally, especially when the same secret is reused across email, VPN, admin portals or third-party services.

Failure mechanism: Attackers obtain the hash database, run offline guessing against weak or reused passwords, and use recovered credentials for impersonation, lateral access or credential stuffing in other systems. Weak salts, short passwords and missing breached-password checks all shorten the time to compromise.

Impact: A single breach can turn into repeat account takeover, privilege escalation and broader exposure if recovered passwords are reused. Even when the original system is hardened later, cracked credentials may continue to be abused elsewhere.

Practitioner Guidance

What to verify: Confirm that every stored password is uniquely salted, that the hashing scheme is current and that the minimum length and blocklist checks are enforced consistently across self-service registration, password change and recovery flows. If one path allows weaker credentials than the others, attackers will find it.

Decision rule: If a password has appeared in a breach corpus or is short enough to be guessed quickly, treat it as unacceptable regardless of hash strength. If the same password may already exist on other employee or customer accounts, assume downstream compromise risk and prioritise reset workflow hardening before tuning any other policy.

Practitioner takeaway: Strong password hashing reduces exposure, but only layered password policy makes stolen hashes materially harder to crack and reuse at scale.

Related resources from NHI Mgmt Group

• How should security teams reduce phishing and account takeover risk after a third-party analytics breach exposes user profile data?
• How should security teams reduce breach risk when remote access still depends on passwords and weak MFA factors?
• How should security teams reduce the risk of data exfiltration after valid accounts are abused in a telecom breach?
• How should security teams reduce breach risk when passwords and valid accounts are the main attack path?