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
(PHP 5 >= 5.5.0, PHP 7, PHP 8)
password_hash — 创建密码的散列（hash）
$password, string|int|null $algo, array $options = []): stringpassword_hash() 使用足够强度的单向散列算法创建密码的散列（hash）。
当前支持的算法：
PASSWORD_DEFAULT - 使用 bcrypt 算法 (PHP 5.5.0 默认)。
注意，该常量会随着 PHP 加入更新更高强度的算法而改变。
所以，使用此常量生成结果的长度将在未来有变化。
因此，数据库里储存结果的列可超过60个字符（最好是255个字符）。
PASSWORD_BCRYPT - 使用 CRYPT_BLOWFISH 算法创建散列。
这会产生兼容使用 "$2y$" 的 crypt()。
结果将会是 60 个字符的字符串， 或者在失败时返回 false。
PASSWORD_ARGON2I - 使用 Argon2i 散列算法创建散列。
只有在 PHP 编译时加入 Argon2 支持时才能使用该算法。
PASSWORD_ARGON2ID - 使用 Argon2id 散列算法创建散列。
只有在 PHP 编译时加入 Argon2 支持时才能使用该算法。
PASSWORD_BCRYPT 支持的选项：
salt(string) - 手动提供散列密码的盐值（salt）。这将避免自动生成盐值（salt）。
省略此值后，password_hash() 会为每个密码散列自动生成随机的盐值。这种操作是有意的模式。
盐值（salt）选项已废弃（deprecated）。 现在最好仅选择使用默认产生的盐值。 从 PHP 8.0.0 起，明确指定的 salt 值会被忽略。
cost (int) - 代表算法使用的 cost。crypt() 页面上有 cost 值的示例。
省略时，默认值是 10。
这个 cost 是个不错的底线，但也许可以根据自己硬件的情况，加大这个值。
PASSWORD_ARGON2I 和 PASSWORD_ARGON2ID 支持的选项：
memory_cost (int) - 计算 Argon2 散列时的最大内存（单位：KB）。默认值： PASSWORD_ARGON2_DEFAULT_MEMORY_COST。
time_cost (int) - 计算 Argon2 散列时最多的时间。默认值： PASSWORD_ARGON2_DEFAULT_TIME_COST。
threads (int) - 计算 Argon2 散列时最多的线程数。默认值： PASSWORD_ARGON2_DEFAULT_THREADS。
只有在 PHP 使用 libargon2 时可用；如果是 libsodium 的实现，则无法使用。
返回散列后的密码。
使用的算法、cost 和盐值作为散列的一部分返回。所以验证散列值的所有信息都已经包含在内。 这使 password_verify() 函数验证的时候，不需要额外储存盐值或者算法的信息。
| 版本 | 说明 |
|---|---|
| 8.0.0 |
失败时 password_hash() 不再返回 false，如果密码散列算法无效，则会抛出
ValueError，如果密码散列因未知错误失败，则会抛出 Error。
|
| 8.0.0 |
参数 algo 可以为 null。
|
| 7.4.0 |
现在 algo 参数可支持 string 类型，但为了向后兼容也支持
int 类型。
|
| 7.4.0 | 扩展 sodium 提供了 Argon2 密码的替代实现。 |
| 7.3.0 |
增加 PASSWORD_ARGON2ID，支持 Argon2id 密码算法。
|
| 7.2.0 |
增加 PASSWORD_ARGON2I，支持 Argon2i 密码算法。
|
示例 #1 password_hash() 示例
<?php
/**
* 我们想要使用默认算法散列密码
* 当前是 BCRYPT，并会产生 60 个字符的结果。
*
* 请注意，随时间推移，默认算法可能会有变化，
* 所以需要储存的空间能够超过 60 字（255字不错）
*/
echo password_hash("rasmuslerdorf", PASSWORD_DEFAULT);
?>以上示例的输出类似于：
$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a
示例 #2 password_hash() 手动设置 cost 的示例
<?php
/**
* 在这个案例里，我们为 BCRYPT 增加 cost 到 12。
* 注意，我们已经切换到了，将始终产生 60 个字符。
*/
$options = [
'cost' => 12,
];
echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
?>以上示例的输出类似于：
$2y$12$QjSH496pcT5CEbzjD/vtVeH03tfHKFy36d4J0Ltp3lRtee9HDxY3K
示例 #3 寻找最佳 cost 的 password_hash() 示例
<?php
/**
* 这个示例对服务器做了基准测试（benchmark），检测服务器能承受多高的 cost
* 在不明显拖慢服务器的情况下可以设置最高的值
* 10 是个不错的底线，在服务器够快的情况下，越高越好。
* 以下代码目标为 ≤ 350 毫秒（milliseconds），
* 对于处理交互式登录的系统来说，这是一个合适的延迟时间。
*/
$timeTarget = 0.350; // 350 毫秒（milliseconds）
$cost = 10;
do {
$cost++;
$start = microtime(true);
password_hash("test", PASSWORD_BCRYPT, ["cost" => $cost]);
$end = microtime(true);
} while (($end - $start) < $timeTarget);
echo "Appropriate Cost Found: " . $cost;
?>以上示例的输出类似于：
Appropriate Cost Found: 12
示例 #4 使用 Argon2i 的 password_hash() 示例
<?php
echo 'Argon2i hash: ' . password_hash('rasmuslerdorf', PASSWORD_ARGON2I);
?>以上示例的输出类似于：
Argon2i hash: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0
强烈建议不要自己为这个函数生成盐值（salt）。只要不设置，它会自动创建安全的盐值。
就像以上提及的，在 PHP 7.0 提供 salt选项会导致废弃（deprecation）警告。
未来的 PHP 发行版里，手动提供盐值的功能已经在 PHP 8.0 移除。
注意:
在交互的系统上，推荐在自己的服务器上测试此函数，调整 cost 参数直至函数时间开销小于 350 毫秒（milliseconds）。 上面脚本的示例会帮助选择合适硬件的最佳 cost。
注意: 这个函数更新支持的算法时（或修改默认算法），必定会遵守以下规则：
- 任何内核中的新算法必须在经历一次 PHP 完整发行才能成为默认算法。 比如，在 PHP 7.5.5 中添加的新算法，在 PHP 7.7 之前不能成为默认算法 （由于 7.6 是第一个完整发行版）。 但如果是在 7.6.0 里添加的不同算法，在 7.7.0 里也可以成为默认算法。
- 仅仅允许在完整发行版中修改默认算法（比如 7.3.0, 8.0.0，等等），不能是在修订版。 唯一的例外是：在当前默认算法里发现了紧急的安全威胁。
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_compatSince 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:
// config.conf
pepper=c1isvFdxMDdmjOlvxpecFw
<?php
// 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);
?>
<?php
// 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.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.If you are you going to use bcrypt then you should pepper the passwords with random large string, as commodity hardware can break bcrypt 8 character passwords within an hour; https://www.tomshardware.com/news/eight-rtx-4090s-can-break-passwords-in-under-an-hourPlease note that password_hash will ***truncate*** the password at the first NULL-byte.
http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html
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.
The password
$a = "\01234567";
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.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;
?>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.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
/**
* @Param int $min_ms Minimum amount of time in milliseconds that it should take
* to calculate the hashes
*/
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
?>Timing attacks simply put, are attacks that can calculate what characters of the password are due to speed of the execution.
More at...
https://paragonie.com/blog/2015/11/preventing-timing-attacks-on-string-comparison-with-double-hmac-strategy
I have added code to phpnetcomment201908 at lucb1e dot com's suggestion to make this possible "timing attack" more difficult using the code phpnetcomment201908 at lucb1e dot com posted.
$pph_strt = microtime(true);
//...
/*The code he posted for login.php*/
//...
$end = (microtime(true) - $pph_strt);
$wait = bcmul((1 - $end), 1000000); // usleep(250000) 1/4 of a second
usleep ( $wait );
echo "<br>Execution time:".(microtime(true) - $pph_strt)."; ";
Note I suggest changing the wait time to suit your needs but make sure that it is more than than the highest execution time the script takes on your server.
Also, this is my workaround to obfuscate the execution time to nullify timing attacks. You can find an in-depth discussion and more from people far more equipped than I for cryptography at the link I posted. I do not believe this was there but there are others. It is where I found out what timing attacks were as I am new to this but would like solid security.According to the draft specification, Argon2di is the recommended mode of operation:
> 9.4. Recommendations
>
> The Argon2id variant with t=1 and maximum available memory is
> recommended as a default setting for all environments. This setting
> is secure against side-channel attacks and maximizes adversarial
> costs on dedicated bruteforce hardware.
source: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-06#section-9.4