Passwords Are Not "Stored"
Any reputable web service does not store your password as-is. What's stored is a "hash value" generated by passing the password through a one-way function (hash function). The original password cannot be recovered from the hash value.
During login, the server hashes the entered password and compares it with the stored hash value. If they match, authentication succeeds. The password itself is never recorded on the server's storage, not even for a moment.
So why go through this roundabout process? It's to minimize the damage when a database is breached.
The Horror of Plaintext Storage - Real Incidents
When a company that stored passwords in plaintext (as raw strings) suffers a data breach, every user's password is immediately in the attacker's hands.
- Adobe (2013): 153 million account records leaked. Passwords were encrypted but stored using reversible encryption (3DES-ECB) rather than hashing, meaning identical passwords produced identical ciphertext. Frequency analysis allowed massive numbers of passwords to be cracked
- RockYou (2009): 32 million passwords leaked in plaintext. This data is still widely used as a dictionary for password cracking today
- Facebook (2019): Hundreds of millions of passwords were found logged in plaintext in internal systems. While there was no external leak, they were viewable by anyone within the company
If passwords are hashed, all an attacker gets from a database breach is hash values. To discover the original passwords, they'd need to "reverse" the hash values, but with proper hash functions, this is computationally infeasible.
The Evolution of Hash Functions - From MD5 to bcrypt
MD5 and SHA-1 - Too Fast to Be Safe
Early password hashing used MD5 or SHA-1. However, these were designed with the goal of "fast computation," which is actually counterproductive for password hashing. Modern GPUs can compute tens of billions of MD5 hashes per second, cracking short passwords through brute force in seconds.
Salt - Different Hashes Even for the Same Password
A salt is a random string added to a password before hashing. Even the same password "password123" produces different hash values for each user because different salts are added. This neutralizes attacks using precomputed hash tables (rainbow tables).
bcrypt - An Intentionally Slow Hash Function
bcrypt (1999) is a function designed specifically for password hashing. Its key feature is being "intentionally slow." A cost factor (work factor) parameter allows adjusting the computational cost, which can be increased as hardware performance improves.
If bcrypt is configured to take 100 ms per hash computation, legitimate logins (one computation) are barely affected, but brute-force attacks (billions of computations) become virtually impossible.
Argon2 - The Current State of the Art
Argon2 won the Password Hashing Competition in 2015 and can adjust not only computation time but also memory usage. It offers higher resistance to GPU-based parallel attacks than bcrypt.
If "Forgot Password" Sends You Your Original Password, That's a Red Flag
If a service sends you your original password by email during a password reset, that service is storing passwords in plaintext (or reversible encryption). If passwords were hashed, recovering the original would be impossible.
A proper implementation has the password reset flow set a "new password." A service that can tell you your original password is proof that it doesn't understand security basics.
Summary
Password hashing is a defense built on the premise that "databases will be breached." Hash functions have evolved from the MD5 era through bcrypt to Argon2, continuously countering the growing computational power of attackers.
What you can do as a user is use different strong passwords for each service, enable two-factor authentication, and if possible, migrate to passkeys. Just as you check your network information on IP Check-san, periodically review the state of your password management as well.