Password hashing protects stored login credentials by making password verification possible without storing the original password. Its purpose is different from encryption: a login system generally needs to check a submitted password, not retrieve the user’s old one. A database leak is still serious, but appropriate hashing raises the cost of guessing passwords offline.
Strong storage begins with a maintained authentication library and a measured configuration. It also includes migration, account recovery, and operational controls. This guide focuses on defensive application design rather than password cracking or testing accounts you do not own.
Choose an algorithm intended for passwords
Fast general-purpose hashes are designed to process data efficiently. That is useful for checksums but undesirable when an attacker can test many candidate passwords against a stolen database. Password-hashing algorithms deliberately impose computational cost, and some also require substantial memory.
OWASP recommends Argon2id as a preferred option under supported conditions and provides guidance for alternatives and compatibility constraints. Use a maintained library that implements the chosen algorithm correctly. Do not assemble your own construction by repeatedly applying a fast hash and guessing at a safe iteration count.
Check the platform, available implementation, and any applicable compliance requirements. An algorithm name alone is not a complete configuration. Its version and cost parameters affect both security and performance, so store the necessary verification information in the library’s supported format.
Let the library manage unique salts
A salt makes identical passwords produce different stored representations and defeats the usefulness of precomputed tables across accounts. It is not a replacement for a suitable algorithm or a strong user password. The salt is normally stored alongside the hash because verification needs it.
Use the password library’s salt-generation and storage behavior. Do not reuse one application-wide salt, derive predictable salts from usernames, or omit them because the database is encrypted. Independent defenses address different failure modes, and encrypted storage does not eliminate the possibility of a logical data export.
Protect the entire credential record from unauthorized modification as well as disclosure. An attacker who can alter authentication state can create problems beyond guessing passwords. Database permissions, application authorization, audit events, and backup access all belong in the review.
Measure work factors under real load
Choose cost parameters by following current guidance and benchmarking on representative infrastructure. A configuration that is expensive enough to slow guessing must still support legitimate login traffic. Include peak concurrency and the application’s other work, not just one isolated verification call.
Measure CPU, memory, and latency for failed as well as successful attempts. Deliberately expensive verification can be abused as a resource-consumption path if the public login endpoint has no protection. Rate limits and abuse controls complement hashing; they do not justify weak storage.
Avoid setting the same configuration forever. Record the decision date, algorithm, parameters, benchmark environment, and review trigger. Hardware and guidance change, and application traffic can make a previously reasonable setting operationally unsuitable. A measured policy is easier to improve than an unexplained constant.
Treat a pepper as a separate secret
A pepper is additional secret material used in an approved password-storage design. Unlike a salt, it must not be stored as an ordinary value beside the hash if the intended protection is separation from a database compromise. Use an appropriate secret-management mechanism and narrow access.
Follow a documented construction rather than improvising how the pepper is combined with a password hash. Plan what happens if it is lost or compromised. Rotation can require users to provide their passwords again or use a reset workflow, depending on the design; do not promise a transparent database-only rewrite.
A pepper adds operational responsibility. If every application instance can print it into logs or retrieve it without restriction, the theoretical separation may not survive a realistic incident. Review deployment, debugging, backup, and recovery paths before adopting it.
Upgrade hashes through supported verification
A practical migration often verifies a user’s password with the existing record and then rehashes that password under the new policy after successful authentication. The library may provide a needs-rehash check. This avoids requiring every user to reset immediately while improving active accounts over time.
Do not attempt to transform an old hash directly into the same result you would obtain by hashing the original password with a new algorithm. You generally do not have the original password, and layering arbitrary hashes is not equivalent to a properly planned migration.
Decide what to do with inactive accounts that never log in. A reset requirement or another documented lifecycle policy may be appropriate. Keep both old verification support and its removal deadline explicit so legacy records do not remain indefinitely by accident.
Protect the rest of the authentication flow
Hashing does not prevent phishing, credential reuse, session theft, or account-recovery abuse. Offer appropriate multifactor authentication and protect session handling. A perfectly stored password is not useful if a weak reset process lets another person take over the account.
Never log submitted passwords, derived intermediate values, or complete credential records. Diagnostic code and failed-login telemetry need deliberate redaction. Support staff should not ask users to disclose their passwords to investigate a problem.
Use established comparison and verification functions. Error responses should be reviewed for account enumeration and information leakage, while logs can record the operational event without its secret input. Balance usability, abuse detection, and privacy rather than treating one generic error message as the whole defense.
Test migration and recovery with synthetic users
Create test accounts using each supported legacy format and the new format. Verify successful login, rejected passwords, malformed records, and the rehash path. Check that concurrent successful logins do not corrupt the credential record or produce inconsistent account state.
Test dependency failures such as an unavailable secret store when a pepper is required. Decide whether the service fails safely, how it reports the incident, and how access is recovered. Do not silently fall back to a weaker storage method because a protected dependency is unavailable.
Include backups in the threat model. Historical credential records can remain sensitive after the live database has migrated. Restrict restore permissions and retention, and explain how a recovered backup enters the current migration policy before serving logins again.
Frequently asked questions
Should passwords be encrypted instead of hashed?
Normally, no. Login verification usually does not require recovering the original password. Use a maintained password-hashing mechanism suited to the application’s requirements.
Does a salt need to be secret?
No. Salts normally accompany hashes. A pepper is different: its value relies on secret handling and separation appropriate to its design.
Where can I find current parameter guidance?
Consult the OWASP Password Storage Cheat Sheet, then benchmark the supported implementation. For complementary account protections, see our passkey security guide.
