Secure Password Hashing in PHP: Salts, password_hash(), and Best Practices

By the end of this page, you will understand how passwords should be stored securely in PHP, why MD5 and plain SHA hashes are not suitable, how salts work, why modern password hashing functions are designed to be slow on purpose, and how to use password_hash() and password_verify() correctly in real applications.

What problem are we solving?

When a user creates a password, you should not store the original password in your database. Instead, you store a password hash.

A hash is a one-way transformation:

• You can hash a password and store the result.
• Later, when the user logs in, you hash the entered password again and compare it.
• You should not be able to reverse the hash back into the original password.

Why MD5 and SHA are not enough

Functions like MD5, SHA1, and even SHA256 are fast general-purpose hashing algorithms. That is good for checksums and file integrity, but bad for password storage.

Why bad?

• Attackers can test huge numbers of guesses very quickly.
• Modern GPUs and specialized hardware can crack fast hashes efficiently.
• Precomputed lookup tables and large wordlists make attacks easier.

Password hashing should be slow by design.

What makes a password hash secure?

A secure password storage system should have these properties:

• One-way: the original password is not stored.
• Slow to compute: brute-force attacks become expensive.
• Salted: each password gets its own random salt.
• Upgradeable: you can increase the cost over time.

What is a salt?

A salt is a random value added to a password before hashing.

This means:

Think of password hashing like storing a locked box label instead of the key itself.

• The password is the key.
• The hash is a label created from that key.
• The salt is like adding a unique serial number before making the label.

If two people have the same key, the serial number makes their labels different.

A fast hash like MD5 is like a machine that prints labels instantly. That sounds useful, but it also helps attackers print billions of labels while guessing passwords.

A password hashing algorithm like bcrypt or Argon2 is like a machine intentionally built to work more slowly and carefully. That delay is small for a real login, but expensive for an attacker trying millions of guesses.

Recommended PHP syntax

Hashing a password

<?php
$password = 'MySecureP@ssw0rd!';
$hash = password_hash($password, PASSWORD_DEFAULT);

echo $hash;

Verifying a password

<?php
$enteredPassword = 'MySecureP@ssw0rd!';
$storedHash = '$2y$10$exampleexampleexampleexampleexampleexampleexampleexam';

if (password_verify($enteredPassword, $storedHash)) {
    echo 'Password is correct';
} else {
    echo 'Invalid password';
}

Better example with real flow

Registering a user

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

// Store $hash in the database

Example

<?php
$password = 'cat123';
$hash = password_hash($password, PASSWORD_DEFAULT);

$isValid = password_verify('cat123', $hash);
var_dump($isValid);

What happens step by step

1. The password is defined

$password = 'cat123';

The variable holds the plain-text password.

2. PHP creates a secure password hash

$hash = password_hash($password, PASSWORD_DEFAULT);

PHP does several things internally:

• Chooses the current default password hashing algorithm
• Generates a secure random salt
• Combines the password and salt correctly
• Applies the algorithm with the proper cost settings
• Returns a full hash string containing the metadata needed later

3. The password is checked

 = (, );

User authentication

The most common use case is login systems:

• registration forms
• sign-in pages
• admin dashboards
• membership systems

API and developer portals

If your platform has user accounts for accessing API keys or dashboards, the passwords for those accounts should be stored with password_hash().

Internal business tools

Even small internal apps need proper password storage:

• employee portals
• HR dashboards
• reporting systems
• support tools

Password resets and account migration

During a login, you can verify an old stored hash and rehash it using stronger settings. This is useful when improving security in existing apps.

Multi-tenant SaaS applications

Different users may choose the same password. Salted password hashing prevents them from ending up with identical stored hashes, which reduces information leakage if the database is exposed.

Typical pattern in real projects

Developers usually build password hashing into these layers:

• registration service
• login/authentication service
• user model or repository
• password reset flow

Common patterns

Validation before hashing

<?php
if (strlen($password) < 12) {
    throw new InvalidArgumentException('Password must be at least 12 characters.');
}

$hash = password_hash($password, PASSWORD_DEFAULT);

Passwords should be validated before hashing, not after.

Guard clause for failed login

<?php
if (!$user) {
    return false;
}

if (!password_verify($password, $user['password_hash'])) {
    return false;
}

return true;

This keeps authentication logic simple and readable.

1. Using MD5 or SHA directly for passwords

Broken approach:

<?php
$hash = md5($password);

Or:

<?php
$hash = hash('sha256', $password);

Why it is a problem:

• They are too fast.
• They are not designed for password storage.
• Attackers can brute-force them efficiently.

Use this instead:

<?php
$hash = password_hash($password, PASSWORD_DEFAULT);

2. Making your own salt incorrectly

Broken approach:

<?php
$salt = '12345';
$hash = hash('sha256', $salt . $password);

Problems:

• Salt is predictable.

Password hashing choices in PHP

Best practice

$hash = password_hash($password, PASSWORD_DEFAULT);
$isValid = password_verify($password, $hash);

Rules to remember

• Do not use md5() for passwords.
• Do not use sha1() or sha256 directly for passwords.
• Do not store plain-text passwords.
• Do not build your own salt system unless you truly need to.
• Do use password_hash().
• Do use password_verify().
• Do use password_needs_rehash() over time.
• Do give your database column enough space, such as VARCHAR(255).

Good salt rules

• random
• unique per password
• generated with a secure source
• usually handled automatically by password_hash()

Good database field

password_hash VARCHAR(255)

Should I use MD5 for passwords in PHP?

No. MD5 is too fast and no longer suitable for password storage.

Is SHA-256 safe for password hashing?

Not by itself for password storage. It is a strong general-purpose hash, but it is too fast for defending against brute-force attacks.

Do I need to generate my own salt in PHP?

Usually no. password_hash() generates and stores a secure salt automatically.

Is bcrypt still acceptable in PHP?

Yes. Bcrypt is still a solid choice and is widely supported. Argon2id is also an excellent option when available.

Why are password hashes intentionally slow?

Because slow hashing makes brute-force attacks more expensive while keeping normal login checks practical.

Should I store several hashes of the same password for extra security?

No. That usually weakens security because an attacker can target the easiest hash.

How long should the database column be for a password hash?

A common practical choice is VARCHAR(255) so future algorithm changes are less likely to cause problems.

Is password hashing the same as encryption?

No. Hashing is one-way and is used for password verification. Encryption is two-way and is used when data must be recovered later.

Related concepts

• Hash functions — basic one-way transformations used in many programming tasks.
• Salting — adding unique randomness to each password before hashing.
• bcrypt — a password hashing algorithm designed to be slow and secure.
• Argon2id — a modern password hashing algorithm with strong security properties.
• Authentication — the process of verifying a user's identity.
• Input validation — checking password rules before storing the hash.
• Database schema design — choosing proper column types and lengths for password hashes.
• Timing-safe comparison — important when comparing sensitive values securely.
• Password reset flows — related because resets often trigger password rehashing or replacement.