[#1] jessieschraaff at hotmail dot com [2015-10-02 08:54:09]

For me it didn't work, so I asked my friend and he told me to remove ."/n"

So it worked like this
$password = password_hash($password, PASSWORD_DEFAULT);

[#2] lortet [2015-09-18 08:52:00]

The PASSWORD_BCRYPT duration evolves exponentially based on COST.

Measure picture : https://static.lortet.io/files/php.net.bcrypt_evolves.png
The "constant" depends on your machine (for me is 1).

Method :
<table border="1">
<?php
    for( $cost = 0; $cost <= 10; $cost=$cost+0.1){
        $start = microtime(true);
        password_hash("test".$cost, PASSWORD_BCRYPT, ["cost" => $cost]);
        $end = microtime(true);
        echo '<tr><td>' . $cost . '</td><td>' . ( $end - $start ) . '</td></tr>';
    }
?>
</table>

[#3] VladimirMozhenkov at yahoo dot com [2015-08-26 12:04:31]

Note that this function can return NULL. It does so if you provide an incorrect constant as an algorythm. I had the following:

$password = password_hash($password1, PASSWORD_BDCRYPT, array( 'cost' => 10 ));

and i couldn't understand why i kept having NULL written in $password; it was a simple fact that the constant was PASSWORD_BCRYPT.

[#4] Mike Robinson [2014-08-28 02:52:29]

For passwords, you generally want the hash calculation time to be between 250 and 500 ms (maybe more for administrator accounts). Since calculation time is dependent on the capabilities of the server, using the same cost parameter on two different servers may result in vastly different execution times. Here's a quick little function that will help you determine what cost parameter you should be using for your server to make sure you are within this range (note, I am providing a salt to eliminate any latency caused by creating a pseudorandom salt, but this should not be done when hashing passwords):

<?php

function getOptimalBcryptCostParameter($min_ms = 250) {
    for ($i = 4; $i < 31; $i++) {
        $options = [ 'cost' => $i, 'salt' => 'usesomesillystringforsalt' ];
        $time_start = microtime(true);
        password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
        $time_end = microtime(true);
        if (($time_end - $time_start) * 1000 > $min_ms) {
            return $i;
        }
    }
}
echo getOptimalBcryptCostParameter(); // prints 12 in my case
?>

[#5] cottton [2014-02-17 16:29:54]

if you thought
"why is the salt included in the hash and is it save when i store it as it is in my db?"

Answer i found:
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.

[#6] Cloxy [2013-10-18 09:45:31]

You can produce the same hash in php 5.3.7+ with crypt() function:

<?php

$salt = mcrypt_create_iv(22, MCRYPT_DEV_URANDOM);
$salt = base64_encode($salt);
$salt = str_replace('+', '.', $salt);
$hash = crypt('rasmuslerdorf', '$2y$10$'.$salt.'$');

echo $hash;

?>

[#7] nicoSWD [2013-10-06 03:29:34]

I agree with martinstoeckli,

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.

[#8] chris at acsdi dot com [2013-06-21 16:29:03]

Alan is entirely wrong, please ignore his comment and/or vote it down. This method encodes the algorithm and other parameters into the returned hash.

Deliberately specifying the algorithm to use should only be done in a carefully considered scenario, and these functions are designed and policies have been decided to ensure wide compatibility.

The risk of forcing a particular algorithm is that your code will continue to use a weaker algorithm as newer ones are implemented and strengthened.

[#9] martinstoeckli [2013-03-08 22:36:28]

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.

[#10] martinstoeckli [2012-12-17 20:56:40]

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