Secure Password Hashing in Node.js and Python

September 11, 2026 · Security, Auth, Node.js, Python

Password hashing is one of the most important security controls in any authentication system. If your user database is ever leaked, strong password hashing can be the difference between a contained incident and every user account being compromised.

In 2026, the practical recommendation is simple: use Argon2id for new systems when you can, use bcrypt when platform compatibility matters, and never use fast general-purpose hashes like SHA-256, SHA-512, or MD5 for passwords.

Hashing vs encryption: the key difference

Password hashing is not encryption. Encryption is reversible if you have the key. Password hashing is intentionally one-way. When a user logs in, you hash the submitted password with the same algorithm and parameters, then verify it against the stored hash.

A secure password hash should be slow, salted, memory-hard when possible, and produced by a well-reviewed password hashing library. The goal is not to make login slow for one user. The goal is to make bulk cracking expensive for an attacker with GPUs or rented cloud hardware.

Use Argon2id for new applications

Argon2id is the preferred password hashing algorithm for most new applications in 2026. It combines resistance to GPU cracking with practical performance on servers. It is recommended over raw SHA hashes and generally preferred over bcrypt when your runtime and deployment environment support it.

Typical production parameters should be benchmarked on your infrastructure, but a reasonable starting point is:

• Memory cost: 64 MiB to 256 MiB
• Time cost: 2 to 4 iterations
• Parallelism: 1 to 4 threads
• Target verification time: about 100ms to 500ms per login on your server

Secure password hashing in Node.js with Argon2id

In Node.js, the argon2 package is a practical choice. Install it with npm:

npm install argon2

Here is a production-oriented password hashing module:

import argon2 from "argon2";

export async function hashPassword(password) {
  return await argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 19456,
    timeCost: 3,
    parallelism: 1
  });
}

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

The returned Argon2 hash string includes the algorithm, version, parameters, salt, and derived hash. You do not need to store the salt separately.

A stored hash will look similar to this:

$argon2id$v=19$m=19456,t=3,p=1$base64Salt$base64Hash

If you need to inspect encoded data while debugging authentication records, DevToolKit’s Base64 Encoder/Decoder at ../tools/base64.html can help you understand encoding formats. Do not paste real production passwords or sensitive hashes into browser tools unless you fully control the environment.

Secure password hashing in Python with Argon2id

In Python, use argon2-cffi. Install it with pip:

pip install argon2-cffi

A safe implementation looks like this:

from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

ph = PasswordHasher(
    time_cost=3,
    memory_cost=65536,
    parallelism=2,
    hash_len=32,
    salt_len=16
)

def hash_password(password: str) -> str:
    return ph.hash(password)

def verify_password(stored_hash: str, password: str) -> bool:
    try:
        return ph.verify(stored_hash, password)
    except VerifyMismatchError:
        return False

Like the Node.js version, the Python hash string contains the parameters and salt. That makes future verification and migration easier.

When bcrypt is still a good choice

bcrypt is still acceptable in 2026 when Argon2id is unavailable or when you need maximum compatibility across older stacks. It is battle-tested and widely supported, but it is not memory-hard like Argon2id.

For bcrypt, use a cost factor that gives an acceptable verification time on your production hardware. Common values in 2026 are usually between 12 and 14, but you should benchmark instead of copying a number blindly.

Node.js bcrypt example

import bcrypt from "bcrypt";

const BCRYPT_COST = 12;

export async function hashPassword(password) {
  return await bcrypt.hash(password, BCRYPT_COST);
}

export async function verifyPassword(hash, password) {
  return await bcrypt.compare(password, hash);
}

Python bcrypt example

import bcrypt

BCRYPT_ROUNDS = 12

def hash_password(password: str) -> bytes:
    password_bytes = password.encode("utf-8")
    salt = bcrypt.gensalt(rounds=BCRYPT_ROUNDS)
    return bcrypt.hashpw(password_bytes, salt)

def verify_password(stored_hash: bytes, password: str) -> bool:
    return bcrypt.checkpw(password.encode("utf-8"), stored_hash)

Important bcrypt limitation: bcrypt uses only the first 72 bytes of the password. If your application supports long passphrases, Argon2id avoids that surprise.

Never use SHA-256 alone for passwords

SHA-256 is excellent for integrity checks, signatures, and many cryptographic workflows. It is not appropriate for password storage by itself because it is too fast. Attackers can test billions of SHA-256 guesses quickly using GPUs.

This is insecure:

import crypto from "crypto";

const hash = crypto
  .createHash("sha256")
  .update(password)
  .digest("hex");

This is also insecure:

import hashlib

hash_value = hashlib.sha256(password.encode("utf-8")).hexdigest()

Adding a salt to SHA-256 is still not enough. You need an algorithm designed for password hashing: Argon2id, bcrypt, scrypt, or PBKDF2 with strong parameters when compliance requires it.

Salts, peppers, and what to store

A salt is a unique random value generated per password. It prevents attackers from using precomputed rainbow tables and ensures identical passwords produce different hashes. Modern Argon2 and bcrypt libraries generate salts automatically and encode them inside the hash string.

A pepper is a separate secret stored outside the database, usually in an environment variable or secrets manager. It can reduce impact if only the database leaks, but it adds operational complexity. If you use a pepper, do not hard-code it in your source code.

import argon2 from "argon2";

const PEPPER = process.env.PASSWORD_PEPPER;

export async function hashPassword(password) {
  return await argon2.hash(password + PEPPER, {
    type: argon2.argon2id,
    memoryCost: 19456,
    timeCost: 3,
    parallelism: 1
  });
}

If you use a pepper, plan rotation carefully. A common approach is to rotate peppers only when users log in or reset passwords, rather than trying to rehash every password immediately.

How to migrate old password hashes safely

Many real systems contain legacy hashes. The safest migration pattern is rehash on login. When a user logs in successfully with the old algorithm, immediately replace the stored hash with a modern Argon2id hash.

async function login(user, password) {
  if (user.hash.startsWith("$argon2id$")) {
    return await argon2.verify(user.hash, password);
  }

  if (user.hash.startsWith("$2b$")) {
    const ok = await bcrypt.compare(password, user.hash);
    if (ok) {
      user.hash = await hashPassword(password);
      await saveUser(user);
    }
    return ok;
  }

  return false;
}

Avoid forcing every user through a password reset unless the legacy hashes are dangerously weak or you suspect active compromise. For old unsalted MD5 or SHA-1 hashes, forced resets are often the better call.

Password validation without weakening security

Password rules should not make users choose predictable passwords. In 2026, prefer minimum length, breached-password screening, and rate limiting over complex composition rules like “one uppercase, one symbol, one number.”

Good baseline rules:

• Require at least 12 characters for normal passwords
• Allow long passphrases up to at least 128 characters
• Block known breached passwords
• Do not silently truncate passwords
• Rate-limit login attempts by account and IP
• Use MFA for sensitive accounts

If you are testing password policy regexes, DevToolKit’s Regex Tester at ../tools/regex-tester.html is useful for validating patterns. Keep the policy simple: regex should assist validation, not become the main security control.

Store authentication metadata clearly

Authentication records should make migrations and audits easy. Store the password hash, algorithm metadata if not already embedded, timestamps, and security flags. For API responses or internal debug objects, DevToolKit’s JSON Formatter at ../tools/json-formatter.html can help inspect structured data safely in development.

{
  "userId": "usr_123",
  "passwordHash": "$argon2id$v=19$m=65536,t=3,p=2$...",
  "passwordUpdatedAt": "2026-09-11T12:00:00Z",
  "mfaEnabled": true
}

For user IDs, reset tokens, or correlation IDs, use cryptographically random values. If you need non-sensitive identifiers during development, DevToolKit’s UUID Generator at ../tools/uuid-generator.html is convenient, but production reset tokens should come from a secure random generator.

Production checklist for password hashing

• Use Argon2id for new systems
• Use bcrypt only when Argon2id is not practical
• Never store plaintext passwords
• Never use MD5, SHA-1, SHA-256, or SHA-512 alone
• Use established libraries instead of custom crypto
• Benchmark parameters on production-like hardware
• Store the full encoded hash string
• Rate-limit login attempts
• Use MFA for admin and high-risk accounts
• Plan hash upgrades with rehash-on-login

Final recommendation

For most Node.js and Python applications in 2026, use Argon2id with library-managed salts, tune the parameters to around 100ms to 500ms per verification, and store the full encoded hash string in your database. Add rate limiting, MFA, secure reset flows, and migration logic for legacy hashes.

Password hashing is not glamorous, but it is one of the highest-leverage security decisions in your application. Get it right once, document the parameters, and future audits become much easier.