How Passwords Should Be Stored (Hashing)

Never store passwords in plain text. Store a one-way hash made with a slow, salted, password-specific algorithm like bcrypt, scrypt, or Argon2 - so a stolen database doesn't hand attackers everyone's password.

1. Hashing, Not Encrypting Store a one-way hash of the password, never the password itself. On login, hash the attempt and compare hashes - so a stolen database reveals no passwords. Hashing is not encryption.
2. Salt (and Why Plain SHA-256 Isn't Enough) Identical passwords hash identically, which rainbow tables exploit. A per-user random salt fixes that. And general-purpose hashes like MD5 and SHA-256 are far too fast - attackers can try enormous numbers of guesses per second.
3. Use a Slow Hash Built for Passwords bcrypt, scrypt, and Argon2 are deliberately slow, salted, and tunable via a work factor. Use a vetted library, never roll your own, verify with a constant-time compare, and add a breach/strength check at signup.