Store a deliberately slow, salted, one-way password hash instead of a password or a fast SHA digest.
The examples introduce the underlying control before showing a verification and an application-level safeguard.
What You Will Build
Store a deliberately slow, salted, one-way password hash instead of a password or a fast SHA digest.
Prerequisites
Use PHP 8.4 or newer, HTTPS for all authentication operations, and an application session or database where required. Example configuration values are placeholders, never production secrets.
Example 1: Basic Operation
Create a salted password hash and check a login candidate.
<?php
$hash = password_hash('example-password', PASSWORD_DEFAULT);
var_dump(password_verify('example-password', $hash));
Example 2: A Different Use Case
Upgrade stored password hashes after successfully verifying a login.
<?php
$hash = password_hash('example-password', PASSWORD_BCRYPT, ['cost' => 11]);
if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
$hash = password_hash('example-password', PASSWORD_DEFAULT);
}
var_dump(password_verify('example-password', $hash));
Practical Example: Checking the Result
Handle failure without exposing whether a stored hash exists.
<?php
$stored = password_hash('sample-passphrase', PASSWORD_DEFAULT);
$candidate = 'incorrect';
if (!password_verify($candidate, $stored)) {
echo 'Credentials not accepted';
}
Important Behavior and Edge Cases
For login, compare the plaintext candidate with password_verify; never hash the candidate again and compare the two resulting hashes.
Enforce controls on the server, test denial paths and do not assume that a snippet alone implements an entire production workflow.
Comparison with Related Functions
| Approach | Key distinction |
|---|---|
| Hashing Passwords with password_hash() | Store a deliberately slow, salted, one-way password hash instead of a password or a fast SHA digest. |
| Related technique | password_hash and password_verify handle the algorithm metadata and salt automatically. |
Common Beginner Mistakes
| Mistake | Correct approach |
|---|---|
| Confusing this operation with a neighboring cryptographic or security mechanism | password_hash and password_verify handle the algorithm metadata and salt automatically. |
| Ignoring a security prerequisite or failure case | For login, compare the plaintext candidate with password_verify; never hash the candidate again and compare the two resulting hashes. |
Key Takeaways
- Store a deliberately slow, salted, one-way password hash instead of a password or a fast SHA digest.
- For login, compare the plaintext candidate with password_verify; never hash the candidate again and compare the two resulting hashes.
- password_hash and password_verify handle the algorithm metadata and salt automatically.
Apply this behavior to a real application only after confirming the required extension, configuration and failure handling on the deployment runtime.