Secure Password Storage: A Guide to bcrypt, Argon2, and scrypt
Back to Blog
Engineeringpassword securitybcryptArgon2

Secure Password Storage: A Guide to bcrypt, Argon2, and scrypt

Stop using MD5 and SHA-256 for passwords. Discover why bcrypt, scrypt, and Argon2 are the industry standards for secure authentication in 2026.

March 14, 202612 min read

In 2026, a database leak isn't just a PR nightmare; it's an existential threat. With the rise of specialized hardware like ASICs and the increasing accessibility of GPU-accelerated cracking clusters, the methods we used to protect user credentials five years ago are now dangerously obsolete. Did you know that over 80% of data breaches involve stolen or weak passwords? If your application is still using MD5, SHA-1, or even unsalted SHA-256 to store passwords, you aren't just behind the curveโ€”you are leaving the door wide open for attackers.

At Increments Inc., we've spent over 14 years building high-performance, secure platforms for global clients like Freeletics and Abwaab. We know that security isn't a feature; it's the foundation. In this guide, we will dive deep into the mechanics of secure password storage, comparing the industry's heavy hitters: bcrypt, scrypt, and Argon2.


The Fundamental Rule: Never Encrypt, Always Hash

Before we look at specific algorithms, we must clarify a common misconception. Many developers use the terms "encryption" and "hashing" interchangeably. In the context of password storage, this is a critical mistake.

Encryption is a two-way function. If you encrypt a password, you can decrypt it back to plaintext if you have the key. This means if an attacker gains access to your server and your encryption keys, every user password is compromised.

Hashing, on the other hand, is a one-way cryptographic function. You can turn a password into a hash, but you (theoretically) cannot turn a hash back into a password. When a user logs in, you hash their input and compare it to the stored hash. If they match, the user is authenticated.

Why Simple Hashing Fails

Traditional hashes like MD5 and SHA-256 were designed for speed. They are meant to verify large files quickly. This speed is a liability for passwords. A modern GPU can calculate billions of SHA-256 hashes per second. If an attacker gets your database, they can brute-force a simple hash in minutes.

This is why we use Slow Hashing Algorithms (Key Derivation Functions). These algorithms are designed to be computationally expensive, making brute-force attacks economically and technically unfeasible.


The Anatomy of a Secure Password Hash

A modern, secure hash isn't just a string of random characters. It is a structured package that includes everything needed for verification except the secret itself.

1. The Salt

A salt is a unique, random string added to the password before hashing. It ensures that two users with the same password (e.g., "Password123") have completely different hashes in the database. This prevents Rainbow Table attacks, where attackers use pre-computed tables of hashes to look up common passwords.

2. The Pepper

While a salt is 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). Even if the database is leaked, the attacker cannot crack the hashes without the pepper.

3. The Cost Factor (Work Factor)

This parameter determines how much CPU time or memory is required to compute the hash. As hardware gets faster, you can increase the cost factor to keep your hashes secure without changing your code.


bcrypt: The Reliable Veteran

Released in 1999 and based on the Blowfish cipher, bcrypt has been the industry standard for over two decades. It introduced the concept of a built-in cost factor, allowing developers to scale security as hardware evolved.

How bcrypt Works

bcrypt uses a modified version of the Blowfish key schedule, called "Eksblowfish." It goes through thousands of rounds of computation to generate the final hash.

Pros:

  • Extremely well-vetted and widely supported in every programming language.
  • Resistant to simple GPU cracking due to its branching logic.
  • Simple to implement correctly.

Cons:

  • The 72-character limit: bcrypt only considers the first 72 bytes of a string. Longer passwords are truncated, which can be a security risk if not handled by pre-hashing (e.g., SHA-256 hashing the password before passing it to bcrypt).
  • CPU-bound only: It doesn't require much memory, which means attackers can build custom FPGA or ASIC hardware to crack it more efficiently than a general-purpose CPU.

bcrypt Hash Structure

$2a$12$R9h/cIPz0gi.URNNX3kh2OPST9/zBdtUM7WfGaJP9lTO8Yph8Xf96

  • $2a$: Algorithm version.
  • $12$: Cost factor (2^12 iterations).
  • R9h/cIPz0gi.URNNX3kh2O: The 22-character salt.
  • PST9/zBdtUM7WfGaJP9lTO8Yph8Xf96: The 31-character hash.

Pro Tip: If you are starting a new project and aren't sure where to begin, bcrypt is a safe, "nobody ever got fired for choosing" option. However, if you're building a high-stakes enterprise platform, you might want to look at the next two options. Start a project with Increments Inc. to get a free technical audit of your current security architecture.


scrypt: The Memory-Hard Pioneer

Created in 2009, scrypt was designed to address the primary weakness of bcrypt: its vulnerability to custom hardware (ASICs).

Why Memory Hardness Matters

Attackers can build chips that do nothing but calculate bcrypt hashes. These chips are fast because bcrypt doesn't need much RAM. scrypt forces the computer to use a large amount of memory to calculate the hash. Since memory is expensive and takes up physical space on a chip, it makes building custom hardware for cracking scrypt incredibly costly.

Pros:

  • Highly resistant to ASIC and FPGA attacks.
  • Configurable CPU, memory, and parallelization parameters.

Cons:

  • Harder to tune correctly. If you set the memory requirement too high, you could accidentally perform a Denial of Service (DoS) attack on your own server during peak login times.
  • Less ubiquitous than bcrypt in some legacy environments.

Argon2: The Modern King

In 2015, the Password Hashing Competition (PHC) concluded, and Argon2 was crowned the winner. It is currently considered the most secure and flexible hashing algorithm available.

The Three Flavors of Argon2

  1. Argon2d: Optimized for speed and resistance against GPU cracking. Best for cryptocurrencies but vulnerable to side-channel attacks.
  2. Argon2i: Designed to resist side-channel attacks (where an attacker times how long a hash takes to guess information). Best for password hashing.
  3. Argon2id: A hybrid that combines the best of both. This is the recommended version for 99% of web applications.

Why Argon2 Wins

Argon2 allows you to fine-tune three different dimensions of security:

  • Iterations (Time): How many passes over the memory are made.
  • Memory (Space): How many kibibytes of RAM are used.
  • Parallelism (Lanes): How many CPU threads are used.

This level of granularity allows developers to maximize security based on their specific server hardware.


Comparison Table: bcrypt vs. scrypt vs. Argon2

Feature bcrypt scrypt Argon2id
Year Released 1999 2009 2015
Primary Strength Simplicity & Ubiquity Memory Hardness Winner of PHC, Most Secure
Hardware Resistance Moderate (GPU) High (ASIC/FPGA) Very High (ASIC/GPU/FPGA)
Max Password Length 72 characters No limit No limit
Configurability Iterations only Iterations, Memory, Parallelism Iterations, Memory, Parallelism
Recommended For Legacy apps, simple web apps High-security internal tools Modern SaaS, Enterprise, FinTech

Secure Authentication Architecture

Storing the hash is only half the battle. You need a secure pipeline to handle the data from the moment the user types it until it hits your database.

The Secure Flow Diagram

[ User Client ] 
      | 
      | (1) TLS 1.3 Encrypted POST Request
      v
[ Load Balancer / WAF ] 
      | 
      | (2) Rate Limiting & DDoS Protection
      v
[ Application Server ] 
      | 
      | (3) Combine Password + Secret Pepper
      | (4) Hash using Argon2id (Salt generated automatically)
      v
[ Database (PostgreSQL/MongoDB) ]
      | 
      | (5) Store: { userId, email, passwordHash }

Key Security Layers:

  1. Transport Security: Never send passwords over HTTP. Use TLS 1.3.
  2. Rate Limiting: Prevent brute-force attempts at the API level. If a user fails 5 times, lock the account or trigger a CAPTCHA.
  3. The Pepper Strategy: Store your pepper in a secret manager (like AWS Secrets Manager or HashiCorp Vault), not in your code repository.

At Increments Inc., we specialize in building these multi-layered security architectures. Every project inquiry we receive gets a free AI-powered SRS document (IEEE 830 standard) and a $5,000 technical audit to ensure your project starts on a foundation of ironclad security. Talk to our engineers today.


Implementation Examples

Node.js (using argon2 library)

Argon2 is the preferred choice for modern Node.js applications.

const argon2 = require('argon2');

async function securePassword(password) {
  try {
    // Hash the password with custom constraints
    const hash = await argon2.hash(password, {
      type: argon2.argon2id,
      memoryCost: 2 ** 16, // 64 MB
      timeCost: 3,         // 3 iterations
      parallelism: 1       // 1 thread
    });
    return hash;
  } catch (err) {
    // Handle error
  }
}

async function verifyPassword(hash, password) {
  return await argon2.verify(hash, password);
}

Python (using passlib)

Passlib is a versatile library that handles salts and multiple algorithms seamlessly.

from passlib.hash import argon2

# Hashing
hash = argon2.using(rounds=4, memory_cost=65536, parallelism=1).hash("user_password_123")

# Verification
is_valid = argon2.verify("user_password_123", hash)
print(f"Password is valid: {is_valid}")

Common Pitfalls to Avoid

1. Re-inventing the Wheel

Never try to write your own hashing algorithm. Cryptography is incredibly difficult to get right. Use well-maintained, audited libraries like bcryptjs, scrypt-js, or argon2.

2. Low Cost Factors

Setting a cost factor that is too low makes it easy for attackers. Setting it too high makes your server slow. The sweet spot is a hash that takes about 200ms to 500ms to calculate on your production hardware. This is fast enough for a human to not notice, but slow enough to stop a mass brute-force attack.

3. Forgetting to Upgrade

As hardware improves, your old hashes become weaker. Modern systems should implement a "re-hash on login" strategy. When a user logs in, check if their hash uses an old algorithm or a low cost factor. If it does, calculate a new hash using your current standards and update the database.


Why Increments Inc. is Your Security Partner

Choosing the right hashing algorithm is just one piece of the puzzle. Building a truly secure platform requires expertise in infrastructure, database design, and secure coding practices.

With over 14 years of experience and a global footprint from Dhaka to Dubai, Increments Inc. has helped companies across FinTech, HealthTech, and EdTech secure their most sensitive data. We don't just write code; we build resilient digital assets.

When you work with us, you get:

  • Expertise: 14+ years of building web and mobile products.
  • Transparency: A free IEEE 830 standard SRS document before you spend a dime.
  • Quality Assurance: A $5,000 technical audit included with every project.
  • Global Standards: We follow OWASP Top 10 and industry-specific compliance (GDPR, HIPAA) by default.

Don't leave your user data to chance. Whether you're building a new MVP or modernizing a legacy platform, we can help you implement a security architecture that stands the test of time.


Key Takeaways

  • MD5 and SHA-256 are NOT for passwords. They are too fast and easily cracked.
  • Salting is mandatory. It prevents rainbow table attacks by making every hash unique.
  • Argon2id is the current gold standard. Use it if your language and environment support it.
  • bcrypt is the best fallback. It's secure, reliable, and available everywhere.
  • scrypt is great for hardware resistance. Use it if you need specific protection against ASICs.
  • Use a Pepper. Store a secret key outside your database for an extra layer of defense.
  • Tune your parameters. Aim for a 200-500ms hashing time on your production servers.

Ready to build something secure? Start your project with Increments Inc. today or reach out to us on WhatsApp to discuss your security needs. Letโ€™s build the future, securely.

Topics

password securitybcryptArgon2scryptcybersecuritybackend developmentauthentication

Written by

II

Increments Inc.

Engineering Team

Want to build something?

Get a free consultation and technical audit worth $5,000. We'll help you build your next successful product.

  • Free $5,000 technical audit
  • No upfront payment required
  • 14+ years of experience