Why Strong Passwords Dont Save You

You’ve got a killer password? Doesn’t matter if the company storing it screws up.

We’re told over and over: make it long, make it complex, make it uncrackable. And yes, weak passwords are a security nightmare. But here’s the thing: even the strongest password on your end can be useless if the system storing it is careless.

That’s the part nobody tells you.
You can spend hours perfecting your digital vault key – but if the vault itself has holes, your 15-character long password won’t be able to save you.

This is the real contrast: your effort vs their responsibility. You handle your side, but if they botch theirs, it’s game over.

That’s what we’re unpacking today.
The side of password security most people never see.

In this piece, I’ll be break down the following:

• How passwords are really stored
• Why some methods are laughably insecure
• Why key stretching is the real game changer

By the end, you’ll know exactly why your effort alone isn’t enough and you will unlock the forbidden sight… a sight to see through B.S

So, let’s dive in.

How Passwords Are Stored

You’ve heard the lectures: use a strong password, throw in a capital letter. But does it really matter?

You might’ve heard scary terms tossed around – plaintext, hashes, encryptions… That is why it’s better to first understand the basics of how passwords reside inside databases. Then we can pivot towards more advanced topics.

Plaintext – The Nightmare Storage

Plaintexts are by far the worst way to store passwords: saved exactly as you typed them, no scrambling, no protection.

If a hacker gets access, they get everything. Your password appears as simple text, it’s a hacker’s jackpot, especially since many users reuse the same password across services. They literally won’t need to use any computation power.

It’s a full win in one file – credentials displayed like a grocery list.

And here’s the worst part, even today, plaintext storage isn’t extinct. Big names have been caught using it:

• In 2019, Meta was fined $101 million by European regulators for storing hundreds of millions of user passwords in plaintext.
• In 2024, the Firebase incident exposed over 19 million plaintext passwords due to poor security rules.

Hashes – Better, But Not Bulletproof

When companies grew tired of the “oops, plaintext leak” embarrassment, they turned to hashing.

A hash is basically a one-way math function: you put in a password, and it spits out a scrambled string that looks nothing like the original. In theory, you can’t reverse it back. So if a database leaks, attackers only see gibberish.

But that doesn’t mean hashing is bulletproof – Weak hashes (like MD5 or SHA-1) are cracked in seconds with today’s GPUs. What took years back in the 90s now takes minutes on a powerful PC.

And here’s where it gets worse:
Say hello to Rainbow tables – Rainbow tables make guessing even faster. These tables are basically pre-computed tables for caching the outputs of a cryptographic hash function. Think of it like a hacker walking in with an already-built cheat sheet.

Even stronger raw hashing isn’t enough on its own. With billions of guesses per second possible, an attacker can brute-force through shorter or common passwords without breaking a sweat.

So, yes – hashing is a step up from plaintext, but relying on weak or unsalted hashes is like locking your front door with a toy padlock.

Enter the Hacker’s POV

Now that you know the basics, flip the script. Imagine you’re the attacker staring at a fresh password dump. What’s your reaction?

If the company stored passwords in plaintext or with weak hashes, you’re probably going to be grinning. It’s going to be effortless – crack them all, resell on the darknet, maybe even reuse them across other accounts. Easy money, no sweat.

But what if the passwords are stored the right way?
Suddenly, everything is going to turn into a nightmare.

Your GPU gets overloaded for days, rainbow tables are useless, and every second feels like wasted effort. That’s when you decide that you need to move on.

So the real question is – what makes passwords “the right way” secure?

Salts – Breaking the Copy-Paste Attack

Talk about securing passwords – Enter salts

A salt is just a random string of data that gets added to your password before it’s hashed. It’s a simple idea, but it has a big impact.

Why does this matter?

Because without salts, two people using the same password will produce the exact same hash. That’s a jackpot for attackers – it tells them which accounts share the same weak password, and with the use of rainbow tables – they can crack these passwords in bulk.

But… with salts – the game flips. Every password hash becomes unique, even if 100 people use “password123,” the stored results all look completely different. That randomness kills off rainbow tables and blocks the copy-paste attack strategy hackers love.

And here’s the thing – Salting doesn’t make passwords uncrackable, but it forces attackers to start from scratch every single time. And in security, making the attacker’s life harder is the whole game.

Key Stretching – The Game Changer

If salts make life harder for attackers, key stretching is what makes it painful. This is the real game changer in password security.

So here’s the deal: at its core, key stretching takes your password and deliberately makes the hashing process slower and heavier. Why? Because what’s cheap and instant for you becomes insanely expensive for an attacker trying to crack millions of passwords at once.

Before we go into the details of how it works (PBKDF2, bcrypt, Argon2 – yeah, the serious stuff), let’s lay down the basics.

What Key Stretching Really Is (and How It Works)

At its core, key stretching is about time. Instead of hashing a password once and calling it a day, the system makes the computer do that hashing again and again – thousands, even millions of times.

Why all the fuss?
Because that tiny delay (barely noticeable to you when logging in) turns into a nightmare for an attacker trying to brute-force millions of passwords at scale.

What’s “instant” for you becomes “impossible” for them.

Here’s what the process looks like:

1.  Initial Hashing: Your password is hashed once, like normal

2.  IterativeHashing: Instead of stopping there, the system takes that hash and runs it through the process many times. Thousands of rounds.

3. Final Output: After all those rounds, the final hash is stored in the database. That’s the version an attacker would have to crack – and good luck with that.

The good thing about key stretching is that – Even if an attacker has powerful GPUs and rainbow tables. Key stretching slows them down by a great deal.

Why Key Stretching Matters More Than the Password

There is a catch most people don’t realize – The storage method matters more than your password strength.

Think about it. A raw hash might take just 0.001 seconds to compute. For a hacker with GPUs, that’s billions of guesses per second. Easy money.

Now add key stretching with 100,000 iterations. Suddenly, that same single guess takes 100 seconds. Multiply that across millions of guesses, and the math gets brutal. What was once hours becomes days, weeks, even months of grinding.

And here’s the paradox that flips the script:
A weak password with proper stretching can outlast a strong password stored with weak hashing.

That’s the part most people never hear.
It’s not just about how clever your password is.
It’s about whether the system behind it is designed to protect you or expose you.

The Players: Common Algorithms

Before you can decide which algorithm is “the best,” you need to know who’s even in the game. Each one has its quirks, strengths, and weak spots.

So let’s break them down – one by one. Once you see how they work, you’ll understand why some belong in the past… and why others are the real defenders of your passwords.

PBKDF2

PBKDF2 stands for Password-Based Key Derivation Function 2. It’s one of the earliest and most widely used methods for securing passwords. Think of it as an old but reliable lock – it does the job, but it wasn’t built for today’s power tools (aka modern cracking rigs).

How it works

• You take a password and mix it with a random salt.
• Instead of hashing it once, PBKDF2 hashes it many times.
• if one guess takes longer, millions of guesses take a lot longer.

Where it shines

• It’s flexible: you can choose the number of iterations it will perform which results in making cracking slower.
• It’s still widely supported, easy to implement, and recommended if nothing stronger is available.
• Security groups like OWASP still list it as acceptable if very high iteration counts are used.

Where It Falls Short

• It doesn’t use much memory, which makes it easy for attackers to run it in parallel on GPUs and specialized hardware.
• To stay secure, you need iteration counts in the hundreds of thousands, and that is something many companies skip because of performance costs.
• It’s old – newer algorithms are better built for today’s attack landscape.

Final Take

PBKDF2 is like a veteran soldier – battle-tested, dependable, but outclassed by newer weapons. If a system is using it with very high iteration counts, it can still hold up. But if the counts are too low, attackers will slice through it with modern hardware.

bcrypt

bcrypt is a password hashing function created in 1999. It was designed specifically to secure passwords (unlike some older algorithms like MD5 that were repurposed). It’s known for being tough on CPUs and has earned a reputation as the “battle-tested” choice.

How it works

• Takes your password and a salt.
• Runs it through a deliberately slow hashing process.
• Instead of “iterations” like PBKDF2, bcrypt has a cost factor (a setting that decides how much work the algorithm should do). Higher cost = slower hashing.
• The result is a unique hash that attackers have to brute-force slowly.

Where it shines

• Proven track record: it’s been around for decades and still holds strong when properly configured.
• Easy to adjust the cost factor, so it can be tuned to stay ahead of faster computers.
• It also makes rainbow tables useless since salts are baked in.

Where it falls short

• Doesn’t fully take advantage of memory-hard defenses (attackers with GPUs or ASICs still have an edge).
• Has a password length limit (usually 72 characters), which can be a bit of disappointment if you rely on long passphrases.
• While still solid, it’s not as modern as newer options like or