password_hash() creates a new password hash using a strong one-way hashing algorithm. password_hash() is compatible with crypt(). Therefore, password hashes created by crypt() can be used with password_hash().
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.
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.
The salt option has been deprecated as of PHP 7.0.0. It is now preferred to simply use the salt that is generated by default.
cost (integer) - 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 10 will be used. This is a good baseline cost, but you may want to consider increasing it depending on your hardware.
memory_cost (integer) - Maximum memory (in kibibytes) that may be used to compute the Argon2 hash. Defaults to PASSWORD_ARGON2_DEFAULT_MEMORY_COST.
time_cost (integer) - Maximum amount of time it may take to compute the Argon2 hash. Defaults to PASSWORD_ARGON2_DEFAULT_TIME_COST.
threads (integer) - Number of threads to use for computing the Argon2 hash. Defaults to PASSWORD_ARGON2_DEFAULT_THREADS.
Using the PASSWORD_BCRYPT as the algorithm, will result in the password parameter being truncated to a maximum length of 72 characters.
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.
Returns the hashed password, or FALSE on failure.
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.
* We just want to hash our password using the current DEFAULT algorithm.
* This is presently BCRYPT, and will produce a 60 character result.
* 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.
* which is a good baseline for systems handling interactive logins.
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.
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.
7.3.0 Support for Argon2id passwords using PASSWORD_ARGON2ID was added.
7.2.0 Support for Argon2i passwords using PASSWORD_ARGON2I was added.
don't create your own salts unless you really know what you're doing.
By default, it'll use /dev/urandom to create the salt, which is based on noise from device drivers.
And on Windows, it uses CryptGenRandom().
Both have been around for many years, and are considered secure for cryptography (the former probably more than the latter, though).
Don't try to outsmart these defaults by creating something less secure. Anything that is based on rand(), mt_rand(), uniqid(), or variations of these is *not* good.
Please, its important that you take note of the documentation as regards the length of the password character on the database. Using password_verify to resolve a password that is hashed using the password_hash function, when the password is set to 50, it might show some malfunctioning. As the documentation shows, the lenght can change. So, to be on the safer side, set the length to 255.
Please note that password_hash will ***truncate*** the password at the first NULL-byte.
If you use anything as an input that can generate NULL bytes (sha1 with raw as true, or if NULL bytes can naturally end up in people's passwords), you may make your application much less secure than what you might be expecting.
is zero bytes long (an empty password) for bcrypt.
The workaround, of course, is to make sure you don't ever pass NULL-bytes to password_hash.
In most cases it is best to omit the salt parameter. Without this parameter, the function will generate a cryptographically safe salt, from the random source of the operating system.
and i couldn't understand why i kept having NULL written in $password; it was a simple fact that the constant was PASSWORD_BCRYPT.
"why is the salt included in the hash and is it save when i store it as it is in my db?"
The salt just has to be unique. It not meant to be a secret.
As mentioned in notes and docu before: let password_hash() take care of the salt.
With the unique salt you force the attacker to crack the hash.
The hash is unique and cannot be found at rainbow tables.
Pay close attention to the maximum allowed length of the password parameter! If you exceed the maximum length, it will be truncated without warning.
If you prepend your own salt/pepper to the password, and that salt/pepper exceeds the maximum length, then this function will truncate the actual password. That means password_verify() will return true with ANY password using the same salt/pepper.
It might be a good idea to append any salt/pepper to the end of the password instead.
Cost Will Be 10 Which Is Secure And Fast Enough.
Note: 1 and 2 for cost are invalid.
For an average site the default of 10 is probably a sane enough value.