password_hash
password_hash() creates a new password hash using a strong one-way hashing algorithm.
The following algorithms are currently supported:
- PASSWORD_DEFAULT — Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP. For that reason, the length of the result from using this identifier can change over time. Therefore, it is recommended to store the result in a database column that can expand beyond 60 characters (255 characters would be a good choice).
- PASSWORD_BCRYPT — Use the CRYPT_BLOWFISH algorithm to create the hash. This will produce a standard crypt() compatible hash using the «$2y$» identifier. The result will always be a 60 character string, or false on failure.
- PASSWORD_ARGON2I — Use the Argon2i hashing algorithm to create the hash. This algorithm is only available if PHP has been compiled with Argon2 support.
- PASSWORD_ARGON2ID — Use the Argon2id hashing algorithm to create the hash. This algorithm is only available if PHP has been compiled with Argon2 support.
Supported options for PASSWORD_BCRYPT :
- salt ( string ) — to manually provide a salt to use when hashing the password. Note that this will override and prevent a salt from being automatically generated. If omitted, a random salt will be generated by password_hash() for each password hashed. This is the intended mode of operation.
Warning The salt option is deprecated. It is now preferred to simply use the salt that is generated by default. As of PHP 8.0.0, an explicitly given salt is ignored.
Supported options for PASSWORD_ARGON2I and PASSWORD_ARGON2ID :
- memory_cost ( int ) — Maximum memory (in kibibytes) that may be used to compute the Argon2 hash. Defaults to PASSWORD_ARGON2_DEFAULT_MEMORY_COST .
- time_cost ( int ) — Maximum amount of time it may take to compute the Argon2 hash. Defaults to PASSWORD_ARGON2_DEFAULT_TIME_COST .
- threads ( int ) — Number of threads to use for computing the Argon2 hash. Defaults to PASSWORD_ARGON2_DEFAULT_THREADS .
Parameters
Using the PASSWORD_BCRYPT as the algorithm, will result in the password parameter being truncated to a maximum length of 72 bytes.
A password algorithm constant denoting the algorithm to use when hashing the password.
An associative array containing options. See the password algorithm constants for documentation on the supported options for each algorithm.
If omitted, a random salt will be created and the default cost will be used.
Return Values
Returns the hashed password.
The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that’s needed to verify the hash is included in it. This allows the password_verify() function to verify the hash without needing separate storage for the salt or algorithm information.
Changelog
| Version | Description |
|---|---|
| 8.0.0 | password_hash() no longer returns false on failure, instead a ValueError will be thrown if the password hashing algorithm is not valid, or an Error if the password hashing failed for an unknown error. |
| 8.0.0 | The algo parameter is nullable now. |
| 7.4.0 | The algo parameter expects a string now, but still accepts int s for backward compatibility. |
| 7.4.0 | The sodium extension provides an alternative implementation for Argon2 passwords. |
| 7.3.0 | Support for Argon2id passwords using PASSWORD_ARGON2ID was added. |
| 7.2.0 | Support for Argon2i passwords using PASSWORD_ARGON2I was added. |
Examples
Example #1 password_hash() example
/**
* We just want to hash our password using the current DEFAULT algorithm.
* This is presently BCRYPT, and will produce a 60 character result.
*
* Beware that DEFAULT may change over time, so you would want to prepare
* By allowing your storage to expand past 60 characters (255 would be good)
*/
echo password_hash ( «rasmuslerdorf» , PASSWORD_DEFAULT );
?>
The above example will output something similar to:
$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a
Example #2 password_hash() example setting cost manually
/**
* In this case, we want to increase the default cost for BCRYPT to 12.
* Note that we also switched to BCRYPT, which will always be 60 characters.
*/
$options = [
‘cost’ => 12 ,
];
echo password_hash ( «rasmuslerdorf» , PASSWORD_BCRYPT , $options );
?>
The above example will output something similar to:
$2y$12$QjSH496pcT5CEbzjD/vtVeH03tfHKFy36d4J0Ltp3lRtee9HDxY3K
Example #3 password_hash() example finding a good cost
/**
* This code will benchmark your server to determine how high of a cost you can
* afford. You want to set the highest cost that you can without slowing down
* you server too much. 8-10 is a good baseline, and more is good if your servers
* are fast enough. The code below aims for ≤ 50 milliseconds stretching time,
* which is a good baseline for systems handling interactive logins.
*/
$timeTarget = 0.05 ; // 50 milliseconds
$cost = 8 ;
do $cost ++;
$start = microtime ( true );
password_hash ( «test» , PASSWORD_BCRYPT , [ «cost» => $cost ]);
$end = microtime ( true );
> while (( $end — $start ) < $timeTarget );
echo «Appropriate Cost Found: » . $cost ;
?>
The above example will output something similar to:
Appropriate Cost Found: 10
Example #4 password_hash() example using Argon2i
The above example will output something similar to:
Argon2i hash: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0
Notes
It is strongly recommended that you do not generate your own salt for this function. It will create a secure salt automatically for you if you do not specify one.
As noted above, providing the salt option in PHP 7.0 will generate a deprecation warning. Support for providing a salt manually may be removed in a future PHP release.
Note:
It is recommended that you test this function on your servers, and adjust the cost parameter so that execution of the function takes less than 100 milliseconds on interactive systems. The script in the above example will help you choose a good cost value for your hardware.
- Any new algorithm must be in core for at least 1 full release of PHP prior to becoming default. So if, for example, a new algorithm is added in 7.5.5, it would not be eligible for default until 7.7 (since 7.6 would be the first full release). But if a different algorithm was added in 7.6.0, it would also be eligible for default at 7.7.0.
- The default should only change in a full release (7.3.0, 8.0.0, etc) and not in a revision release. The only exception to this is in an emergency when a critical security flaw is found in the current default.
See Also
- password_verify() — Verifies that a password matches a hash
- password_needs_rehash() — Checks if the given hash matches the given options
- crypt() — One-way string hashing
- sodium_crypto_pwhash_str() — Get an ASCII-encoded hash
User Contributed Notes 9 notes
There is a compatibility pack available for PHP versions 5.3.7 and later, so you don’t have to wait on version 5.5 for using this function. It comes in form of a single php file:
https://github.com/ircmaxell/password_compat
Since 2017, NIST recommends using a secret input when hashing memorized secrets such as passwords. By mixing in a secret input (commonly called a «pepper»), one prevents an attacker from brute-forcing the password hashes altogether, even if they have the hash and salt. For example, an SQL injection typically affects only the database, not files on disk, so a pepper stored in a config file would still be out of reach for the attacker. A pepper must be randomly generated once and can be the same for all users. Many password leaks could have been made completely useless if site owners had done this.
Since there is no pepper parameter for password_hash (even though Argon2 has a «secret» parameter, PHP does not allow to set it), the correct way to mix in a pepper is to use hash_hmac(). The «add note» rules of php.net say I can’t link external sites, so I can’t back any of this up with a link to NIST, Wikipedia, posts from the security stackexchange site that explain the reasoning, or anything. You’ll have to verify this manually. The code:
// register.php
$pepper = getConfigVariable ( «pepper» );
$pwd = $_POST [ ‘password’ ];
$pwd_peppered = hash_hmac ( «sha256» , $pwd , $pepper );
$pwd_hashed = password_hash ( $pwd_peppered , PASSWORD_ARGON2ID );
add_user_to_database ( $username , $pwd_hashed );
?>
// login.php
$pepper = getConfigVariable ( «pepper» );
$pwd = $_POST [ ‘password’ ];
$pwd_peppered = hash_hmac ( «sha256» , $pwd , $pepper );
$pwd_hashed = get_pwd_from_db ( $username );
if ( password_verify ( $pwd_peppered , $pwd_hashed )) echo «Password matches.» ;
>
else echo «Password incorrect.» ;
>
?>
Note that this code contains a timing attack that leaks whether the username exists. But my note was over the length limit so I had to cut this paragraph out.
Also note that the pepper is useless if leaked or if it can be cracked. Consider how it might be exposed, for example different methods of passing it to a docker container. Against cracking, use a long randomly generated value (like in the example above), and change the pepper when you do a new install with a clean user database. Changing the pepper for an existing database is the same as changing other hashing parameters: you can either wrap the old value in a new one and layer the hashing (more complex), you compute the new password hash whenever someone logs in (leaving old users at risk, so this might be okay depending on what the reason is that you’re upgrading).
Why does this work? Because an attacker does the following after stealing the database:
password_verify(«a», $stolen_hash)
password_verify(«b», $stolen_hash)
.
password_verify(«z», $stolen_hash)
password_verify(«aa», $stolen_hash)
etc.
(More realistically, they use a cracking dictionary, but in principle, the way to crack a password hash is by guessing. That’s why we use special algorithms: they are slower, so each verify() operation will be slower, so they can try much fewer passwords per hour of cracking.)
Now what if you used that pepper? Now they need to do this:
password_verify(hmac_sha256(«a», $secret), $stolen_hash)
Without that $secret (the pepper), they can’t do this computation. They would have to do:
password_verify(hmac_sha256(«a», «a»), $stolen_hash)
password_verify(hmac_sha256(«a», «b»), $stolen_hash)
.
etc., until they found the correct pepper.
If your pepper contains 128 bits of entropy, and so long as hmac-sha256 remains secure (even MD5 is technically secure for use in hmac: only its collision resistance is broken, but of course nobody would use MD5 because more and more flaws are found), this would take more energy than the sun outputs. In other words, it’s currently impossible to crack a pepper that strong, even given a known password and salt.