Password storage

Verify a password without keeping a recoverable copy

An application normally needs to decide whether a submitted password is correct. It does not need to retrieve the user's original password. A password verifier produced by an appropriate password-hashing scheme supports that comparison without storing plaintext or a routinely decryptable password.

This distinction matters after a database exposure. A suitable verifier makes offline guessing more expensive, but it does not make weak passwords impossible to guess. Brute-force attacks explains the candidate-testing problem. The aim is to reduce the efficiency of that testing while maintaining a usable login service.

Two users choose the same password

Imagine a fictional membership service where two test accounts use the same password. If the service stores only the result of a fast, unsalted hash, the stored results match. An attacker can reuse guessing work across records and identify accounts with identical stored values.

A unique salt makes each password's computation distinct. The salt can be stored with the verifier and is not intended to be secret. It prevents one precomputed result from applying directly to every record with the same password. It does not change the fact that an attacker can test individual guesses when they obtain the database.

Password storage combines the submitted password, a unique salt, and a suitable cost setting to create a verifier rather than a recoverable password. Open full-size diagram ↗

Why a file hash is the wrong tool

A general-purpose cryptographic hash such as SHA-256 is designed to process data efficiently. That is useful for many integrity tasks, but fast computation helps an attacker test many password guesses. Password-hashing schemes deliberately impose additional computational or memory costs.

OWASP currently recommends Argon2id for appropriate new deployments and documents alternatives and configuration requirements. Use a maintained library and current guidance for the environment rather than inventing a repeated-hashing recipe. The Cryptographic hashing note explains the broader distinction between a digest and a password verifier.

Cost settings are an operational choice

Imagine the membership service raises its hashing cost substantially. Offline guessing becomes more expensive, but legitimate sign-ins also consume more resources. The team needs to benchmark expected load and consider how the login service behaves under abusive request volume. Strong settings and request controls support one another.

The stored record should identify enough about the scheme and settings for verification and future migration. An application can often upgrade an older verifier after a successful login when the password is available for verification, according to its migration design. Accounts that never return may need a different transition plan.

Salt and pepper have different responsibilities

A pepper is additional secret material managed separately from the password database. Unlike a salt, its protection and availability become secret-management responsibilities. Losing or rotating it can require a carefully designed migration or password-reset process. It should not be introduced as a decorative extra field beside the database it is meant to complement.

For a beginner exercise, diagram registration and later sign-in using invented values. Label which information is stored, which must remain secret, and how the comparison happens. Do not write a production password system from the diagram; use it to understand a maintained implementation and the requirements behind it. Continue with Authentication for the complete login flow.