Back to Blog
Security4 अप्रैल 20266 min

How to Generate Bcrypt Password Hashes Securely

Bcrypt is the gold standard for password hashing — not because it's the newest algorithm, but because it was designed from the ground up to be slow. That deliberate slowness is exactly what makes it resistant to brute-force attacks. If an attacker dumps your database, they need to crack each hash individually, and bcrypt makes that process expensive.

This tutorial walks you through generating bcrypt hashes using the Bcrypt Hash Generator on TinyToolbox — no server, no installation, everything runs locally in your browser.

What Is Bcrypt and Why Does It Matter?

Most developers know they shouldn't store plaintext passwords. But not all hashing algorithms are created equal. MD5 and SHA-256 are fast — great for file integrity checks, terrible for passwords. A modern GPU can compute billions of SHA-256 hashes per second, meaning a leaked hash database can be cracked in hours.

Bcrypt solves this with a configurable cost factor. The algorithm performs 2^n internal iterations, where n is the number of rounds you specify. At 10 rounds, your server does about 1,000 operations per hash. Bump it to 14, and you're at 16,000. Each increment roughly doubles the time required — for both legitimate logins and attackers.

For tasks where speed is acceptable — checksums, content fingerprinting, API response signing — the Hash Generator handles MD5, SHA-1, SHA-256, and SHA-512 efficiently. Bcrypt is specifically for passwords.

Step-by-Step: Generating a Bcrypt Hash

Here's the complete workflow using TinyToolbox's Bcrypt Hash Generator.

Step 1: Open the tool

Navigate to Bcrypt Hash Generator. No account required, nothing to install. The tool runs entirely in your browser.

Step 2: Enter your password

Type or paste the password you want to hash into the input field. For testing, use a known string. For production work, start with a strong candidate — the Password Generator can create one with high entropy and configurable complexity.

Step 3: Set the cost factor (rounds)

The default is typically 10. This is a reasonable starting point for most web applications. See the next section for guidance on tuning this value for your specific environment.

Step 4: Generate the hash

Click Generate. The output will look something like this:

$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LnImaS70VpC

This string encodes everything: the algorithm version (2b), the cost factor (10), the 22-character salt, and the 31-character hash — all in one portable string.

Step 5: Copy and store it

Copy the full hash string. Store it as-is in your database's password column. Never truncate it — the complete string is required for verification. Use VARCHAR(72) or TEXT to be safe.

Step 6: Verify on login

When a user logs in, pass their entered password and the stored hash to your bcrypt verify function. The library extracts the salt from the hash automatically and re-runs the algorithm to compare.

In Node.js:

const match = await bcrypt.compare(plaintext, storedHash);

In Python:

result = bcrypt.checkpw(password.encode(), stored_hash)

In PHP:

$valid = password_verify($password, $hash);

Choosing the Right Cost Factor

The right number of rounds depends on your hardware and your tolerance for login latency. OWASP guidelines recommend targeting a hash time of roughly 1 second on your production server. Run a quick benchmark — time how long 10 rounds takes. If it completes in 50ms, you can safely increase to 12 or 13. If it's already pushing 500ms, 10 is probably your ceiling.

A rough reference by use case:

  • Rounds 10–11: Fast hardware, high-traffic APIs. Login takes 100–200ms.
  • Rounds 12–13: Mid-range servers, moderate traffic. Login takes 250–500ms.
  • Rounds 14+: Sensitive applications, infrequent auth (admin panels, financial tools). 1+ seconds per hash is acceptable.
  • One important limitation: bcrypt truncates input at 72 bytes. If users might use very long passphrases, consider pre-hashing with SHA-256 before passing to bcrypt. Before finalizing your password policy, run candidate passwords through Password Strength Check to understand their baseline entropy and complexity scores.

    Common Mistakes to Avoid

    Storing only part of the hash. Some legacy VARCHAR(60) columns were sized for older bcrypt variants. The modern $2b$ format requires at least 72 characters. Audit your schema before deploying.

    Using bcrypt for non-password data. Bcrypt is intentionally slow — never use it to hash API keys, session tokens, or file checksums. Use SHA-256 for those via the Hash Generator.

    Never rehashing as hardware improves. As servers get faster, 10 rounds becomes weaker. Plan to rehash on next login when you increase the cost factor. The stored hash encodes its own round count, so old and new hashes coexist transparently during migration.

    Rolling your own salt logic. Every production bcrypt library generates a cryptographically secure random salt automatically. Never pass a hardcoded salt. The tool and every reputable library handle this correctly by default — don't override it.

    FAQ

    Can I use the same bcrypt hash to verify a password multiple times?

    Yes. The hash string contains both the salt and cost factor embedded in it. Every time you call the verify function with the original plaintext and the stored hash, it will return true as long as the password matches. You don't need to store the salt separately — it's already there.

    What's the difference between bcrypt and Argon2?

    Argon2 won the Password Hashing Competition in 2015 and is memory-hard, making GPU-based attacks significantly more expensive. Bcrypt is still considered secure and has far broader library support across languages and frameworks. For new projects, Argon2 is worth evaluating. For existing bcrypt deployments, there's no urgent need to migrate — bcrypt with a sensible cost factor remains solid.

    Why does the same password produce a different hash every time?

    Bcrypt generates a new random salt on every call. Two hashes of the same password look completely different but both verify correctly against that password. This is by design — it prevents rainbow table attacks and ensures that two users with the same password have completely distinct hash values in your database.

    Conclusion

    Bcrypt remains one of the most battle-tested tools in any developer's security toolkit. The key is using it correctly: pick a cost factor appropriate for your hardware, store the full hash string without truncation, and let the library handle salting. The Bcrypt Hash Generator on TinyToolbox gives you a fast, no-friction way to generate hashes for testing, prototyping, and verifying your implementation — all without sending your data anywhere. Pair it with Password Generator to build strong test credentials from the start, check your inputs with Password Strength Check, and you have a complete foundation for password security on any project.

    अपडेटेड रहें

    नई टूल्स सबसे पहले पाएं।

    सबसे पहले नए टूल्स पाएं। 5,000+ डेवलपर्स के साथ जुड़ें जो हर हफ्ते नए ऑनलाइन टूल्स, कोडिंग टिप्स और प्रोडक्टिविटी हैक्स का डाइजेस्ट पाते हैं। बिना स्पैम के।

    © 2026 TinyToolbox. सर्वाधिकार सुरक्षित।

    गोपनीयता पहले। विज्ञापन-समर्थित। हमेशा मुफ्त।

    [H4CK]