Why do password hashes still need salts and cost tuning in modern applications?

Why Salts Still Matter Even When Hash Functions Are Strong

A password hash answers a security question, not a storage question: can this secret be verified without making offline guessing cheap? Salts ensure identical passwords do not produce identical hashes, which blocks precomputed rainbow tables and prevents attackers from reusing one cracked result across many accounts. That remains true even when the hash algorithm itself is modern.

Without a salt, one breached database can become a multiplier. Attackers can test common passwords once, compare against every account, and immediately identify users who share the same secret. With a unique salt per password, each guess must be recomputed for each record, which sharply raises the cost of large-scale cracking and makes breach data much less reusable.

A second benefit is that salts preserve ambiguity for defenders. When two hashes match, you should know the same password was used only if the design intentionally allows that inference. In modern authentication systems, that is usually the wrong trade-off, because repeated values are a signal attackers can exploit for clustering, prioritisation, and credential stuffing preparation.

Why Cost Tuning Is a Security Control, Not a Performance Detail

Cost tuning is the practical control that keeps a password hash expensive enough to resist offline guessing while still fast enough for legitimate sign-in flows. The goal is not maximum possible work, but the highest cost your application can sustain without creating an availability problem or an unusable login experience.

That balance matters because attacker economics and defender economics are not the same. A small increase in per-hash work may be negligible for one user logging in, but it becomes decisive when an adversary tries millions of guesses against a stolen hash database. The tuning decision therefore directly changes the amount of time, compute, and money required for attack at scale.

Modern guidance treats cost as something to revisit, not a one-time setup value. Hardware gets faster, authentication traffic changes, and application latency budgets tighten or loosen over time. If the work factor is never revisited, a design that was reasonable at launch can become cheap to brute force years later, especially for weak passwords or reused credentials.

For password storage specifically, current practice also expects memory-hard or deliberately expensive functions where appropriate, because simple fast hashes are unsuitable for password protection. Salts stop reuse. Cost stops scale. Those are complementary protections, not substitutes.

How Practitioners Should Set and Review Password Hash Parameters

What to verify: Confirm that every password gets a unique random salt, that the chosen algorithm is purpose-built for password hashing, and that work factors are applied consistently across all environments. If legacy records exist, verify whether they need staged rehashing on next login rather than a flag day migration.

What to measure: Measure login latency, CPU and memory impact under realistic concurrency, then tune to the highest cost that stays within your service targets. The right setting is the one that materially slows offline attacks without turning authentication into a bottleneck during peak usage or incident recovery.

Common mistake: Treating hashing as a compliance checkbox and leaving parameters unchanged for years. That approach often leaves older accounts under-protected, especially when the application has scaled, the hardware has improved, or password policy weaknesses make offline guessing more attractive.

Practitioner takeaway: Salt every password, tune the work factor deliberately, and review it as a living security parameter. The real objective is not to make hashing “strong” in the abstract, but to keep stolen password data expensive to exploit without degrading the user experience you must support.

Related resources from NHI Mgmt Group

• How should security teams choose a password hashing algorithm for modern applications?
• Why do password spray attacks still work in modern identity environments?
• Why does SQL injection still appear in modern applications?
• Why do blind XSS and DOM XSS still matter in modern applications?