How should organisations hash passwords before storing them in a database?

How password hashing should work in practice

Password hashing should be designed so the original password is never stored, only a derived value that is expensive to reverse. That means using a password-specific algorithm, not a general-purpose hash, plus a unique salt for every password and a server-side cost setting that slows bulk guessing without breaking normal login flow. The goal is to make database theft far less useful to an attacker.

Modern password hashing also needs safe operational handling. Hashes should be computed on the server, stored alongside the salt and algorithm parameters, and compared in a way that avoids leaking timing differences. If you are still using a fast hash such as SHA-256 for password storage, the design is too weak for current attack rates and hardware.

Why salts, work factors, and algorithm choice matter

A unique salt stops identical passwords from producing identical stored values, which blocks rainbow-table reuse and makes precomputed cracking much less effective. A strong work factor, often called a cost parameter, forces the attacker to spend meaningful time and compute on each guess. That matters because password databases are usually attacked at scale, and fast verification is exactly what attackers want when they obtain a dump.

Algorithm choice matters because password hashing is a specialized problem. General-purpose hashes are built for speed and integrity, not resistance to offline guessing. Password hashing schemes are designed to be slow, memory-hard, or both, so each guess is intentionally expensive. When the algorithm or cost is too old, the protection can fail even if the password policy itself looks strong on paper.

Good password storage also supports controlled migration. Teams should be able to rehash on login when the algorithm or cost changes, without forcing a full password reset unless the stored material is too weak to trust. That keeps the system maintainable while avoiding unnecessary user disruption.

What secure storage and verification look like

The stored record should contain the hash, the unique salt, and the algorithm parameters needed to verify the password later. Secrets that help protect the database, such as application keys or pepper values if used, should be protected separately from the password table. The database itself should not be treated as the only control boundary, because compromise of the application tier or backups can expose the same material.

Verification should always compare the submitted password by hashing it with the stored parameters and matching the results on the server. The application should reject any workflow that tries to decrypt a password, reuse a plain-text backup, or downgrade to an older hash format without a migration plan. Strong storage is effective only when the rest of the credential lifecycle, including backup handling and access control, is equally disciplined.

Risk and Threat Considerations

Weak password hashing turns a database breach into an offline password-cracking problem, which is one of the highest-value outcomes for an attacker. Even if the application remains unavailable, stolen hashes can be tested at scale until reused passwords, weak passwords, or credential reuse across other services are uncovered.

Failure mechanism: Fast hashes, shared salts, missing cost factors, or poor parameter handling reduce the work required for offline guessing and make bulk cracking practical.

Impact: Attackers can recover passwords, pivot into other accounts that reuse them, and turn a single database exposure into broader account compromise.

Practitioner Guidance

What to prioritise: Use a password-specific hashing scheme with unique per-password salts and a tuned cost factor, then test that your login path still supports safe rehashing as you raise the work factor over time.

What to verify: Confirm that no code path stores plain text, uses a fast general-purpose hash for passwords, or exposes the same password hash format across environments without a migration strategy.

Practitioner takeaway: The right question is not whether passwords are hashed, but whether the stored form remains expensive to attack after a database theft and easy to evolve as cracking power improves.

Related resources from NHI Mgmt Group

• How should organisations handle weak, reused, or exposed passwords before attackers can exploit them?
• When should organisations fetch provider tokens at runtime instead of storing them in their own database?
• What should organisations check before removing passwords from user access flows?
• How should organisations test generative AI chatbots before putting them in production?