How Bcrypt Password Hashing Works: Complete Analysis

1. Introduction and Core Concepts

bcrypt password hashing is an adaptive, slow, and salted password hashing function designed specifically to protect stored credentials against offline brute-force and rainbow table attacks. Created by Niels Provos and David Mazières in 1999 and based on the Blowfish block cipher, bcrypt was introduced at a time when fast cryptographic hashes like MD5 and SHA-1 were commonly misused for password storage. Unlike general-purpose hash functions optimized for speed, bcrypt is intentionally computationally expensive and future-proof, making it a cornerstone of secure authentication in modern web applications.

At its core, bcrypt password hashing solves three critical problems that plague naive password storage. First, it automatically generates and embeds a unique 128-bit salt for every password, ensuring that identical passwords produce entirely different hashes and rendering precomputed rainbow tables useless. Second, it incorporates an adjustable work factor or cost parameter that determines how many iterations of its internal key derivation are performed, allowing the hashing time to scale as hardware becomes faster. Third, it is designed to be slow and memory-access intensive in a way that frustrates parallelization on GPUs and ASICs, significantly raising the cost of large-scale guessing attacks.

Understanding why bcrypt matters requires contrasting it with how passwords are often mishandled. Storing passwords in plaintext, encrypting them reversibly, or hashing them with a single fast SHA-256 iteration leaves users vulnerable if a database is breached. Attackers can test billions of guesses per second against fast hashes. bcrypt password hashing changes this equation by forcing each guess to take hundreds of milliseconds, reducing an attacker from billions to only a few guesses per second per core. This adaptive slowness is the reason bcrypt remains recommended by security authorities like OWASP and NIST for password storage, even more than two decades after its invention.

Key Properties of bcrypt

bcrypt is not just a hash function but a complete password hashing construction. Its output is a single 60-character string in modular crypt format that encodes the algorithm identifier, cost factor, 22-character salt, and 31-character hash. This self-contained format simplifies storage and verification because all parameters needed to re-hash and verify a candidate password are present in the stored string itself. There is no need for separate salt columns or version management logic in many implementations.

Another defining concept is the adaptive cost. The cost parameter is a logarithmic value, typically between 4 and 31, where the actual iteration count equals 2 raised to the power of cost. A cost of 12 means 4,096 iterations of the expensive Eksblowfish key setup. As servers become more powerful, administrators can increment the cost by one to double the hashing time, ensuring that password hashing keeps pace with Moore's Law without requiring a change of algorithm or database schema migration.

2. How It Works

bcrypt is built upon the Eksblowfish (Expensive Key Schedule Blowfish) algorithm, a deliberately expensive variant of the Blowfish cipher. Standard Blowfish has a fast key setup, but Eksblowfish interleaves the key expansion with the hashing of the password and salt, making the setup intentionally slow. The core idea is to use the password and salt to repeatedly encrypt a known plaintext, and the resulting ciphertext becomes the hash. This process is computationally intensive and cannot be easily shortcut.

The algorithm proceeds in several distinct phases. First, a 128-bit salt is generated using a cryptographically secure pseudorandom number generator. This salt is then combined with the password and the cost parameter to initialize the Eksblowfish state. The state consists of 18 32-bit P-array entries and four S-boxes each containing 256 32-bit entries, totaling over 4 kilobytes of constantly mutated state. The initialization phase repeatedly encrypts and mixes the state using alternating operations with the password and salt for 2^cost iterations, which dominates the total execution time.

After the expensive key setup is complete, bcrypt encrypts the 24-byte plaintext string "OrpheanBeholderScryDoubt" 64 times using Blowfish in ECB mode with the state derived in the previous phase. The final 192-bit ciphertext is then Radix-64 encoded using a bcrypt-specific Base64 alphabet (./A-Za-z0-9) to produce the 31-character hash portion. The final modular crypt format string looks like $2b$12$EixZaYVK1fsbw1ZfbX3OXePaWxn96p36WQoeG6Lruj3vjPGKT5O, where 2b denotes the algorithm version, 12 is the cost, and the remainder is the salt and hash.

The Role of Salt and Cost

The salt in bcrypt password hashing is not secret; it is stored in plaintext as part of the hash string. Its purpose is uniqueness, not confidentiality. A 128-bit salt provides 2^128 possible values, making it statistically impossible for two users to share the same salt even with billions of accounts. This uniqueness ensures that an attacker must attack each hash individually, even if two users chose the same password. Without salts, an attacker could hash a dictionary once and compare it against every entry simultaneously.

The cost parameter is the primary tuning knob for security versus performance. On a modern server, a cost of 10 takes roughly 60-80 milliseconds, cost 12 takes about 250-350 milliseconds, and cost 14 can exceed one second. The ideal cost is the highest value that still provides acceptable user experience during login and registration, typically targeting 200-500 ms per hash. Because cost is logarithmic, small increments have large effects, allowing fine-grained adjustment for different deployment environments, from low-power IoT devices to high-performance authentication servers.

Why Blowfish and Eksblowfish?

Blowfish was chosen because its key schedule is inherently complex and requires significant memory access to large S-boxes, which makes it less amenable to GPU optimization. Unlike SHA-256 which is heavily pipelined and can be massively parallelized on graphics cards, Blowfish's sequential memory lookups create bottlenecks for parallel hardware. Eksblowfish amplifies this by making the key schedule dependent on both salt and password in an alternating, non-parallelizable loop, ensuring that each hash computation must be performed serially and cannot be batched efficiently.

3. Implementation

Implementing bcrypt password hashing correctly in Python requires using a well-vetted library rather than attempting to implement Eksblowfish from scratch. The most common library is bcrypt, a Python wrapper around the OpenBSD implementation, which handles salt generation, cost management, and constant-time verification. Alternative libraries like passlib and Flask-Bcrypt provide higher-level abstractions but ultimately delegate to the same underlying C implementation for security and performance.

The following examples demonstrate production-ready patterns for hashing, verifying, benchmarking, and hardening bcrypt usage. All code assumes Python 3.8+ and installation via pip install bcrypt. Remember that passwords should be handled as bytes and that bcrypt truncates inputs longer than 72 bytes, a limitation that must be addressed for very long passphrases.

import bcrypt

# --- Basic Hashing and Verification ---
# Always work with bytes; encode user input as UTF-8
password = b"correct_horse_battery_staple_v2!"
# gensalt generates a 128-bit salt and encodes cost (default 12)
salt = bcrypt.gensalt(rounds=12)
hashed = bcrypt.hashpw(password, salt)

print(hashed.decode())
# Output example: $2b$12$K1AVi5EV5Z9B1p4F.6u6euH8p2a2...

# Verification extracts salt and cost automatically from stored hash
candidate = b"correct_horse_battery_staple_v2!"
is_valid = bcrypt.checkpw(candidate, hashed)
print(f"Password valid: {is_valid}")  # True

# Wrong password fails verification
is_valid_wrong = bcrypt.checkpw(b"wrong_password", hashed)
print(f"Wrong password valid: {is_valid_wrong}")  # False

import bcrypt
import time

def benchmark_cost(password: bytes, max_cost=14):
    """Benchmark different cost factors to select optimal latency."""
    print("Cost | Time (s) | Hash Preview")
    print("-" * 50)
    for cost in range(4, max_cost + 1):
        salt = bcrypt.gensalt(rounds=cost)
        start = time.perf_counter()
        hashed = bcrypt.hashpw(password, salt)
        elapsed = time.perf_counter() - start
        # Use escaped comparison for HTML safety
        status = "TOO SLOW" if elapsed > 0.5 else "OK"
        # Truncate hash for display
        preview = hashed.decode()[:29] + "..."
        print(f"{cost:4} | {elapsed:7.4f} | {preview} [{status}]")
        # Stop if latency exceeds 1 second
        if elapsed > 1.0:
            print("Stopping: latency exceeds 1s target")
            break

benchmark_cost(b"benchmark_password_123")

import bcrypt
import hashlib
import os
import hmac

# Pepper is a secret application-wide key stored outside the DB (env var, HSM)
PEPPER = os.environ.get("PEPPER_SECRET", "change_me_in_production").encode()

def hash_with_pepper(password: str) -> bytes:
    """Pre-hash with pepper and SHA-256 to handle long passwords and add defense in depth."""
    # Bcrypt truncates at 72 bytes; pre-hashing avoids silent truncation
    # Use HMAC-SHA256 with pepper so pepper remains secret
    peppered = hmac.new(PEPPER, password.encode('utf-8'), hashlib.sha256).digest()
    # Hash the 32-byte digest with bcrypt (well under 72-byte limit)
    # Note: peppered is bytes, so we hash its hex representation
    # Alternative: directly hash peppered bytes after base64 encoding
    hashed = bcrypt.hashpw(peppered, bcrypt.gensalt(rounds=12))
    return hashed

def verify_with_pepper(password: str, stored_hash: bytes) -> bool:
    """Verify peppered password using constant-time comparison."""
    peppered = hmac.new(PEPPER, password.encode('utf-8'), hashlib.sha256).digest()
    # bcrypt.checkpw is constant-time and handles salt extraction
    return bcrypt.checkpw(peppered, stored_hash)

# Example usage
pwd = "a_very_long_passphrase_that_exceeds_seventy_two_bytes_and_would_be_truncated_without_pre_hashing_extra"
stored = hash_with_pepper(pwd)
print(f"Stored: {stored.decode()}")
print(f"Verify correct: {verify_with_pepper(pwd, stored)}")
print(f"Verify wrong: {verify_with_pepper('wrong', stored)}")

import bcrypt

# --- Password Upgrade and Rehashing Strategy ---
# Simulate user database with stored hashes
fake_db = {}

def register_user(username: str, password: str, cost=12):
    """Register new user with current cost."""
    hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=cost))
    fake_db[username] = hashed.decode()
    print(f"Registered {username} with cost {cost}")

def verify_and_upgrade(username: str, password: str, desired_cost=12) -> bool:
    """Verify login and upgrade hash if cost is outdated."""
    stored_hash = fake_db.get(username)
    if stored_hash is None:
        return False
    stored_bytes = stored_hash.encode()
    # Check password (handles old cost automatically)
    if not bcrypt.checkpw(password.encode(), stored_bytes):
        return False
    # Check if rehashing is needed (cost changed or version updated)
    # bcrypt.checkpw does not tell us cost; we parse it
    current_cost = int(stored_hash.split("$")[2])
    if current_cost < desired_cost:
        print(f"Upgrading {username} from cost {current_cost} to {desired_cost}")
        new_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=desired_cost))
        fake_db[username] = new_hash.decode()
    else:
        print(f"{username} hash is up-to-date (cost {current_cost})")
    return True

register_user("alice", "s3cureP@ss", cost=10)
verify_and_upgrade("alice", "s3cureP@ss", desired_cost=12)
print(f"New hash: {fake_db['alice']}")
verify_and_upgrade("alice", "s3cureP@ss", desired_cost=12)

4. Step-by-Step Example

To make bcrypt password hashing concrete, let us walk through hashing the password "Tr0ub4dor&3" with cost 10 and a fixed salt for reproducibility. In production the salt is always random, but for illustration we use the salt "EixZaYVK1fsbw1ZfbX3OXe" (22 characters, Base64 encoded 16 bytes). The modular crypt format combines all parameters into one string before hashing begins.

Step 1 is salt generation and encoding. The raw 128-bit salt is 16 bytes, for example 0x48a9f3c2e1b5d07f8a6c4e9b2d1f0a3c. This is encoded with bcrypt's custom Base64 alphabet to produce a 22-character string. The cost 10 is formatted as two digits "10" and the version prefix "$2b$" is prepended. The full salt string becomes "$2b$10$EixZaYVK1fsbw1ZfbX3OXe", which is 29 characters long and will be stored as the prefix of the final hash.

Step 2 is the expensive key setup. The Eksblowfish state is initialized with the fractional part of pi (as in Blowfish), then the 18 P-array entries and four S-boxes are repeatedly XORed and encrypted with alternating blocks of the password and salt. For cost 10, this loop runs 2^10 = 1024 times. Each iteration performs multiple Blowfish encryptions, each requiring 16 rounds of Feistel network operations with S-box lookups. This phase dominates runtime and is where the work factor is enforced. After 1024 iterations, the state is thoroughly mixed and dependent on every bit of password and salt.

Step 3 is the final encryption. The 24-byte ASCII string "OrpheanBeholderScryDoubt" is encrypted 64 times in ECB mode using the state derived in Step 2. The first encryption takes the plaintext and encrypts it with the current P and S boxes, the output is then encrypted again, and so on for 64 rounds. The resulting 192-bit (24-byte) ciphertext is then encoded with the same Radix-64 alphabet to produce 31 characters, for example "PaWxn96p36WQoeG6Lruj3vjPGKT5O". The final stored hash is the concatenation: salt string + hash encoding = "$2b$10$EixZaYVK1fsbw1ZfbX3OXePaWxn96p36WQoeG6Lruj3vjPGKT5O" (60 characters total).

Verification reverses the process without needing to store the salt separately. When a user logs in with candidate password "Tr0ub4dor&3", the system extracts "$2b$10$EixZaYVK1fsbw1ZfbX3OXe" from the stored hash, repeats Steps 2 and 3 with the candidate password and extracted salt/cost, and compares the resulting 31-character hash to the stored suffix using a constant-time comparison. If they match, authentication succeeds. If the candidate were "tr0ub4dor&3" (lowercase t), the Eksblowfish setup would produce a completely different state and final hash, causing verification to fail.

5. Complexity Analysis

The time complexity of bcrypt password hashing is intentionally exponential in the cost parameter, which is its most important security property. Hashing requires O(2^cost) Blowfish key setup iterations, each performing a constant amount of work involving S-box lookups and Feistel rounds. Therefore, doubling the cost doubles the time. For a fixed cost, the time is linear in the password length up to 72 bytes (since Blowfish processes key material in blocks), but effectively constant for typical passwords because the expensive loop dominates. Verification has identical complexity to hashing because it must perform the same Eksblowfish setup to recompute the hash for comparison.

Space complexity is O(1) with respect to password length and cost, requiring a fixed 4,168 bytes for the Blowfish state (18 P-array entries + 4 * 256 S-box entries, each 4 bytes). This constant memory footprint is relatively small by modern standards, which is both a strength and a weakness: it makes bcrypt efficient on servers but also means it is not strongly memory-hard, allowing attackers with custom hardware to parallelize guesses more easily than with memory-hard functions like Argon2 or scrypt that require megabytes per hash.

Best, average, and worst cases for bcrypt are essentially identical because the algorithm always performs the full 2^cost iterations regardless of password content. There is no early exit or data-dependent branching that would cause timing variations, which is crucial for preventing timing side-channel attacks. The only minor variation comes from password length: passwords shorter than 72 bytes require slightly less XOR work during key expansion, but this difference is negligible compared to the 2^cost loop. Salt generation is O(1) and depends only on the CSPRNG.

From a system perspective, the relevant complexity is throughput and latency under load. If a server can handle 100 bcrypt hashes per second per core at cost 12, an attacker with a single GPU that can compute 10,000 SHA-256 hashes per second would be reduced to only a few hundred bcrypt guesses per second even with optimizations. This 1000x slowdown is the practical security gain. Administrators must balance this against denial-of-service risk: an attacker could flood a login endpoint with requests to force the server to compute expensive hashes, so rate limiting and CAPTCHAs are essential complements to bcrypt.

6. Variations and Optimizations

Several version identifiers exist for bcrypt, reflecting bug fixes and improvements over time. The original "$2a$" version had a bug in handling non-ASCII passwords with the 8th bit set. "$2x$" and "$2y$" were introduced to fix this and to distinguish buggy versus corrected implementations, particularly in PHP. Modern implementations should use "$2b$", which is the current OpenBSD version that correctly handles all password bytes and is the default in most libraries. Some libraries also support "$2b$" with explicit handling of long passwords, but the version string itself does not affect the core algorithm.

A common optimization is pre-hashing long passwords to overcome bcrypt's 72-byte truncation limit. Since bcrypt only uses the first 72 bytes of input, passwords longer than that are silently truncated, meaning "password_72_bytes_plus_extra_A" and "password_72_bytes_plus_extra_B" would hash to the same value if they share the same 72-byte prefix. To avoid this, best practice is to pre-hash the password with SHA-256 or HMAC-SHA256 before bcrypt, as shown in the pepper example. This ensures the full entropy of long passphrases is preserved while staying within bcrypt's input limit.

Peppering is another variant where a secret key (pepper) is added to the password before hashing, typically via HMAC. Unlike salt, which is unique per user and stored with the hash, pepper is application-wide and stored separately, such as in an environment variable, vault, or hardware security module. Peppering provides defense in depth: if the database is breached but the pepper remains secret, offline cracking becomes infeasible even for weak passwords. However, pepper rotation is more complex than salt rotation and requires careful key management.

Performance optimizations focus on selecting the right cost and offloading computation. Adaptive cost tuning via benchmarking at server startup ensures optimal latency as hardware evolves. Some deployments offload bcrypt computation to dedicated authentication microservices or use asynchronous hashing to avoid blocking web workers. While bcrypt itself cannot be parallelized internally, servers can parallelize across requests using thread pools. It is critical not to optimize by reducing rounds or caching hashes in a way that weakens security; the slowness is the feature.

Related Adaptive Functions

While not strictly bcrypt variants, functions like bcrypt-SHA256 and tunable bcrypt implementations that support costs up to 31 are common. Some systems implement "bcrypt with SHA-512 pre-hash" to support passwords of arbitrary length and to add an extra layer of mixing. These should be clearly documented and versioned, as they change the verification logic. When migrating from bcrypt to newer memory-hard functions, a common pattern is to wrap the existing bcrypt hash with Argon2, allowing gradual upgrades without forcing password resets.

7. Real-World Applications

bcrypt password hashing is the default choice for password storage in a vast array of web frameworks, databases, and authentication systems. In web servers, frameworks like Django (Python), Ruby on Rails, Spring Security (Java), and Laravel (PHP) either default to bcrypt or recommend it as the primary password hasher. For example, Django's PBKDF2 hasher can be swapped for bcrypt via configuration, and Devise for Rails uses bcrypt by default. This ubiquity means that millions of user accounts are protected by bcrypt without developers needing to understand its internals.

In database and backend systems, bcrypt hashes are stored as VARCHAR(60) or TEXT columns alongside user records. Because the hash string is self-contained, no additional columns for salt or cost are needed, simplifying schema design and migration. Authentication microservices often expose a simple API: hash(password) returns a string, verify(password, hash) returns boolean. This encapsulation allows centralized cost management and pepper handling. Cloud providers like AWS, GCP, and Azure offer managed authentication services (Cognito, Firebase Auth, Azure AD B2C) that internally use bcrypt or similar adaptive functions, though the exact algorithm may be abstracted.

Network and infrastructure applications also rely on bcrypt. OpenBSD, where bcrypt originated, uses it for local system password storage in /etc/master.passwd. Linux distributions with libxcrypt support bcrypt via the crypt() function. VPN concentrators, SSH bastion hosts, and network appliances that manage local admin accounts often use bcrypt to protect device credentials, ensuring that stolen configuration backups do not yield plaintext passwords. Even embedded systems with limited resources can use lower costs (e.g., cost 8-10) to balance security and performance.

Beyond traditional web logins, bcrypt is used in API key derivation, password managers, and encrypted file systems where a user-supplied passphrase must be stretched into a key. While bcrypt is not a key derivation function for encryption keys (HKDF or Argon2 are better suited), it is often used to hash the master password that protects a vault. In this context, the work factor directly determines how long it takes to unlock the vault, providing a tunable delay that protects against brute-force if the vault file is stolen.

8. Comparison with Alternatives

Choosing a password hashing algorithm involves trade-offs between security, performance, memory hardness, and ecosystem support. bcrypt password hashing excels at being simple, battle-tested, and widely supported, but newer algorithms like Argon2 and scrypt offer stronger resistance to GPU and ASIC attacks through memory hardness. Understanding these differences helps architects select the right tool for their threat model and deployment constraints.

PBKDF2 (Password-Based Key Derivation Function 2) is an older NIST-approved standard that applies HMAC-SHA256 iteratively. It is highly configurable and FIPS-compliant, making it popular in enterprise and government systems, but it is not memory-hard and can be efficiently parallelized on GPUs, requiring very high iteration counts (e.g., 600,000+) to achieve comparable security to bcrypt cost 12. scrypt, designed by Colin Percival, is both CPU and memory-hard, requiring large amounts of RAM per hash, which makes custom hardware attacks expensive. Argon2, the winner of the 2015 Password Hashing Competition, comes in three variants (Argon2d, Argon2i, Argon2id) and is now considered state-of-the-art, offering tunable memory, time, and parallelism parameters.

Fast hashes like SHA-256 and MD5 should never be used directly for passwords, even with salts, because they are designed for speed and can be computed at billions of hashes per second on modern hardware. The table below compares these approaches across key dimensions relevant to password storage. For new systems where memory-hardness is a priority and library support is available, Argon2id is often recommended, while bcrypt remains an excellent and pragmatic choice where simplicity and broad compatibility are paramount.

9. Common Mistakes and Best Practices

Even with a strong primitive like bcrypt password hashing, implementation errors can nullify its security benefits. One of the most common mistakes is using too low a cost factor, such as the default cost 4 or 8 in some libraries, which provides minimal protection. Developers often leave the default unchanged for performance reasons without benchmarking on production hardware. Best practice is to benchmark at deployment and in CI, selecting the highest cost that keeps login latency under 500 ms and re-evaluating annually as hardware improves.

Another frequent pitfall is mishandling the 72-byte truncation. Users with long passphrases may believe their full 100-character sentence is being hashed, but bcrypt silently discards bytes beyond 72, reducing entropy and potentially causing collisions. The fix is to pre-hash with SHA-256 or HMAC-SHA256 as demonstrated earlier, ensuring the full password contributes to the hash. Similarly, failing to handle Unicode correctly—such as normalizing NFC versus NFD forms or inconsistent UTF-8 encoding between registration and login—can cause legitimate passwords to fail verification for international users.

Security anti-patterns include implementing your own salt generation with a weak RNG, reusing salts across users, or storing salts separately. Always use the library's gensalt which uses a CSPRNG. Never truncate or modify the bcrypt output string; store the full 60-character hash. Avoid double-hashing like bcrypt(bcrypt(password)) or bcrypt(md5(password)) without understanding the implications, as this can reduce entropy or introduce vulnerabilities. When adding pepper, do not store it in the same database as the hashes; use environment variables, secret managers, or HSMs, and have a rotation plan.

Operational best practices extend beyond code. Enforce rate limiting and account lockout on login endpoints to prevent online guessing and to mitigate DoS via expensive hash computations. Use constant-time comparison for verification (bcrypt.checkpw already does this) to avoid timing leaks. Plan for hash upgrades: store the algorithm version and cost alongside the hash (already in the string) and implement a rehash-on-login flow that transparently upgrades hashes when cost increases. Finally, never log plaintext passwords or hashes, enforce TLS for transport, and combine bcrypt with multi-factor authentication for high-value accounts.

• Benchmark cost on production hardware; target 250-500 ms and increase cost over time.
• Pre-hash passwords longer than 72 bytes with HMAC-SHA256 to avoid truncation.
• Use library-provided CSPRNG for salts; never reuse salts or use predictable values.
• Store the full 60-character hash; do not split salt and hash into separate columns unless needed.
• Keep pepper secret and separate from the database; rotate with versioning.
• Implement rate limiting, CAPTCHA, and monitoring to prevent hash-DoS and credential stuffing.
• Normalize Unicode (NFKC) and consistently encode as UTF-8 before hashing.
• Plan for migration: support multiple hash versions and rehash on successful login.

10. Interview Questions

Q1: Why is bcrypt considered more secure than SHA-256 for password hashing, even though SHA-256 is a cryptographic hash function?

SHA-256 is designed to be fast and efficient, which is ideal for verifying data integrity but terrible for password storage because attackers can compute billions of guesses per second on GPUs. bcrypt is intentionally slow and adaptive, requiring 2^cost iterations of Eksblowfish setup, reducing attacker throughput to a few hundred guesses per second. Additionally, bcrypt automatically handles unique salting and is more resistant to parallelization due to its memory-access pattern, whereas SHA-256 requires manual salting and iteration (as in PBKDF2) and remains highly parallelizable. The key insight is that password hashing should be slow for attackers, not fast.

Q2: Explain the bcrypt cost parameter. What happens if you increase it from 12 to 13?

The cost parameter is a logarithmic work factor where the number of iterations equals 2^cost. Increasing cost from 12 to 13 doubles the computation time and the number of Eksblowfish key setup iterations from 4,096 to 8,192. This means hashing and verification will take roughly twice as long, doubling the cost for attackers attempting brute-force. In practice, you would increase cost when servers become faster to maintain a target latency (e.g., 300 ms). The modular crypt format stores the cost with the hash, so existing hashes with cost 12 remain valid, but new passwords or rehashed logins will use cost 13.

Q3: What is the 72-byte limit in bcrypt and how would you handle a 100-character passphrase?

bcrypt is based on Blowfish which has a 72-byte (576-bit) key limit; any bytes beyond 72 are ignored, so two passwords sharing the same 72-byte prefix would produce the same hash. For a 100-character passphrase, especially with multi-byte UTF-8 characters, this truncation silently reduces security. The recommended solution is to pre-hash the password with a cryptographic hash like SHA-256 or HMAC-SHA256 before bcrypt, for example HMAC-SHA256(pepper, password) then bcrypt the 32-byte digest. This compresses arbitrary-length input into a fixed size under the limit while preserving entropy and allowing pepper integration.

Q4: How does bcrypt's salt prevent rainbow table attacks, and where is the salt stored?

A salt is a unique random 128-bit value generated per password that ensures identical passwords hash to different values. Without salts, an attacker can precompute a rainbow table of hashes for common passwords once and compare it against every entry in a breached database simultaneously. With unique salts, the attacker must compute a separate table for each salt, which is infeasible given 2^128 possibilities. In bcrypt, the salt is not stored separately; it is encoded as 22 characters within the 60-character hash string itself (after the cost), so verification can extract it automatically. The salt is not secret, but its uniqueness is critical.

Q5: Compare bcrypt and Argon2. When would you choose one over the other?