Hashing, bcrypt and password storage

A password must never be stored as-is, nor even encrypted - because anything encrypted can be decrypted. You store a one-way fingerprint: the hash. Here are the ideas to keep in mind before implementing authentication.

A hash is one-way

A hashing function turns an input into a fixed-size fingerprint with no way back. Verifying a password means re-hashing the input and comparing fingerprints. But fast hashes like MD5 or SHA-256 are built for speed - exactly what an attacker wants to test billions of combinations.

💡 Anecdote - A little-known trap: bcrypt ignores anything past 72 bytes, so a very long password is silently truncated.

Salt and cost

The salt is a random value added to each password before hashing. It ensures two users with the same password get different fingerprints, and makes precomputed tables useless. The cost (or work factor) deliberately makes the computation slow: negligible for a single login, ruinous for a brute-force attack.

The right tool for the job

For passwords, use a slow, salted algorithm designed for it: bcrypt, scrypt or argon2. Keep SHA-256 for file fingerprints and signatures, where speed is an asset. To experiment and compare algorithms on an example, our hash generator computes everything locally, never transmitting your text

🤓 Did you know? bcrypt is built on Bruce Schneier's Blowfish cipher, and its "cost factor" was designed back in 1999 to age well: you raise it as hardware speeds up, keeping hashing slow against Moore's law.