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 bytes (255 bytes would be a good choice).
PASSWORD_BCRYPT - Use the bcrypt algorithm to
create the hash. This will produce a standard crypt() compatible hash using
the $2y$ identifier.
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.
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.
cost (int) - which denotes the algorithmic cost that should be used.
Examples of these values can be found on the crypt() page.
If omitted, a default value of 12 will be used. This is a good
baseline cost, but it should be adjusted depending on hardware used.
An associative array containing options. See the password algorithm constants for documentation on the supported options for each algorithm.
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.4.0
The default value of the cost option of the
PASSWORD_BCRYPT algorithm was increased from
10 to 12.
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
ints for backward compatibility.
7.4.0
The sodium extension provides an alternative implementation for Argon2 passwords.
Example #3 password_hash() example finding a good cost
This code will benchmark the machine to determine how high of a cost can be used
without deteriorating user experience. It is recommended to set the highest cost
that does not slow down other operations the machine needs to perform. 11 is a
good baseline, and more is better if the machine is fast enough. The code below
aims for ≤ 350 milliseconds stretching time, which is an appropriate delay for
systems handling interactive logins.
It is strongly recommended not to provide an explicit salt for this function.
A secure salt will automatically be created if no salt is specified.
As noted above, providing the salt option in PHP 7.0.0
will generate a deprecation warning. Support for providing a salt explicitly
has been removed in PHP 8.0.0.
Note:
It is recommended to test this function on the machine used, adjusting the cost parameter(s)
so that execution of the function takes less than 350 milliseconds for interactive logins.
The script in the above example will help choosing an appropriate bcrypt cost for the given
machine.
Note:
Updates to supported algorithms by this function (or changes to the default one) must follow
the following rules:
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.