Secure Password Hashing in Node.js with Bcrypt and Argon2

This article outlines the essential safety precautions and best practices for handling raw password inputs in Node.js applications using bcrypt or argon2. It covers secure transmission, preventing denial-of-service (DoS) attacks, managing memory securely, and configuring hashing parameters to ensure robust authentication security.

1. Secure the Input in Transit

Before a password ever reaches your hashing function, it must be secured in transit. Always use HTTPS (TLS) to encrypt the connection between the client and your Node.js server. Without HTTPS, attackers can intercept raw passwords in transit, rendering even the strongest hashing algorithms useless.

2. Enforce Password Length Limits (Preventing DoS)

Both bcrypt and argon2 are computationally expensive by design. Attackers can exploit this to launch Denial of Service (DoS) attacks by sending extremely long strings as passwords, forcing your server to waste CPU cycles hashing them.

• Bcrypt Limitation: bcrypt has a maximum input limit of 72 bytes. Any characters beyond this limit are ignored. While this prevents CPU exhaustion from massive inputs, it silently truncates user passwords.
• Argon2 Limitation: argon2 does not have a strict input limit, but hashing massive strings will severely impact server performance.
• The Solution: Implement a strict maximum length validation (e.g., maximum 128 characters) on your password input fields before passing them to the hashing function.

3. Avoid Memory Leaks of Raw Passwords

In Node.js, strings are immutable. Once a raw password string is created, it remains in system memory until the garbage collector cleans it up, exposing it to potential memory dump exploits.

• Minimize Exposure: Avoid assigning the raw password to global variables or passing it through multiple unnecessary functions.
• Buffer Usage: For high-security environments, handle the raw password as a Buffer and overwrite the buffer with zeroes immediately after the hashing process is complete.

4. Choose and Configure the Right Work Factors

To protect against brute-force attacks, you must configure your hashing algorithms to be slow enough to deter attackers but fast enough to not degrade user experience.

• For Bcrypt: Use a salt round (work factor) of at least 10 to 12. As hardware improves, you should periodically increase this number.
• For Argon2: Tune the memory cost (memoryCost), time cost (timeCost), and parallelism (parallelism) parameters according to your specific server hardware. Argon2id is the recommended variant for general password hashing as it resists both GPU-based and side-channel attacks.

5. Never Log Raw Passwords or Error Details

Ensure your application logging framework is configured to never record raw password inputs.

• Use middleware to sanitize incoming request bodies in your logs.
• When catching authentication errors, write generic messages to the client (e.g., “Invalid credentials”) rather than specific errors that reveal whether the username or the password was incorrect.