The Definitive Guide to Password Hashing

In the modern landscape of cybersecurity, the question is not if a database will be breached, but when. When an attacker gains access to a user table, the only line of defense between them and the users' actual credentials is the quality of the password hashing implementation.

Poorly implemented password storage—such as storing passwords in plaintext or using fast, outdated hash functions—can lead to catastrophic identity theft and systemic security failures. This guide provides a technical deep-dive into the mechanics of password hashing, the evolution of algorithms, and the gold standards for secure implementation.

Key Takeaways

  • Never use reversible encryption: Passwords should be hashed, not encrypted.
  • Salt everything: Unique salts prevent rainbow table attacks and identical-password collisions.
  • Slow is secure: Use "hard" functions (Argon2, bcrypt) that are computationally expensive to thwart brute-force attempts.
  • Avoid "Homegrown" Crypto: Always use peer-reviewed, industry-standard libraries.
  • Iterative Hardening: Regularly update your work factor (cost) as hardware capabilities increase.

Understanding the Core Concepts

Hashing vs. Encryption

A common misconception among junior developers is the use of encryption for password storage. Encryption is two-way; it is designed to be decrypted with a key. If an attacker steals the encryption key, every password in the database is compromised instantly.

Hashing is a one-way cryptographic function. It takes an input (the password) and produces a fixed-size string (the hash). Mathematically, it is computationally infeasible to reverse a hash to find the original input. The only way to verify a password is to hash the user's attempt and compare it to the stored hash.

The Danger of Fast Hashes

General-purpose hash functions like MD5, SHA-1, and even SHA-256 are designed for speed. They are intended to verify the integrity of large files or create checksums. In a password context, speed is a liability.

Modern GPUs can calculate billions of SHA-256 hashes per second. An attacker with a modest rig can crack an 8-character password hashed with SHA-256 in a matter of hours. To secure passwords, we need functions that are intentionally slow.

The Anatomy of a Secure Hash

A professional password storage string typically looks like this: $argon2id$v=19$m=65536,t=3,p=4$S29yZSBvZiBzaGFsdA$7hS...

This string contains more than just the hash; it contains the metadata required to verify the password.

1. The Salt

A salt is a random string of bytes appended to the password before hashing.

  • Purpose: It ensures that two users with the same password ("Password123") have different hashes.
  • Defense: Salts neutralize Rainbow Tables—precomputed lists of hashes for common passwords. Without a salt, an attacker only needs to compute a hash once to crack every single user sharing that password.

2. The Pepper

While salts are stored in the database next to the hash, a pepper is a secret key stored outside the database (e.g., in an environment variable or a Hardware Security Module).

  • Purpose: To provide an extra layer of security. If the database is leaked but the application server remains secure, the attacker cannot crack the hashes because they lack the pepper.

3. The Cost Factor (Work Factor)

Modern algorithms allow developers to define a "cost" parameter. This determines how many iterations of the hashing process occur or how much memory is required. As hardware gets faster, you can increase the cost factor without changing the algorithm, keeping the "time-to-crack" constant.

Recommended Algorithms

Argon2 (The Gold Standard)

The winner of the Password Hashing Competition (PHC), Argon2 is currently the most recommended algorithm. It is designed to resist GPU and ASIC-based attacks by being memory-hard.

  • Argon2d: Optimized for maximum resistance against GPU cracking (best for cryptocurrency).
  • Argon2i: Optimized to resist side-channel attacks.
  • Argon2id: A hybrid version that provides the best of both worlds and is the recommended choice for general password storage.

bcrypt

A classic and highly reliable choice based on the Blowfish cipher. While not memory-hard like Argon2, it has stood the test of time and is supported by almost every programming language.

scrypt

Similar to Argon2, scrypt was designed to be memory-hard to make it expensive for attackers to use custom hardware (ASICs) to crack passwords.

Real-World Implementation

Bad Implementation (Anti-Pattern)

// DO NOT DO THIS
const crypto = require('crypto');

async function savePassword(password) {
    // MD5 is broken and fast. No salt.
    const hash = crypto.createHash('md5').update(password).digest('hex');
    await db.users.save({ passwordHash: hash });
}

Professional Implementation (Node.js with Argon2)

const argon2 = require('argon2');

async function hashPassword(password) {
    try {
        // Argon2 handles salt generation and storage automatically 
        // within the returned hash string.
        const hashedPassword = await argon2.hash(password, {
            type: argon2.argon2id,
            memoryCost: 65536, // 64MB
            timeCost: 3,        // 3 iterations
            parallelism: 4       // 4 threads
        });
        return hashedPassword;
    } catch (err) {
        console.error('Hashing failed:', err);
    }
}

async function verifyPassword(hashedPassword, providedPassword) {
    // Use a constant-time comparison to prevent timing attacks
    return await argon2.verify(hashedPassword, providedPassword);
}

Beyond the Hash: Integrated Security

Password hashing is only one part of the authentication lifecycle. Once a user is verified, the application typically issues a token, such as a JSON Web Token (JWT).

Securing the transition from password verification to session management is critical. For instance, when debugging authentication flows or analyzing the structure of your session tokens, tools like jwt-parser (from the ArmyTool suite) are invaluable for ensuring that claims are properly set and that tokens aren't exposing sensitive internal data.

Common Pitfalls to Avoid

  1. Truncation: Some older databases or libraries truncate strings at 32 or 64 characters. Password hashes (especially Argon2) can be longer. Ensure your database columns (e.g., VARCHAR(255)) can accommodate the full hash string.
  2. Double Hashing: Avoid "creative" schemes like sha256(bcrypt(password)). This adds no security and often introduces bugs or limits the password length.
  3. Client-Side Hashing: While hashing on the client can prevent the plaintext password from traveling over the wire, it doesn't replace server-side hashing. If you only hash on the client, the hash itself becomes the "password," and if the database is leaked, the hashes can be replayed.

Conclusion

Password security is a game of economics. You cannot make it impossible for an attacker to crack a password, but you can make it so computationally expensive that the effort outweighs the reward. By using Argon2id, implementing unique salts, and tuning your cost factors, you ensure that your users' credentials remain secure even in the face of a total database compromise.

The rule of thumb is simple: If you are writing your own hashing logic, you are doing it wrong. Use a vetted library, follow the OWASP guidelines, and prioritize "slowness" over convenience.