Password hashing explained: What it is and how it works

Storing raw passwords is one of the most dangerous mistakes a system can make. If attackers breach the system, they don’t need to crack anything: they get direct access to every user account.

That’s why most systems don’t store passwords at all. Instead, they store a hash, which is a fixed string of characters that represents the password but doesn’t reveal it. Even if someone steals the database, all they get are scrambled hashes, not the actual passwords.

That’s the goal, at least. In practice, weak hashes still get broken. Attackers use brute force attacks, precomputed tables, and automation that can tear through vulnerable hashes in hours.

This is why security doesn’t stop with hashing alone: salting, peppering, and modern algorithms add extra steps that make the attacker’s job far harder.

This guide covers how password hashing works, its strengths and weaknesses, and how it protects real-world systems.

Why plaintext passwords are dangerous

Picture this: you're running a website, and you decide to store user passwords exactly as people type them. No encryption, no scrambling—just plain text sitting in your database. It sounds convenient, but it's one of the worst security decisions you can make.

When attackers break into that database, they don't need fancy hacking tools or weeks of password cracking. Every single password is right there, ready to use.

Real-world risks of storing passwords in plaintext

• Accounts get taken over immediately. The stolen passwords work right away. No puzzle to solve, no code to break. Hackers can log into user accounts within minutes of accessing the database.
• The damage spreads to other websites. Most people use identical passwords across multiple services. This means that your users' banking passwords, social media accounts, and email logins will often match what they used on your site.
• Identity theft becomes much easier. These database breaches typically expose more than just login credentials. Phone numbers, email addresses, and sometimes Social Security numbers get stolen alongside the passwords. For example, a National Public Data breach alone exposed around 2.9 billion records tied to real identities.
• Automated tools amplify the problem. Specialized software can test stolen passwords against thousands of valuable targets—banking sites, government portals, and corporate email systems. Success rates might be low, but even a tiny percentage is a big win when you've got millions of stolen passwords to work with.
• Legal trouble and damaged reputation. Companies that store plaintext passwords may face serious regulatory penalties under laws like GDPR and state privacy regulations. Beyond the financial hit, customers lose trust fast when they discover their passwords were stored without basic protection.

Real-life data breach examples

• Yahoo Voices (2012). Yahoo Voices got hit in 2012 when hackers used SQL injection to steal about 450,000 plaintext passwords. The attackers posted everything online.
• RockYou (2009). This breach was even bigger—over 32 million unencrypted passwords leaked. Security researchers still use that password list today to test how strong people's passwords really are.
• Epik (2021). A massive leak that exposed around 15 million records with plaintext passwords, SSH keys, and payment info all stored without protection.
• RockYou2024. This collection of data breaches included nearly 10 billion unique plaintext passwords.

How password hashing works

Plaintext password storage is problematic, but encryption has its own issues. If someone steals the encryption key, they can decrypt everything. Hashing takes a completely different route by scrambling passwords into strings that nobody can unscramble, not even the system itself.

When criminals hack into a database full of hashed passwords, they find gibberish instead of login credentials. Each hash needs to be cracked separately, which costs them time and computing power they might not have.

Step-by-step: From input to hash

Step 1: User creates a password

A user picks their password during account creation and types it in.

Step 2: A salt is added

The system adds a salt. This is a mix of random characters that prevents two identical passwords from looking the same after hashing. Without salts, hackers could spot duplicate passwords easily.

Step 3: The hashing function runs

Next comes the actual hashing. The password plus salt runs through a mathematical blender that spits out a fixed-length string of characters. Same input always produces the same output, but the result looks completely random. What’s more, a minimal change to the input values will change the output entirely.

Step 4: The hash is stored

The database stores this scrambled mess along with the salt. The original password? Gone forever. The system literally can't retrieve it even if it wanted to.

Step 5: Verification happens during login

Later, when someone tries to log in, the system hashes their entered password with the stored salt. If this new hash matches what's in the database, they're in. No match means no access.

Hashing functions explained

SHA-256 and SHA-3

These are general-purpose cryptographic hash functions used in applications like digital signatures, blockchain, and file integrity checks. They’re designed to be extremely fast and efficient, producing a unique and irreversible output for each input.

But that speed becomes a weakness when used for password storage. Fast hashing allows attackers to run billions of guesses per second using modern GPUs or botnets. That means even moderately complex passwords can be cracked quickly in the event of a breach.

While SHA-256 and SHA-3 are secure in general cryptographic use, they lack built-in features like salting, which are critical for password protection. For this reason, security experts and organizations like OWASP strongly recommend using password-specific algorithms instead.

PBKDF2 (Password-Based Key Derivation Function 2)

PBKDF2 is a hashing function that combines a password with a salt, then runs that combination through a hash function thousands or even millions of times. Each iteration slows the process just enough to make large-scale brute-force attacks impractical. PBKDF2 is a trusted choice in enterprise and regulatory-compliant environments.

However, while PBKDF2 can be configured to run slowly, it generally offers less resistance against specialized hardware like GPUs compared to bcrypt.

Bcrypt

bcrypt was created specifically to protect stored passwords. It’s intentionally slow, which helps defend against brute-force attacks. The algorithm includes a “work factor” that controls how long each hash takes to compute. System administrators can adjust this over time to match rising hardware speeds and keep attacks costly.

bcrypt also adds a unique salt to every password automatically. That means even if two users choose the same password, their hashes will look completely different. This prevents attackers from using precomputed tables like rainbow tables to reverse hashes.

Argon2

Argon2 is a modern password hashing function designed to defend against brute-force attacks, even those using high-powered GPUs or custom-built hardware. It doesn’t just slow down hashing over time; it also consumes a large amount of memory, making attacks more expensive and harder to scale.

Argon2 has three versions: Argon2d (more resistant to GPU attacks), Argon2i (better against side-channel leaks), and Argon2id, which combines both and is the recommended default in most systems. It won the Password Hashing Competition in 2015 and is recommended by OWASP for new systems that can support it.

Reasons to use password hashing

• Protects against database breaches. Database breaches hurt less when passwords are properly hashed. Criminals walk away with useless scrambled data instead of working login credentials.
• Limits credential reuse attacks. Identical passwords stay invisible. Thanks to salting, two people with the password "123456" produce completely different hashes.
• Slows down brute force attacks. Brute force attacks become expensive. When each password guess takes several seconds to process, testing millions of combinations becomes a serious financial burden for attackers.
• Meets regulatory requirements. Regulations like HIPAA require proper password protection. Hashing checks that compliance box while also providing meaningful security benefits.
• Protects against insider threats. Even company insiders can't peek at user passwords. Database administrators, IT staff, and developers see only the scrambled hashes, which protects users from internal threats.

Password hashing vs. encryption

Many people mix up hashing and encryption when talking about password security, but these two methods work completely differently. Encryption scrambles data in a way that lets you unscramble it later with the right key. Hashing is a one-way function that takes your password and turns it into something that can never be turned back.

Think of encryption like putting your password in a locked box. If someone finds the key, they can open the box and see your original password. Hashing is more like putting your password through a paper shredder and then mixing it with confetti—there's no way to put those pieces back together.

What's the difference?

Encryption protects data by scrambling it using algorithms like AES or RSA. Only someone with the correct decryption key can read the original information. You could encrypt an entire password database, then decrypt it later to recover all the original passwords. This works great when you actually need to retrieve the original data, like with secure file storage or private messaging.

Hashing doesn't allow any retrieval. It transforms your password into a hash that's permanently changed. When you log in later, the system hashes whatever you type and compares it to the stored hash. If it matches, you get in.

But here's the key difference: even if hackers steal the entire database and know exactly which hashing algorithm was used, they still can't work backwards to figure out your original password. That irreversibility is exactly what makes hashing so valuable for password security.

When to use which

Encryption makes sense when you need to recover the original information later. API tokens, encrypted files, and sensitive documents are all instances where you'll eventually need to decrypt and use that data. But encryption carries risks for passwords. If the decryption key gets stored in the same place as the encrypted data, or if attackers can access it somehow, a single breach could expose everything.

Hashing is what you want for password storage. Here's the thing: hashed passwords can be verified without ever storing the actual password anywhere in your system. Even if attackers steal everything—the hashes, the salts, even the secret pepper values—they still have no direct way to get user passwords. Their only option is brute force guessing, which becomes incredibly expensive and time-consuming against properly hashed data.

Many real-world systems use both methods together. The password database contains hashed passwords, but the entire database file sits on encrypted storage. This creates multiple layers of protection: if someone breaks into the file system, they still need to decrypt the database, and even then they only find hashed passwords instead of usable credentials.

What is password salting and why does it matter?

Salting passwords before hashing prevents attackers from using precomputed lookup tables, making large-scale password cracking far more difficult. A salt is basically random data that gets mixed into each password before the hashing process starts. This ensures that two people with identical passwords end up with completely different hashes.

Without salts, attackers can use rainbow tables—massive precomputed lists that match common password hashes to their original passwords. It's like having answer sheets for a test. With salts, those answer sheets become worthless.

Why hashing alone doesn't cut it

Hashing turns passwords into scrambled strings, but it does this the same way every time. Hash "password123" twice without a salt, and you'll get identical results both times. That consistency creates problems.

Picture this scenario: an attacker steals your password database and notices that 20 different users have the exact same hash. They now know those 20 people are using the same password. Even worse, if that password happens to be something common like "password123," it might already exist in their rainbow table. One lookup gives them 20 cracked passwords instantly.

So essentially, hashing by itself is too predictable. Attackers can spot patterns, identify popular passwords, and crack multiple accounts simultaneously using precomputed tables.

How salting destroys rainbow table attacks

Salting changes the game. Even if two users both pick "password123," they'll end up with completely different hashes because each gets a unique salt mixed in before hashing.

The salt gets stored right next to the hash in your database, so it's not secret. But here's why that doesn't matter: rainbow tables are built for unsalted hashes. When every password gets a unique salt, those precomputed tables become useless. An attacker would need to build separate rainbow tables for every single salt value in your database.

Consider the math: if you're using 128-bit salts (which you should), that's 2^128 possible salt values. Building rainbow tables for each one isn't just impractical—it's computationally impossible with current technology.

Salts don't eliminate brute-force attacks entirely, but they force attackers to tackle each password individually instead of cracking hundreds at once.

Salting vs. peppering: What's the difference?

Salting uses unique random values for each password, and those values live in your database alongside the hashes. Everyone can see the salts—they're not secret.

Peppering works differently. It applies a single secret value to all passwords in your system. This pepper typically gets stored separately from the database, maybe in your application code or a hardware security module.

Salt protects against rainbow tables. Pepper adds another layer of difficulty. If attackers steal your password database but can't access the pepper, they'll have trouble validating their cracking attempts.

But peppers also create management headaches. If the pepper gets compromised, your entire password system is at risk. If you need to rotate the pepper, you'll have to rehash every password in your database. Mess up the pepper rotation, and you've just locked every user out of your system.

In summary, salts are mandatory for modern password security, while peppers can strengthen your defenses further, but only if you can handle the key management properly.

Choosing the right hashing algorithm

Not every hashing method is built for password security. In fact, many of the most common algorithms used in software today are completely wrong for protecting passwords. The issue comes down to one simple factor: speed.

Strong hashes vs. weak hashes

Weak hashes include anything built for speed: SHA-256 and SHA-3, for example. On paper, these functions still produce unique outputs, but for password storage, their speed is their weakness.

Modern cracking tools can run SHA-256 at billions of hashes per second. Once a hacker obtains a database of SHA-256 password hashes, they can run through enormous lists of guesses almost instantly, especially if users have chosen weak or common passwords.

In contrast, strong password hashing functions like bcrypt intentionally slow this process to a crawl (a couple of hundred thousand rather than billions of guesses per second). Each guess takes time and resources, turning brute-force attacks into a painfully slow process. This doesn’t make cracking impossible, but it makes mass attacks impractical.

Slow hashing: bcrypt and why speed matters

The entire point of bcrypt, PBKDF2, and Argon2 is to burn attacker time. bcrypt uses its cost factor to control how long each hash takes to compute. For example, a bcrypt cost of 12 might take 200 to 300 milliseconds per hash on a modern server. That delay barely registers when a legitimate user logs in—but for an attacker trying to guess millions of passwords, it adds up fast.

Argon2 goes a step further. It not only burns CPU time but also demands memory, which blocks attackers from using massively parallel GPU clusters. Argon2 is widely considered one of the most advanced hashing algorithms available for modern systems. With its combination of memory hardness and CPU cost, it’s extremely effective at defending against the kind of large-scale cracking attacks that plague faster algorithms.

The bottom line is simple: fast hashes put your users at risk, while slow, adaptive hashes protect them.

Can I reuse passwords if they’re hashed and salted?

Hashing and salting passwords well is essential, but it doesn’t give you a free pass to reuse them. Let’s be clear: salted hashes protect against database-side attacks, but they don’t address the risks that come from using the same password across multiple services.

The myth of safe reuse

Some people think, “If my password is hashed and salted, even if it leaks, no one can reverse it. Therefore, reuse is fine.” That’s a myth. Take this scenario: the same weak password (say, Summer2025!) is hashed and salted on two different sites. Each site stores its own salted hash, so the strings will differ.

But smart attackers don’t need to reverse the hash: they attempt credential stuffing, using one site’s leaked password on others. If people reuse the same password, they’ll get access. So hashing helps on one site, but it doesn’t protect against cross-site reuse.

Another risk: an attacker discovering a plaintext password in a breach could still log in elsewhere—regardless of how it’s stored there. Salted hashes don’t prevent people from using the same password on a banking site that only uses hashing. And because users tend to recycle or slightly vary their passwords, credential stuffing remains one of the most effective attacks today.

Best practices for password hygiene

It doesn’t matter how secure your system is—if your passwords are weak, everything’s at risk. Good password hygiene isn’t just a technical detail or a developer’s job: it’s something everyone needs to get right. The tips below are split into two groups: one for everyday users and one for the IT professionals responsible for keeping systems secure.

For everyday users:

• Always use unique passwords. Reusing a password across multiple services makes it vulnerable, no matter how well one site protects it.
• Use a password manager. Password managers like ExpressVPN Keys generate strong, unique passwords for each account. No one can remember dozens of random strings—leave that to the software.
• Use two-factor authentication (2FA) or multi-factor authentication (MFA). 2FA and MFA block attacks that rely on stolen passwords alone. This adds an extra layer of defense, even if a reused password is compromised.

For developers and IT admins:

• Implement rate limiting and lockouts. Even hashed passwords need protection. Developers should limit failed logins, block repeated attempts quickly, and monitor for credential stuffing behavior.
• Encourage users to choose strong passwords. Prompts, password strength meters, and education for end users can help here.
• Rehash periodically. As hardware advances and hashing standards evolve, systems should periodically rehash existing salted passwords using higher cost factors. That maintains resistance without requiring user password changes.