Password hashing (bcrypt/argon2)
Storing a slow, salted one-way scramble instead of the password. Nobody can read it back, but a login attempt can still be checked.
See it
What it is
A password hash is a one-way scramble: you can check a guess against it, but you cannot turn it back into the password, not even with the database in hand. The trick is that password hashing deliberately uses slow functions. bcrypt, scrypt, and Argon2id are tuned so one check costs real CPU time (and, for Argon2 and scrypt, real memory), which makes billions of offline guesses per second impractical. Each hash also carries a random salt, so two people with the same password get different stored values and precomputed rainbow tables are worthless.
Use Argon2id if your language has a maintained binding, bcrypt if you want the boring, everywhere-available option. Store the whole encoded string (algorithm, cost parameters, salt, digest) in one column so you can raise the cost factor later and rehash on next successful login.
Gotcha: SHA-256, MD5, and 'encrypting' the password are all wrong answers. General-purpose hashes are fast by design, which is exactly the property you do not want, and encryption is reversible by whoever holds the key. Two smaller traps: compare with the library's own verify function (it is constant time), and know that bcrypt silently ignores input past 72 bytes.
Ask AI for it
Store passwords with Argon2id (fall back to bcrypt with cost 12 if Argon2 is unavailable): hash on signup with a per-password random salt, save the full encoded hash string in a single column, and verify logins with the library's constant-time verify function. Never use MD5, SHA-1, SHA-256, or reversible encryption. Rehash with current parameters after a successful login when the stored cost is outdated, and never log or return the password or the hash.