Why Big Tech Shuns MD5 for Passwords: Inside Bcrypt and JWT Security

Many developers initially store passwords with a simple password -> md5(password) operation, believing the hash is irreversible. In modern security architectures this is considered a high‑risk design because traditional hash functions like MD5 or SHA‑256 compute too quickly.

Fast hashes enable attackers to perform brute‑force enumeration, rainbow‑table lookups, GPU‑accelerated cracking, or ASIC cluster attacks.

High‑end GPUs can calculate billions of SHA‑256 hashes per second, so leaked password lists containing common passwords (e.g., 123456, password, qwerty, admin123) are cracked almost instantly.

Bcrypt’s Intentional Slowness

Bcrypt is designed to be deliberately slow to turn password verification into a time‑war against brute‑force attacks. Its core parameter cost determines the number of iterations as Iterations = 2^cost. For cost = 10, Bcrypt performs 1024 iterations, typically taking about 80 ms per verification.

User login feels almost instantaneous.

Attacker’s brute‑force cost explodes.

Bcrypt embeds the salt directly in the resulting hash string, which also contains the algorithm version and cost factor, e.g., $2b$10$Eix9XYZabcdefghijklmno789pqrstuvwxyz1234567890. The bcrypt.compare() function automatically extracts these components, so developers only need to pass the plain password and the stored hash.

JWT’s Real Purpose

JSON Web Tokens (JWT) are primarily about stateless authentication . Unlike traditional session storage, the server does not keep session state; the client carries the token.

A JWT consists of three Base64Url‑encoded parts: Header.Payload.Signature. The signature is computed as Signature = HMAC‑SHA256(Header.Payload, JWT_SECRET), where JWT_SECRET is known only to the server.

JWT does not encrypt the payload; anyone who obtains the token can read its contents.

Therefore, sensitive information such as phone numbers, ID numbers, passwords, bank cards, or other private data must never be placed in the payload.

Token Revocation and the “Stateless” Paradox

Because a JWT remains valid until its expiration, revoking a token is a common interview question. The industry‑standard solution is to maintain a Redis blacklist: when a user logs out, changes a password, or is banned, the token is added to Redis with a TTL matching its remaining lifetime. During verification, the system checks both jwt.verify() and redis.exists(token) to enforce double validation.

DoS Risks of Bcrypt

Bcrypt’s CPU‑intensive nature can be abused for denial‑of‑service attacks. An attacker can flood the /login endpoint with incorrect passwords, forcing the server to execute bcrypt.compare() for each request, potentially saturating CPU resources.

Production systems mitigate this risk with login rate limiting, IP blocking, captchas, risk‑based controls, device fingerprinting, and isolating authentication services.

Key Takeaways for Secure Backend Design

Effective security architecture requires understanding why certain designs are chosen:

Never store passwords with fast hashes like MD5.

Use Bcrypt (or similar) with an appropriate cost factor to balance user experience and attack cost.

Leverage JWT for stateless authentication, but protect integrity with signatures and avoid placing sensitive data in the payload.

Implement token revocation via a server‑side blacklist (e.g., Redis) to reconcile statelessness with control.

Guard against Bcrypt‑induced DoS through comprehensive rate‑limiting and auxiliary defenses.

Mastering these mechanisms distinguishes a competent backend engineer from one who merely knows how to call APIs.