Argon2 password hashing is a method for converting a password into a scrambled value that a service stores instead of the original text. It was designed to make guessing those stored values slow and expensive. Understanding it helps developers, administrators and curious readers judge whether a login system is handling sensitive data responsibly.
This article explains what a password hash is, how Argon2 works at a conceptual level, and why its design resists attacks that use specialized hardware. It also covers the settings that control its cost, common mistakes, and practical steps for anyone who needs to choose or review a password storage approach.
Why Services Never Store Passwords in Plain Text
When you create an account, a service needs to check your password later, but it should not keep the password itself. A password hash is a one-way transformation that turns your password into a fixed-length string of characters. The service stores that string and compares it with a fresh hash of whatever password you type at sign-in.
Because the transformation runs in only one direction, a stolen hash does not directly reveal the original password. An attacker who obtains the stored values must guess candidate passwords, hash each guess, and compare the results. The difficulty of that guessing process is what determines how well the stored data is protected.
This is why the choice of hashing algorithm matters so much. A fast algorithm lets an attacker test billions of guesses cheaply, while a deliberately slow and memory-hungry algorithm sharply limits how many guesses can be tried in a given period.
What Argon2 Is and Where It Came From
Argon2 is a password hashing function that won the Password Hashing Competition, an open cryptographic contest held in 2015. It was designed by researchers to be a modern successor to older schemes that were not built to resist specialized attack hardware. The competition selected it as the winner, and it has since been standardized in the IETF specification RFC 9106.
Argon2 comes in three variants. Argon2d maximizes resistance to attacks that use graphics processors and custom chips, but it can be more exposed to certain side-channel timing observations. Argon2i is designed to resist those timing observations. Argon2id combines both approaches and is the variant generally recommended for password hashing today.
Most readers do not implement Argon2 themselves. They encounter it inside libraries, frameworks and identity platforms. Knowing that Argon2id is the common recommendation helps you recognize a sound configuration when you see one in documentation or a code review.
How Argon2 Makes Guessing Expensive
Argon2 relies on a few design ideas that work together to raise the cost of each guess. Understanding them in plain terms makes its settings easier to reason about.
- It uses a salt, a random value generated for each password, so identical passwords produce different stored hashes and precomputed lookup tables become useless.
- It requires a configurable amount of memory, forcing each hash computation to occupy a meaningful block of RAM rather than running quickly in tiny pieces.
- It repeats its internal work a configurable number of times, adding processing time that is acceptable for one login but painful across billions of guesses.
- It can run in parallel across multiple lanes, letting administrators tune how much processing power a single hash consumes on their own servers.
These properties do not make a weak password safe, and no hash can rescue a password that is common or guessable. What they do is make large-scale guessing against stolen data far slower and more costly, buying time for users and administrators to respond after a breach.
Choosing Memory, Time and Parallelism Settings
Argon2 exposes three main parameters: memory cost, time cost and parallelism. Memory cost sets how much RAM each hash uses, time cost sets how many passes the algorithm makes over that memory, and parallelism sets how many threads can work at once. Raising any of them increases the work required for each guess.
There is no single correct setting, because the right values depend on your server’s hardware, your traffic volume and how long a login can reasonably take. A common approach is to benchmark on the production server and choose the strongest parameters that keep login latency comfortable and do not exhaust memory under peak load.
The OWASP Password Storage Cheat Sheet and RFC 9106 both publish guidance and example parameter ranges. Treat any numbers you find there as starting points to test against your own environment rather than fixed rules, since recommended values change as hardware improves.
Common Mistakes When Implementing Password Hashing
One frequent error is choosing parameters that are too weak because the system feels slow during testing. Developers sometimes lower memory or time cost to make logins instant, which quietly reduces protection for every stored password. A login that takes a fraction of a second is often a sign the settings are reasonable, not a reason to weaken them.
Another mistake is reusing a single salt across many passwords or generating salts with a predictable random source. Argon2 libraries normally generate salts correctly when used as intended, so the safer path is to rely on the library’s default salt handling rather than building your own. Hand-rolled cryptography is a common source of subtle flaws.
Some systems hash passwords with Argon2 but then wrap the result in other reversible encryption or log the raw password during an error. Hashing protects nothing if plain text copies exist elsewhere, so review logs, backups and debugging output along with the hashing code itself.
Argon2 Compared With Older Password Hashing Schemes
Several older schemes are still found in legacy systems. Knowing how they differ helps you prioritize upgrades and recognize when a migration is worth the effort.
Bcrypt and Its Practical Role
Bcrypt has been a widely used password hashing function for many years. It includes a salt and a configurable work factor, which makes it considerably better than fast general-purpose hashes. However, its memory use is fixed and relatively small, which gives specialized hardware more room to compete.
Many systems running bcrypt are not in immediate danger, provided the work factor is high enough and the password policy discourages weak choices. Migrating to Argon2id is a sensible long-term improvement rather than an emergency for most well-configured deployments.
When planning a move, consider that existing hashes can often be upgraded gradually. The system can verify old bcrypt hashes at sign-in and then store an Argon2id hash once the user logs in successfully.
Scrypt and Why Memory Hardness Matters
Scrypt is a memory-hard function that predates Argon2 and was designed to make large-scale parallel attacks expensive. Like Argon2, it requires significant RAM for each computation, which is the central idea behind memory hardness. It remains a respectable choice in many libraries.
Argon2 generally receives more recommendation today because its design choices and standardization give administrators clearer tuning guidance. Both are far stronger than unhashed or fast-hashed storage, so the difference matters most when you are selecting a new system rather than auditing an existing one.
If you already run scrypt with reasonable parameters, there is no urgent need to replace it. Focus your attention on making sure salts are unique and that the parameters have been set deliberately.
PBKDF2 and Its Limitations
PBKDF2 is an older key derivation function that repeats a hash many times to slow guessing. It is widely supported and has been used in regulated environments for years. Its weakness is that it does not require memory, so it is comparatively easier to accelerate with graphics processors and custom chips.
Because PBKDF2 can still be configured with a high iteration count, it is not broken in the way that a fast hash is. Still, systems that have a choice should prefer a memory-hard function. Where regulations or platform constraints require PBKDF2, the answer is to set a strong iteration count and keep the password policy solid.
Protecting the Wider Login System Around the Hash
A strong hash is only one layer of a secure sign-in process. Attackers often bypass stored hashes entirely by guessing passwords directly against the login page, reusing credentials leaked from other sites, or stealing session tokens after authentication. Argon2 does nothing to stop those attacks.
Rate limiting and account lockout policies reduce the number of online guesses an attacker can make, while multi-factor authentication means a correct password alone is not enough. Monitoring for unusual sign-in patterns helps catch attempts that slip past other controls. Each of these works alongside good hashing rather than replacing it.
Encryption in transit also matters. Passwords should travel only over protected connections, and the application should never send them in URLs or log them. Hashing protects the database, while these other measures protect the moment of entry.
How to Evaluate an Argon2 Implementation
Before trusting a system with user passwords, check which Argon2 variant it uses and whether the parameters are documented and reasonable. If the variant is not stated, or the settings are impossible to find, that is a signal to ask questions of the vendor or maintainer before relying on it.
Choose libraries that are actively maintained, widely reviewed and well documented. Mature open source projects and established platform libraries are generally preferable to obscure code copied from unverified sources. Read the release notes for security fixes, and keep dependencies current.
For internal reviews, confirm that the code uses a unique random salt for every password, stores the full encoded hash with its parameters, and handles verification in constant time where the library supports it. These checks are simple to perform and catch many of the errors that undermine otherwise sound designs.
Checklist for Teams Deploying Argon2 Password Hashing
Teams that plan to adopt or review Argon2 can work through a short checklist. The items below cover the decisions that most often determine whether the deployment is genuinely protective.
- Use Argon2id unless you have a documented reason to choose another variant.
- Benchmark memory and time settings on production-class hardware before setting defaults.
- Confirm that each password receives a unique, randomly generated salt through the library.
- Store the encoded hash with its parameters so future tuning does not break verification.
- Plan a gradual upgrade path for any legacy hashes such as bcrypt or PBKDF2.
Completing this checklist does not make a system invulnerable, but it closes the most common gaps. Revisit the settings periodically, since hardware changes and recommended values are updated over time. Document the decisions so future maintainers understand why each parameter was chosen.
Next Steps for Improving Password Storage Over Time
Start by identifying how your system currently stores passwords. If you cannot answer that question quickly, review the authentication code or ask the team responsible for it. Knowing the current state tells you whether Argon2 adoption is a priority, a planned improvement or already complete.
If you are a developer, read the Argon2 specification and your library’s documentation together, then test settings in a staging environment before changing production. If you are an administrator or buyer, ask vendors directly which hashing function and parameters they use, and what their plan is for updating older records.
Revisit your approach each year or whenever hardware or guidance changes. Password storage is not a set-and-forget task. Steady, documented improvements to hashing, paired with strong authentication habits, give the best protection for the people who rely on your system.