Password Hashing with Argon2 and bcrypt

Password Hashing: Making Cracking Prohibitively Expensive

Storing passwords securely is one of the most fundamental requirements of any authentication system. The goal is not to make passwords unbreakable — given enough time and resources, any hash can be cracked. The goal is to make cracking so expensive in time and hardware that it is impractical for an attacker.

Why Fast Hashes Fail for Passwords

General-purpose hash functions like MD5, SHA-1, and SHA-256 are designed for speed. They verify data integrity and compute checksums quickly. This speed is a feature for their intended use but a catastrophic flaw for password storage.

The math of cracking speed:

• A modern GPU can compute billions of SHA-256 hashes per second
• An 8-character password has ~218 trillion (95^8) possible combinations
• At 10 billion hashes/second, cracking all 8-character passwords takes ~6 hours
• MD5 is even faster — trillions of hashes per second on modern hardware

Real-world example: In 2012, LinkedIn stored passwords using unsalted SHA-1. Attackers cracked 6.5 million passwords within days using GPU clusters. The fast hash made brute-force attacks trivially cheap.

What Makes a Good Password Hash

A password hashing algorithm must have these properties:

1. Slow: Each hash computation should take 100-500ms on production hardware. This makes brute-force attacks impractical while remaining acceptable for legitimate login attempts.

2. Memory-hard: The algorithm should require significant memory (64+ MB) to compute. This makes GPU and ASIC attacks impractical because these devices have limited memory per core.

3. Salted: Each password must be hashed with a unique random salt. This prevents rainbow table attacks and ensures that identical passwords produce different hashes.

4. Adaptive: The algorithm should allow increasing the work factor as hardware improves, without breaking existing hashes.

The Two Leading Algorithms

Argon2 (winner of the Password Hashing Competition, 2015):

• Argon2id is the recommended variant (resists both GPU and side-channel attacks)
• Memory-hard: requires configurable memory (default 64 MB)
• Time-hard: configurable number of iterations (default 3)
• Parallelism: configurable threads (default 4)
• Resistant to GPU cracking because GPUs have limited memory per core

bcrypt (based on the Blowfish cipher, 1999):

• Time-hard: configurable cost factor (default 12, meaning 2^12 = 4,096 iterations)
• Not memory-hard: uses only 4 KB of memory
• Still widely used and considered secure with appropriate cost factors
• Limited to 72-byte passwords (longer passwords are truncated)

Salts: Why They Matter

A salt is a random value added to each password before hashing. The salt is stored alongside the hash (it is not a secret).

Without salts:

hash("password") = 5f4dcc3b5aa765d61d8327deb882cf99  (MD5)

Every user with the password "password" has the same hash. An attacker can precompute a rainbow table of common password hashes and instantly look up any matching hash.

With salts:

hash("password" + "salt_A") = 7c6a180b36896a0a8c02787eeafb0e4c
hash("password" + "salt_B") = 6cb75f652a9b52798eb6cf2200e8896c

Identical passwords produce different hashes. Rainbow tables are useless because the attacker would need a separate table for every possible salt.

Salt requirements:

• Unique per password (never reuse salts)
• Cryptographically random (use os.urandom or secrets)
• Sufficiently long (16+ bytes)
• Stored alongside the hash (not a secret)

Practical Implementation of Password Hashing

Argon2id Implementation (Python)

from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

# Create hasher with recommended parameters
ph = PasswordHasher(
    time_cost=3,      # Number of iterations
    memory_cost=65536, # 64 MB in KiB
    parallelism=4,     # Number of threads
    hash_len=32,       # Length of the hash in bytes
    salt_len=16        # Length of the salt in bytes
)

# Hash a password (automatically generates a random salt)
password = "user_password_123"
hash_string = ph.hash(password)
# Example output: $argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

# Verify a password
try:
    ph.verify(hash_string, "user_password_123")
    print("Password correct")
except VerifyMismatchError:
    print("Password incorrect")

# Check if hash needs rehashing (parameters have changed)
if ph.check_needs_rehash(hash_string):
    new_hash = ph.hash(password)
    # Update stored hash in database

The encoded hash string contains all parameters and the salt, so verification does not require storing them separately.

bcrypt Implementation (Python)

import bcrypt

# Hash a password
password = b"user_password_123"  # bcrypt requires bytes
salt = bcrypt.gensalt(rounds=12)  # Cost factor 12 (2^12 = 4,096 iterations)
hash_bytes = bcrypt.hashpw(password, salt)
# Example output: b'$2b$12$LJ3m4ys5Lz5z5z5z5z5z5O...'

# Verify a password
if bcrypt.checkpw(b"user_password_123", hash_bytes):
    print("Password correct")
else:
    print("Password incorrect")

bcrypt Implementation (Node.js)

const bcrypt = require('bcrypt');
const SALT_ROUNDS = 12;

// Hash a password
const hash = await bcrypt.hash('user_password_123', SALT_ROUNDS);

// Verify a password
const match = await bcrypt.compare('user_password_123', hash);
if (match) {
    console.log('Password correct');
}

Choosing Parameters

Argon2id parameters:

• memory_cost: 64 MB (65536 KiB) is the recommended minimum for production
• time_cost: 3 iterations is the recommended minimum
• parallelism: 4 threads (adjust based on available CPU cores)
• Target: 100-500ms per hash on production hardware

bcrypt cost factors:

• Cost 10: ~100ms (minimum acceptable)
• Cost 12: ~300ms (recommended for most applications)
• Cost 14: ~1s (high-security applications)
• Increase by 1 every 18-24 months as hardware improves

Benchmarking script:

import time
from argon2 import PasswordHasher

ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4)

start = time.time()
ph.hash("benchmark")
elapsed = time.time() - start
print(f"Hash time: {elapsed:.3f}s")
# Target: 0.1 - 0.5 seconds

Migration Strategy

When upgrading hashing parameters or migrating from a weaker algorithm:

1. Do not force password resets — this creates poor user experience and does not improve security (users choose weaker passwords).
2. Rehash on next login — when a user successfully logs in with an old hash, rehash with the new algorithm and update the database.

def verify_and_update(password, stored_hash):
    if stored_hash.startswith('$argon2id$'):
        # Current algorithm — verify normally
        try:
            ph.verify(stored_hash, password)
            if ph.check_needs_rehash(stored_hash):
                update_hash_in_db(ph.hash(password))
            return True
        except VerifyMismatchError:
            return False
    else:
        # Legacy algorithm (e.g., bcrypt) — verify and upgrade
        if bcrypt.checkpw(password.encode(), stored_hash.encode()):
            update_hash_in_db(ph.hash(password))
            return True
        return False

Practice: Implement Secure Password Storage

Implement a secure password storage system for a new application. Choose the algorithm, parameters, and write the hash and verify functions.