Why Hash Passwords
Learn why passwords must be hashed before storage, how password hashing differs from general hashing, and why algorithms like bcrypt and Argon2 exist specifically for this.
Detailed Explanation
Password hashing is the practice of storing a one-way hash of a user's password instead of the password itself. When a user logs in, the system hashes the submitted password and compares it to the stored hash. This ensures that even if the database is breached, the actual passwords are not directly exposed.
Why not store passwords in plaintext?
Database breaches are common. If passwords are stored in plaintext, every user's password is immediately compromised. Users often reuse passwords across services, so a breach of one site can cascade into compromised accounts everywhere. Hashing ensures the attacker must perform significant computational work to recover each password.
Why not use SHA-256 for passwords?
General-purpose hash functions like SHA-256 are designed to be fast. A modern GPU can compute billions of SHA-256 hashes per second. An attacker with a stolen database of SHA-256 password hashes can try every common password, dictionary word, and pattern in minutes. This is why dedicated password hashing functions exist: they are deliberately slow and memory-intensive.
Purpose-built password hashing algorithms:
bcrypt (1999) incorporates a configurable work factor that makes each hash computation intentionally slow. At a work factor of 12, computing a single bcrypt hash takes roughly 250ms. scrypt (2009) adds memory-hardness, requiring significant RAM per hash to resist GPU and ASIC attacks. Argon2 (2015), winner of the Password Hashing Competition, offers tunable time cost, memory cost, and parallelism, providing the best defense against modern hardware. All three algorithms incorporate salt automatically.
Best practices:
Use Argon2id for new systems (recommended by OWASP). Use bcrypt if Argon2 is unavailable in your framework. Never use MD5, SHA-1, or SHA-256 alone for password hashing. Always use a unique random salt per password (bcrypt and Argon2 handle this automatically). Set the work factor so that hashing takes at least 250ms on your hardware. Implement rate limiting and account lockout as complementary defenses. Rehash passwords with stronger parameters during login as hardware improves.
Use Case
Every web application storing user credentials must hash passwords with bcrypt or Argon2 to protect users in the event of a database breach.