When you create an account on a well-built website, your password is never stored as the text you typed. Instead, it is run through a one-way mathematical function called a hash, and only the result — a fixed-length string of seemingly random characters — is saved in the database. If an attacker steals that database, they get hashes, not passwords. The security of your account then depends entirely on how difficult it is to reverse those hashes back into the original passwords.
Hashing Is Not Encryption
This distinction matters. Encryption is reversible — given the right key, you can decrypt the data and recover the original. Hashing is a one-way function. There is no key, no decryption step, and no mathematical shortcut to get from the hash back to the password. The only way to “crack” a hash is to guess the original input, hash the guess, and check if the results match.
This is exactly what attackers do when they obtain a stolen database. They run millions or billions of candidate passwords through the same hashing algorithm and compare the output to the stolen hashes. Modern GPUs can test over 180 billion guesses per second against weak algorithms like MD5 or SHA-1 — which is why the choice of hashing algorithm is the difference between a password that falls in milliseconds and one that resists attack for centuries.
Salting: Defeating Precomputed Attacks
Without additional protection, identical passwords produce identical hashes. An attacker could precompute a massive table of hash-to-password mappings — a rainbow table — and look up millions of hashes instantly without doing any real-time computation.
Salting defeats this. A salt is a random value generated uniquely for each password and appended to it before hashing. The same password with two different salts produces two completely different hashes. This forces the attacker to crack each user’s password individually rather than amortising the work across the entire database.
Every modern password hashing algorithm handles salting automatically. If a service’s password database is breached and all hashes are identical for users who chose the same password, that service was not salting — a failure so basic it borders on negligence.
The Algorithms That Matter
Not all hashing algorithms are suitable for passwords. General-purpose functions like SHA-256 are designed to be fast, which is exactly the wrong property for password storage. Purpose-built password hashing algorithms are deliberately slow, forcing attackers to spend significant time and resources on each guess.
bcrypt has been the workhorse of password hashing since 1999. It is based on the Blowfish cipher and includes a configurable cost factor that controls how much computation is required to produce each hash. With a cost factor of 12, a single hash takes roughly 250 milliseconds — imperceptible to a user logging in, but devastating to an attacker who needs to test billions of candidates. bcrypt’s main limitation is that it uses a fixed 4 KB of memory, which means attackers with specialised hardware can still run many parallel instances.
scrypt, introduced in 2009, added memory hardness to the equation. It requires significant RAM to compute each hash, which makes attacks using GPUs and custom hardware much more expensive. GPUs have enormous parallel processing power but limited memory per core, so a memory-hard algorithm forces them to run far fewer simultaneous operations. scrypt is widely deployed and has a strong track record, though it has been somewhat overtaken by a newer design.
Argon2 won the Password Hashing Competition in 2015 and is now the recommended choice for new systems according to OWASP. It comes in three variants: Argon2d for maximum resistance against GPU cracking, Argon2i for resistance against side-channel attacks, and Argon2id — the recommended default — which combines both approaches. Argon2 allows fine-grained control over memory usage, computation time, and parallelism, letting developers tune the algorithm to their specific hardware and security requirements.
The current OWASP recommendation for Argon2id is a minimum of 19 MB of memory, 2 iterations, and 1 degree of parallelism. For systems with more resources, 46 MB of memory with a single iteration provides equivalent protection.
What Happens When It Goes Wrong
The breaches that make headlines almost always involve outdated or improperly implemented password hashing. Databases stored with unsalted MD5 or SHA-1 are cracked in bulk within hours of being leaked. Even passwords that look complex — mixed case, symbols, digits — fall quickly when the underlying hash provides no meaningful resistance.
Properly hashed passwords are a different story. A 16-character random password stored with Argon2id at recommended settings would take longer to crack than the remaining lifespan of the sun, even with hardware that does not yet exist. The algorithm does not eliminate the attacker’s ability to guess, but it makes each guess so expensive that the attack becomes economically irrational.
What This Means for You
You cannot control how a service hashes your password. Some use Argon2, some use bcrypt, some — regrettably — still use MD5. What you can control is the strength of the password itself.
A long, random, unique password generated by a tool like Safe Pass Guru provides the strongest possible input to whatever hashing algorithm the service uses. Even a weak algorithm provides reasonable protection when the input password has enough entropy to resist guessing. A short, common, or reused password is vulnerable regardless of the algorithm behind it.
The best defence is the combination of both: a strong, unique password on your side and a modern hashing algorithm on the service’s side. You can ensure the first; the second is why choosing services that take security seriously — and holding them accountable when they do not — matters more than most people realise.