A site should never store your actual password — it stores a slow, salted hash. Done right, even a full database breach doesn't immediately hand attackers your password.
Why normal hashes are wrong here
SHA-256 is built to be fast — which is exactly wrong for passwords, because fast hashing lets attackers try billions of guesses per second (Password Cracking). Password hashing needs to be deliberately slow.
| Use | Hash |
|---|---|
| File integrity | SHA-256 (fast = good) |
| Passwords | bcrypt / scrypt / Argon2 (slow = good) |
The defenses
- Slow by design — a work factor you can tune up as hardware improves.
- Salt — a unique random value per password, so identical passwords hash differently and precomputed "rainbow tables" are useless.
- Memory-hard (scrypt/Argon2) — also expensive in RAM, defeating GPU/ASIC cracking.
$hash = password_hash($pw, PASSWORD_ARGON2ID); // salt + cost handled for you
password_verify($pw, $hash); // constant-time checkArgon2id is the current recommendation; bcrypt is a fine, ubiquitous default. Never store plaintext, never use plain SHA/MD5.
Related: Hashing Explained · Password Cracking · Securing a Public PHP App