100% Free Forever — No signup, no paywalls, no limits.
DevKit
Security 5 min read June 17, 2026

Bcrypt Cost Factor: Choosing the Right Value for Your App in 2026

Cost factor 10 vs 12 vs 14 — how bcrypt's work factor affects security and performance, and what OWASP recommends in 2026.

DK

DevKit Team

Engineering

Share:

Bcrypt's cost factor determines how many iterations the hashing algorithm runs — higher means more secure but slower. The cost factor is exponential: each increment doubles the computation time. In 2026, OWASP recommends cost factor 12 as the default for new systems.

Choosing the Right Cost Factor

Cost 10: ~100ms per hash — fast but increasingly considered too low. Cost 12: ~400ms per hash — the OWASP recommended default for 2026. Cost 14: ~1.6s per hash — high security but may cause noticeable delays on login. The right value depends on your hardware and user experience tolerance. Measure the hash time on your production hardware and aim for 250-500ms. Increase the cost factor every 2-3 years as hardware gets faster. Never use cost factors below 10 in production.

Why This Matters in 2026

Security vulnerabilities in authentication and cryptographic systems can lead to devastating data breaches. In 2026, the threat landscape has evolved — AI-assisted attacks, quantum computing concerns, and increasingly sophisticated supply chain attacks mean that developers can no longer treat security as an afterthought. Understanding the tools and practices that protect user data is essential for every developer, not just security specialists.

Key Takeaways

  • Always use cryptographically strong algorithms — EdDSA for JWTs, Argon2id for passwords
  • Set short expiration times on tokens — 15 minutes for access tokens is the 2026 standard
  • Never store sensitive data in JWT payloads — they are encoded, not encrypted
  • Store tokens in httpOnly Secure cookies, never in localStorage
  • Validate all JWT claims — exp, iss, aud, nbf — not just the signature
  • Use secret management services, never hardcode secrets in source code

Common Mistakes to Avoid

  • Using alg:none in JWT verification — allows complete authentication bypass
  • Storing JWTs in localStorage where XSS attacks can steal them
  • Using MD5 or SHA-256 directly for password hashing — they are too fast
  • Not setting expiration times on tokens, leaving them valid forever
  • Using weak signing keys — less than 256 bits for HS256 is unacceptable
  • Not validating the audience (aud) claim, allowing cross-service token reuse

Warning

Never store passwords, credit card numbers, or other sensitive data in a JWT payload. The payload is Base64-encoded, not encrypted — anyone with the token can decode and read it. The signature only proves integrity, not confidentiality.

Best Practices

  • Use EdDSA (Ed25519) as the default algorithm for new JWT systems
  • Use Argon2id with OWASP-recommended parameters for password hashing
  • Keep access tokens short-lived (15 min) with refresh token rotation
  • Store refresh tokens as opaque random bytes, hashed in the database
  • Pin the algorithm in your verifier — never let the token choose
  • Audit your authentication system quarterly for new vulnerabilities

Tip

Implement refresh token rotation with reuse detection. If a used refresh token is presented again, revoke the entire session — this catches token theft in real time.

Quick Reference

Here is a secure JWT verification pattern that pins the algorithm and validates all critical claims:

javascript
import jwt from "jsonwebtoken";

function verifyToken(token, publicKey) {
  try {
    const payload = jwt.verify(token, publicKey, {
      algorithms: ["EdDSA"], // Never let the token choose
n      issuer: "your-app",
      audience: "your-api",
    });
    return { valid: true, payload };
  } catch (e) {
    return { valid: false, error: e.message };
  }
}

Real-World Example

A real-world authentication flow using short-lived access tokens with refresh token rotation. This pattern limits the damage from compromised tokens while maintaining a smooth user experience:

javascript
// Login: issue access + refresh token
async function login(userId) {
  const accessToken = jwt.sign({ sub: userId }, privateKey, {
    algorithm: "EdDSA",
    expiresIn: "15m",
    issuer: "your-app",
  });
  const refreshToken = crypto.randomBytes(32).toString("hex");
  await storeRefreshToken(userId, hash(refreshToken));
  return { accessToken, refreshToken };
}

Tools and Resources

  • DevKit JWT Decoder — inspect JWT header, payload, and claims client-side
  • DevKit Hash Generator — generate SHA-256, SHA-512 hashes in the browser
  • DevKit Bcrypt Generator — test bcrypt hashing with different cost factors
  • OWASP Cheat Sheet Series — authoritative security best practices
  • Have I Been Pwned — check if credentials have been in data breaches

"Security is not a product, but a process. It is not something you buy, it is something you practice."

Security requires constant vigilance. Use strong algorithms, keep tokens short-lived, validate every claim, and never trust unverified input. The tools are available — the discipline to use them consistently is what separates secure systems from vulnerable ones.

Advertisement
32 tools ready to use

Ready to boost your workflow?

No accounts. No uploads. No limits. Just open a tool and start working.

Browse All Tools
Free forever
No signup
100% private