Password Hashing and Salting: Limits and Superior Alternatives

Password security is the cornerstone of online safety, yet many systems still rely on outdated practices like hashing and salting. While these methods have been staples for decades, they come with significant flaws that can leave users vulnerable. In this article, we’ll break down what password hashing and salting are, explore real-world examples, highlight their issues and drawbacks, and introduce why Password-Authenticated Key Exchange (PAKE) protocols like OPAQUE provide a far superior alternative. With OPAQUE, even if a server is fully compromised, user accounts remain secure because the server learns nothing about passwords.

What is Password Hashing and Salting?

Password hashing is a one-way cryptographic function that transforms a password into a fixed-size string of characters, making it computationally infeasible to reverse. Salting adds a random value (salt) to the password before hashing, preventing rainbow table attacks by ensuring identical passwords produce different hashes.

How It Works

When a user creates an account, the system generates a unique salt, appends it to the password, and hashes the combination using algorithms like bcrypt, scrypt, or Argon2. The salt and hash are stored; during login, the process repeats and compares hashes.

Real-World Examples

Major platforms use these techniques:

• Atlassian (Jira, Confluence): Uses a PBKDF2 wrapper (their own solution: atlassian-security) for password storage. Source
• LinkedIn (pre-2012 breach): Initially used unsalted SHA-1, leading to 167 million exposed passwords. Source Wikipedia
• Dropbox: Employs bcrypt, a CPU-intensive key derivation function, to resist brute-force and hardware-accelerated attacks. Source

These examples show hashing and salting in action, but as we’ll see, they’re not foolproof.

Issues and Drawbacks of Hashing and Salting

Despite their benefits, hashing and salting have critical limitations:

1. Server-Side Vulnerabilities

Hashes are stored on servers. If breached (e.g., via SQL injection or insider threats), attackers can perform offline brute-force or dictionary attacks. Even with strong hashing, GPUs can crack weak passwords quickly.

2. Computational Costs and Scalability

Strong algorithms like Argon2 are intentionally resource-intensive to resist attacks, requiring significant memory and CPU time. Argon2, for instance, is a memory-hard function that fills RAM with data to thwart GPU-based cracking, which excels at parallel computations but struggles with high memory usage. This design makes it computationally expensive for servers during user registration and login, as each hash operation can take hundreds of milliseconds.

From a scalability perspective, this increases server load and operational costs. Websites with millions of users performing frequent logins may need more powerful hardware or cloud instances to handle the extra processing. Latency can also rise, potentially frustrating users with slower authentication times. For example, a server handling 1000 logins per second might require tuning parameters to balance security and performance, but even then, weak passwords remain vulnerable, Argon2 only slows down attackers, it doesn’t make inherently weak passwords (like “password123”) secure. Attackers can still brute-force or dictionary-attack them given enough time and resources.

Recommended Argon2id parameters for general use (based on OWASP guidelines):

• Memory cost (m): 19456 KiB (19 MiB) – Provides good resistance to attacks without excessive memory use.
• Time cost (t): 2 iterations – Balances security and speed.
• Parallelism (p): 1 thread – Suitable for most server environments. These settings ensure strong protection while keeping computation time under 500ms on modern hardware.

3. No Protection Against Client-Side Attacks Like Phishing or Keyloggers

Hashing only secures stored passwords; it doesn’t prevent interception during transmission or entry. This limitation applies to all password-based authentication systems, including PAKE protocols, as phishing and keyloggers are client-side threats.

4. Quantum Threats

Future quantum computers could break current hashing algorithms, rendering them obsolete.

Why PAKE Like OPAQUE is Way Better

Password-Authenticated Key Exchange (PAKE) protocols enable secure authentication without revealing passwords to servers. OPAQUE, standardized in RFC 9497, is a state-of-the-art PAKE that provides asymmetric password authentication.

How OPAQUE Works

OPAQUE uses a “password file” derived from the password via a key derivation function. During registration, the client sends an envelope (encrypted password data) to the server. For login, the client and server perform a key exchange where the server proves knowledge of the envelope without decrypting it. The client verifies the password implicitly.

Key Advantages Over Hashing and Salting

1. Zero-Knowledge Security: The server never sees or stores the password. Even in a full breach, attackers get unusable data.

2. Resistance to Server Compromises: Accounts remain safe; no offline cracking possible.

3. Built-in Forward Secrecy: Each session uses unique keys, protecting past and future communications.

4. No Password Reuse Risks: Since passwords aren’t stored, breaches don’t affect other services.

5. Superior Quantum Security: OPAQUE provides better protection against quantum attacks compared to traditional hashing.

Important Caveat on Quantum Resistance: While OPAQUE offers superior quantum security compared to traditional password hashing, it is not fully quantum-proof. OPAQUE relies on an Oblivious Pseudorandom Function (OPRF) that typically uses elliptic curve cryptography (ECC), which remains vulnerable to quantum attacks via Shor’s algorithm. For true post-quantum security, OPAQUE implementations should use quantum-resistant OPRF variants based on lattice cryptography or hash-based signatures.

Real-World Adoption

• Cloudflare: Uses OPAQUE for secure password authentication.
• WireGuard: Employs modern cryptographic protocols with similar zero-knowledge principles.
• Interactive Simulation: Experience OPAQUE in action with a live demo at https://opaque-auth.com/.
• Open-Source Library: The Serenity Kit OPAQUE JS library (https://github.com/serenity-kit/opaque) enables implementations like Ellipticc’s secure authentication.

Best Practices for Password Security

• Use PAKE protocols like OPAQUE for new systems.
• For legacy systems, combine hashing with multi-factor authentication (MFA).
• Educate users on strong, unique passwords.
• Regularly audit and update security practices.

Sources and Further Reading

• OWASP: Password Storage Cheat Sheet. “Use Argon2id with a minimum configuration.” https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• NIST: Digital Identity Guidelines. Recommendations for password hashing. https://pages.nist.gov/800-63-3/sp800-63b.html
• RFC 9497: The OPAQUE Asymmetric PAKE Protocol. https://datatracker.ietf.org/doc/rfc9497/
• Cloudflare: OPAQUE deployment. https://blog.cloudflare.com/opaque-oblivious-passwords/
• Adobe Breach Analysis: Lessons from 2013. https://www.troyhunt.com/adobe-credentials-and-serious/