Security teams should never store plain passwords and should salt every password hash with a unique random value before hashing. Salting prevents attackers from reusing precomputed rainbow tables across many accounts. For stronger resistance, pair salting with a slow password based key derivation function such as PBKDF2, especially for highly sensitive accounts and master credentials.
Why salts break precomputed hash reuse
Precomputed hash attacks succeed when the attacker can compare stolen hashes against a reusable dictionary of candidate passwords built in advance. A unique salt changes the input to the hash for each password, so the same password no longer produces the same stored value across accounts. That forces the attacker to attack each password individually instead of amortising work across many targets.
Salting is effective because it defeats the main economic advantage of rainbow tables and other precomputation methods. It does not make a weak password strong, and it does not prevent online guessing, but it does remove the attacker’s ability to reuse one prepared table at scale.
For practitioners, the key design point is uniqueness: each password must have its own random salt, stored alongside the hash. A shared salt, a predictable salt, or a salt reused across accounts reintroduces the same reuse problem the control is meant to eliminate.
Why slow password hashing still matters after salting
Salting stops reuse, but it does not slow down an attacker who can brute-force a single account. That is why password hashes should also be computed with a deliberately slow password-based key derivation function, such as PBKDF2, bcrypt, scrypt, or Argon2, depending on your platform and policy. The goal is to make each guess expensive enough that offline cracking becomes materially less practical.
The cost factor matters most when the password protects a high-value account, a privileged operator login, or a master credential that can open additional systems. In those cases, the hash is not just an authentication artifact, it is a high-value secret boundary, so the work factor should be set with much more care than for low-impact consumer accounts.
Security teams should also validate that the implementation uses an approved password hashing scheme rather than a general-purpose fast hash. Fast hashes are designed for speed, which is exactly what an offline attacker wants. A slow derivation function turns the attacker’s workload into a time-and-cost problem rather than a simple dictionary lookup.
What good password storage looks like in practice
Strong password storage is a combination of controls, not a single setting. Salt every password with a unique random value, use a slow hashing algorithm, tune the cost factor to current hardware, and keep the stored hash format explicit enough that future migrations are possible. That way, when you need to raise the cost or move to a stronger scheme, you can do it without breaking verification.
Where possible, treat master credentials and administrative passwords as separate from ordinary user passwords in your operational review. Those credentials deserve stricter rotation, stronger hash parameters, tighter storage protection, and more scrutiny around reuse. If the same password policy is applied everywhere without risk-based differentiation, the highest-value accounts often end up underprotected.
Hashing hygiene also depends on surrounding controls. Limit where password hashes are stored, protect the database and backup layers that contain them, and monitor for exposure of credential stores. Salting and slow hashing reduce cracking efficiency, but they do not help if the stored hashes are copied out in bulk and left unprotected elsewhere.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers password, salt, and verifier lifecycle controls for stored credentials. |
| IA-7 — Cryptographic Module Authentication | Supports stronger authentication material handling when hashes protect privileged access. | |
| Recommendation — Use IA-5 to enforce salted, slow password hashing and secure authenticator handling. Apply IA-7 where password verifiers are part of higher-assurance authentication design. | ||
| CIS Controls v8 | CIS-5 — Account Management | Password storage and rotation practices sit within account and authenticator governance. |
| Recommendation — Harden account credential handling and review password storage practices under CIS-5. | ||
| OWASP ASVS | V6 — Authentication | Directly addresses password hashing, verifier storage, and authentication robustness. |
| Recommendation — Use V6 to require unique salts and slow password hashing for stored credentials. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Password hashing is a cryptographic protection decision for stored secret material. |
| Recommendation — Define and enforce approved cryptographic controls for password storage under A.8.24. | ||
Practitioner Guidance
What to verify: Confirm that every stored password uses a unique per-record salt and that no code path still relies on fast hashes such as SHA-256 or MD5 for password verification.
What to measure: Track the hashing work factor and the time required per verification so you can see when hardware changes or new policy targets make the current settings too weak.
Decision rule: If a credential can unlock privileged administration, sensitive data, or a master recovery path, treat its password hash as higher risk and apply the strongest approved password hashing settings available in your stack.
Practitioner takeaway: Salting prevents reuse, slow hashing limits cracking speed, and neither control is optional if the stored password is worth stealing.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
