Password hashing

When someone signs up, the server runs their password through a password hashing function and stores only the result. At login it hashes the typed password the same way and compares the two. Each password gets a random salt (a unique value mixed in before hashing), so two people with the same password end up with different hashes and precomputed lookup tables, known as rainbow tables, are useless.

These functions are deliberately slow and, in the newer designs, memory-hungry, so guessing billions of passwords on graphics cards becomes impractical. OWASP recommends Argon2id (winner of the 2015 Password Hashing Competition) first, then scrypt, bcrypt for older systems, and PBKDF2 where FIPS-140 compliance is required. Plain SHA-256, MD5 or reversible encryption are not acceptable for passwords, because they are far too fast or can be undone.

Good libraries and frameworks (the argon2 and bcrypt packages, Django, Laravel, ASP.NET Identity) generate and store the salt for you, and the cost setting can be raised over time. bcrypt only reads the first 72 bytes of a password. Hosted services such as Supabase Auth, Firebase Auth and Auth0 handle all of this, and passkeys remove the stored password altogether.