Few topics attract more confident bad advice than password storage. The core ideas are simple, the details are unforgiving, and the mistakes are extremely common. Here is the plain version.
Hash ≠ password storage
A hash is a one-way function: same input, same output, impossible (in practice) to reverse. That makes SHA-256 great for integrity checks and terrible for password storage — because fast hashes are exactly what attackers want. They can try billions of guesses per second against a stolen hash list.
Related reading: How to Remain Valuable When Intelligence Becomes Cheap — a 224-page practical book on staying valuable as intelligence gets cheap. $3.84. Read it on Gumroad →
Why salt
A salt is a random value added to each password before hashing. It exists so that identical passwords produce different hashes, and so precomputed lookup tables ("rainbow tables") are useless. Salts are not secrets — they are stored next to the hash. The defense comes from the salt making every hash unique, not from hiding it.
The right tools
- Password storage: a key-derivation function designed for the job — bcrypt, scrypt, or Argon2. They are deliberately slow, and that slowness is the security.
- Integrity: SHA-256 or HMAC. Fast, standard, and correct for verifying that data has not changed.
- Identification: the Hash Type Identifier helps you recognize what a given hash actually is before you treat it as something else.
The rule
Do not design your own cryptographic scheme. The difference between "clever" and "broken" in cryptography is almost never visible in testing — it appears in the breach report years later. Use the standard primitives the browser already ships (crypto.subtle includes PBKDF2 and AES-GCM), use established constructions, and treat any homemade variant as a defect, not a feature.
