# Choosing a Password Hash

> Storing passwords safely is a solved problem: use a purpose-built, salted, slow password hash, not a raw digest. This is a short decision guide, from the algorithm to pick to the parameters to set and the mistakes to avoid, aligned with OWASP and NIST guidance.

Source: https://ronutz.com/en/learn/choosing-a-password-hash  
Updated: 2026-07-01  
Related tools: https://ronutz.com/en/tools/hash-preimage-finder

---

Password storage is not where to be creative. The safe path is well established.

## The first rule

Never store passwords with a plain fast hash (MD5, SHA-1, SHA-256) or with reversible encryption. A fast hash is exactly what brute force beats, and reversible encryption means a stolen key exposes every password.

## Pick an algorithm

In order of preference: **Argon2id** as the default, then **scrypt**, then **bcrypt**, and **PBKDF2** only where FIPS compliance forces it. All of them salt automatically or must be given a unique salt.

## Set the parameters

Tune the work factor so a single hash takes a chosen wall-clock time on your hardware, then raise it as hardware improves. OWASP publishes current starting points, for example Argon2id memory and iteration settings and bcrypt cost factors.

## Salt, and optionally pepper

Use a unique random salt per password; the libraries handle this. You may add a server-side secret, a pepper, kept out of the database, so a database-only leak is not enough.

## Favor length over rules

Allow long passphrases, screen new passwords against known-breached lists as NIST recommends, and avoid composition rules that hurt usability without adding entropy.

## Migrating off a weak scheme

When moving away from a fast hash, either rehash each password on next login or wrap the old hash inside the new KDF, and never keep the fast-hash version around.