Why should you hash passwords with bcrypt instead of SHA-256 or storing them in plain text?
Plain text leaks everything in a breach. SHA-256 is designed to be fast, so attackers can test billions of guesses per second. bcrypt is deliberately slow, adds a unique salt, and its cost can be raised over time.
Explain it simply
Think of storing passwords as locking a door. Plain text is leaving the key under the mat. A fast hash like SHA-256 is a lock that anyone can try thousands of keys on in a second. bcrypt is a lock that takes a noticeable moment for each attempt, which is nothing for one honest login but ruinous for someone trying a billion guesses.
Two ideas make bcrypt a good fit:
- Salt: a random value mixed into each password before hashing. Two users with the password
india123get completely different hashes, so one precomputed table cannot crack everyone. - Work factor (cost): how much computation each hash needs. As computers get faster you raise it.
Hashing is one-way: you never decrypt, you hash the login attempt and compare.
Example
const bcrypt = require("bcrypt");
async function demo() {
const hash = await bcrypt.hash("india123", 12);
console.log(hash.length); // 60
console.log(await bcrypt.compare("india123", hash)); // true
console.log(await bcrypt.compare("india124", hash)); // false
}
demo();Other good choices are argon2 and scrypt. SHA-256 is fine for checksums or signing, just not for passwords.
What to say in the interview
"I never store plain passwords. I use a slow, salted algorithm like bcrypt or argon2, so each password has its own salt and guessing is expensive. SHA-256 is too fast for this purpose."
Common mistakes
- Encrypting passwords instead of hashing them.
- Using one global salt (a "pepper") as the only protection.