Secure Password Storage and Hashing

Understand the stored verifier

A password database should contain a one-way verifier, not the original password. A password-hashing function deliberately consumes memory or computation so large-scale guessing is more expensive if verifiers are stolen. The application recomputes a candidate verifier during sign-in and compares it using the library's supported verification method.

A unique random salt prevents identical passwords from sharing the same stored result and defeats precomputed tables. Mature password libraries create and encode salts with parameters automatically. Salts are not secrets and can be stored beside the verifier. Do not replace them with one global static value or manually truncate library output.

Select current parameters safely

Use the algorithm currently recommended by OWASP for the platform and available libraries, then choose work settings through measured tests on production-like hardware. Verification should resist guessing without creating unacceptable sign-in latency or an easy denial-of-service condition. Published recommendations change, so avoid freezing numeric advice into permanent application assumptions.

Benchmark under expected concurrency and monitor resource use. Store algorithm and parameter metadata with each verifier so records can evolve. Use maintained libraries instead of implementing cryptography. Security review should confirm random generation, comparison behavior, input limits, error handling, and deployment configuration rather than relying on the algorithm label alone.

Protect surrounding authentication data

An optional pepper can add protection when it is held outside the password database in an approved secret manager or hardware-backed service. Its access should be least privilege, audited, and separated from routine database backups. Pepper rotation may require password resets, so document recovery and incident decisions before adopting one.

Use encrypted transport, protect session handling, and rate-limit sign-in through a risk-aware design that avoids locking out targeted users. Never log passwords, candidate values, or verifier material. Restrict database and backup access, monitor unusual exports, and prepare escalation for suspected disclosure. Password hashing does not compensate for weak authorization elsewhere.

Migrate and verify without disclosure

When a valid sign-in uses an older verifier, the application can rehash the submitted password with current settings and replace the record after successful verification. Accounts that do not return may need a reset campaign. Do not decrypt old passwords, request them by email, or silently weaken parameters to simplify migration.

Test migration with synthetic accounts across every supported legacy format, interrupted writes, pepper unavailability, concurrent sign-ins, and reset paths. Confirm database backups and rollback before deployment, but ensure restored data follows the same protection. Review current OWASP guidance, library support, measured work factors, access grants, and incident readiness quarterly.

Upgrade an owned legacy login service

A service stores salted verifiers made with an outdated work setting and needs a gradual migration without learning user passwords.

1. Inventory verifier formats, library versions, authentication paths, database access, backups, and reset dependencies.
2. Select a maintained library and current OWASP-aligned configuration after benchmarking production-like concurrency.
3. On successful legacy verification, create a new verifier and replace the record through an atomic database update.
4. Test synthetic legacy accounts, failed passwords, concurrent requests, interrupted updates, and account recovery in staging.
5. Monitor migration counts and errors, restrict verifier access, preserve rollback, and escalate any sign of data exposure.

Password verifier management playbook

Use this playbook to review storage, upgrades, and incident readiness.

• Library and algorithm: maintained implementation, current official guidance, supported formats, and accountable owner.
• Parameters: measured latency, memory or work settings, concurrency test, input limit, and review date.
• Data protection: unique salts, separate pepper storage, least database privilege, backups, and prohibited logging.
• Migration: format detection, successful-login rehash, reset path, atomic update, rollback, and user communication.
• Response: disclosure indicators, access evidence, pepper decision, reset authority, escalation, and quarterly reassessment.

Common mistakes

• Using a fast general-purpose digest because its output looks random and is easy to calculate.
• Encrypting passwords reversibly so the application or support team can retrieve them later.
• Changing verifier configuration without testing resource exhaustion, migration failures, backups, and account recovery.

Try one

Sources

• OWASP Password Storage Cheat SheetOWASP current recommendations for password hashing and migration.
• OWASP Secrets Management Cheat SheetOWASP guidance for secret creation, storage, access, rotation, and retirement.