Introduction

If you recently started using password_hash() in PHP, you probably noticed something strange.

You hash the same password again and again — and every time the result is different.

For example, the password:

AsaamBarpeta123@

Generates different hashes:

$2y$10$ab3K9f....
$2y$10$Qp7Lm1....
$2y$10$Zt5Rk2....

At first, this looks like an error.

But actually… this is the main security feature.

In this article, you will clearly understand:

  • Why hashes change every time

  • How login still works

  • What salt means

  • How hackers steal passwords

  • Why plain password storage is dangerous

  • How to properly implement PHP login security

This guide is written for developers who want real-world security — not just theory.



What Is Password Hashing?

Password hashing means:

Converting a password into an irreversible encrypted string.

You can verify it — but never get the original password back.

Example:

Password → Hash
hello123 → $2y$10$kP7sd82jskd82Kjsd...

Unlike encryption, hashing cannot be decoded.

So even the website owner cannot see the user's password.

Why Hash Changes Every Time (The Salt Concept)

Modern PHP uses bcrypt hashing by default.

bcrypt automatically adds a random value called:

SALT

Salt = random secret added to password before hashing

So internally PHP does:

hash(password + random_salt)

Each time salt is different → hash becomes different.

Example

Password:

AsaamBarpeta123@

Internal working:

AsaamBarpeta123@ + 8392ks
AsaamBarpeta123@ + 2Ksk1P
AsaamBarpeta123@ + 9xT21z

Different input → different output hash.

This is intentional security.

Then How Login Works?

Good question.

Because login does NOT compare hash to hash.

It uses:

password_verify()

This function reads salt from stored hash automatically.

Login Process

  1. User enters password

  2. PHP extracts salt from DB hash

  3. Recalculates hash using same salt

  4. Compares result

If match → login success

Example PHP Login Code

$input_pass = $_POST['password'];
$db_pass = $row['password'];

if(password_verify($input_pass, $db_pass)){
    echo "Login success";
}else{
    echo "Wrong password";
}

No manual comparison required.

Why Plain Password Storage Is Dangerous

Many small websites still store passwords like:

password = 123456

If database leaks:

All users hacked instantly.

Hackers try same password on:

  • Gmail

  • Facebook

  • Bank accounts

  • UPI apps

This is called:

Credential Stuffing Attack

Real Life Data Breaches

Millions of accounts leaked because of plain password storage:

  • Old forums

  • Small recharge portals

  • Weak admin panels

  • Cheap hosting websites

Most users reuse passwords.

So 1 leak = total compromise.

Why Hashing Stops Hackers

When hashed:

Database shows:

$2y$10$8Jd92KslP0skd9sKJd9s...

Even hackers cannot reverse it.

They must brute-force each password individually — extremely slow.

With bcrypt cost factor:

1 password crack = hours or days

So large database = practically useless.

Correct Way to Store Passwords

Register / Change Password

$password = $_POST['password'];
$hash = password_hash($password, PASSWORD_DEFAULT);

mysqli_query($db,"UPDATE users SET password='$hash' WHERE id=1");

Login

if(password_verify($_POST['password'],$row['password'])){
    echo "Login OK";
}

That’s all.

No manual encryption needed.

Important Security Rules

Never do:

md5(password)
sha1(password)
base64(password)

These are outdated and crackable.

Only use:

password_hash()
password_verify()

Migrating Old Websites

If your site already stores plain passwords:

You can upgrade without breaking login.

During login:

  1. Check plain match

  2. Convert to hash

  3. Save hash

After few days all users become secure automatically.

Why Hash Changes Is Actually Good

Many developers panic seeing different hash values.

But think:

If hash stayed same → hackers could pre-calculate password tables.

Called:

Rainbow Table Attack

Salt completely destroys rainbow tables.

So every user password becomes unique.

Performance Impact

bcrypt is intentionally slow.

Why?

Because computers get faster every year.

A slow hash today prevents future attacks.

Login takes milliseconds for user
but hours for hacker

Perfect balance.

Best Practices (2026 Standard)

Always follow:

  • Never store plain passwords

  • Never email passwords

  • Never show passwords in admin panel

  • Always hash before storing

  • Always verify using password_verify

Optional:

  • Force strong password length

  • Add login attempt limit

  • Use HTTPS

Final Conclusion

If your password hash changes every time —
your system is secure

If your hash stays same —
your system is vulnerable

So don’t try to make hashes identical.

That difference is the protection.

Modern authentication works on verification, not equality.

Once you understand this, PHP authentication becomes simple and safe.

Quick Summary

QuestionAnswer
Why hash changesRandom salt
Login still workspassword_verify
Can decode hashNo
Safe to storeYes
Recommendedbcrypt (default)

Now your PHP login system is production-level secure 🔐