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
password_hash
(PHP 5 >= 5.5.0, PHP 7, PHP 8)
password_hash — パスワードハッシュを作る
説明
password_hash(string
$password, string|int|null $algo, array $options = []): stringpassword_hash() は、 強力な一方向ハッシュアルゴリズムを使って、 新しいパスワードハッシュを作ります。
現在、以下のアルゴリズムに対応しています。
-
PASSWORD_DEFAULT- bcrypt アルゴリズムを使います (PHP 5.5.0 の時点でのデフォルトです)。 新しくてより強力なアルゴリズムが PHP に追加されれば、 この定数もそれにあわせて変わっていきます。 そのため、これを指定したときの結果の長さは、変わる可能性があります。 したがって、結果をデータベースに格納するときにはカラム幅を 60 文字以上にできるようなカラムを使うことをお勧めします (255 文字くらいが適切でしょう)。 -
PASSWORD_BCRYPT-CRYPT_BLOWFISHアルゴリズムを使ってハッシュを作ります。これは標準の crypt() 互換のハッシュで、識別子 "$2y$" を使った場合の結果を作ります。 その結果は、常に 60 文字の文字列になります。失敗した場合にfalseを返します。 -
PASSWORD_ARGON2I- Argon2i ハッシュアルゴリズムを使って ハッシュを作ります。このアルゴリズムは、 PHP が Argon2 のサポートを有効にしてコンパイルした場合のみ利用できます。 -
PASSWORD_ARGON2ID- Argon2id ハッシュアルゴリズムを使って ハッシュを作ります。このアルゴリズムは、 PHP が Argon2 のサポートを有効にしてコンパイルした場合のみ利用できます。
PASSWORD_BCRYPT がサポートするオプション:
-
salt(string) - パスワードのハッシュに使うソルトを手動で設定します。 これは、自動生成されたソルトを上書きすることに注意しましょう。省略した場合は、パスワードをハッシュするたびに password_hash() がランダムなソルトを自動生成します。これは意図したとおりの操作モードです。
警告このソルト・オプションは 非推奨になっています。 このオプションは指定せずに、デフォルトで生成されるソルトを使うことを推奨します。 PHP 8.0.0 以降は、この値を明示的に指定しても無視されます。
-
cost(int) - 利用するアルゴリズムのコストを表します。 値の例については crypt() のページを参照ください。省略した場合のデフォルトは
10です。この値でもかまいませんが、 ハードウェアの性能が許すならもう少し高くすることもできます。
PASSWORD_ARGON2I と
PASSWORD_ARGON2ID が
サポートするオプション
-
memory_cost(int) - Argon2 ハッシュを計算するのに 使われるメモリの最大値(キロバイト単位)。 デフォルトはPASSWORD_ARGON2_DEFAULT_MEMORY_COSTです。 -
time_cost(int) - Argon2 ハッシュを計算するのに 使って良い時間の最大値。 デフォルトはPASSWORD_ARGON2_DEFAULT_TIME_COSTです。 -
threads(int) - Argon2 ハッシュを計算するのに使う スレッド数。 デフォルトはPASSWORD_ARGON2_DEFAULT_THREADSです。警告PHP が libargon2 を使う場合にのみ利用可能です。 libsodium の実装では利用できません。
パラメータ
-
password -
ユーザーのパスワード。
警告PASSWORD_BCRYPTをアルゴリズムに指定すると、passwordが最大 72 バイトまでに切り詰められます。 -
algo -
パスワードのハッシュに使うアルゴリズムを表す パスワードアルゴリズム定数。
-
options -
オプションを含む連想配列。各アルゴリズムがサポートするオプションについては、 パスワードアルゴリズム定数 のページを参照ください。
省略した場合は、ランダムな salt を生成してデフォルトのコストを使います。
戻り値
ハッシュしたパスワードを返します。
使ったアルゴリズムやコスト、そしてソルトもハッシュの一部として返されます。 つまり、ハッシュを検証するために必要な情報は、すべてそこに含まれているということです。 そのため、password_verify() でハッシュを検証するときに、 ソルトやアルゴリズムの情報を別に保存する必要はありません。
変更履歴
| バージョン | 説明 |
|---|---|
| 8.0.0 |
password_hash()
は、失敗時に false を返さなくなりました。
代わりに、パスワードハッシュのアルゴリズムが有効でなかった場合は
ValueError がスローされるようになりました。
また、パスワードハッシュの作成が不明なエラーで失敗した場合は、
Error がスローされるようになっています。
|
| 8.0.0 |
引数 algo は、 nullable になりました。
|
| 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() で、コストを手動で設定する例
<?php
/**
* この例では、BCRYPT のコストをデフォルトより上げて、12 にします。
* また、アルゴリズムを BCRYPT に変えたことにも注目しましょう。結果は常に 60 文字になります。
*/
$options = [
'cost' => 12,
];
echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
?>
上の例の出力は、 たとえば以下のようになります。
$2y$12$QjSH496pcT5CEbzjD/vtVeH03tfHKFy36d4J0Ltp3lRtee9HDxY3K
例3 password_hash() で、適切なコストを探す例
<?php
/**
* このコードは、サーバーをベンチマークして、どの程度のコストに耐えられるかを判断します。
* サーバーに負荷をかけすぎない範囲で、できるだけ高めのコストを設定したいものです。
* 基準として 8 から 10 程度からはじめ、サーバーが十分に高速なら、できるだけ上げていきましょう。
* 以下のコードでは、ストレッチングの時間を 50 ミリ秒以内にすることを狙っています。
* 対話形式のログインを扱う際の許容時間としては、このあたりが妥当なところでしょう。
*/
$timeTarget = 0.05; // 50 ミリ秒
$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;
?>
上の例の出力は、 たとえば以下のようになります。
Appropriate Cost Found: 10
例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
注意
警告
この関数で使うソルトを自前で設定するのはお勧めしません。 ソルトを省略すれば、安全なソルトをこの関数が自動的に作ってくれます。
先述のとおり、PHP 7.0 で salt オプションを指定すると、
非推奨の警告が発生します。ソルトを手動で設定する仕組みは、将来のリリースで廃止されるかもしれません。
注意:
実際にサーバー上でこの関数をテストして、コストパラメータの適切な設定値を調整することをお勧めします。 対話型のシステムなら、関数の実行時間が 100 ミリ秒くらいに収まるくらいが適切です。 先ほどの例のスクリプトは、自分のハードウェア上での適切なコストを判断するための助けとなるでしょう。
注意: この関数がサポートするアルゴリズムの更新 (あるいはデフォルトのアルゴリズムの変更) は、必ず次の手順にのっとって行われます。
- 新しく追加されたアルゴリズムがデフォルトになるまでには、 少なくとも一度は PHP のフルリリースを経ること。 つまり、たとえば、新しいアルゴリズムが 7.5.5 で追加されたとすると、 そのアルゴリズムがデフォルトになるのは早くても 7.7 以降ということになります (7.6 は、最初のフルリリースだからです)。 しかし、もし別のアルゴリズムが 7.6.0 で追加されたとすると、 そのアルゴリズムも 7.7.0 の時点でデフォルトになる資格を得ます。
- デフォルトを変更できるのはフルリリース (7.3.0 や 8.0.0 など) のときだけで、リビジョンリリースでは変更できない。 唯一の例外は、現在のデフォルトにセキュリティ上の致命的な欠陥が発覚した場合の緊急リリースです。
参考
- password_verify() - パスワードがハッシュにマッチするかどうかを調べる
- password_needs_rehash() - 指定したハッシュがオプションにマッチするかどうかを調べる
- crypt() - 文字列の一方向のハッシュ化を行う
- sodium_crypto_pwhash_str() - ASCII 文字でエンコードされたハッシュ値を得る
add a note
User Contributed Notes 12 notes
martinstoeckli ¶
10 years ago
phpnetcomment201908 at lucb1e dot com ¶
3 years ago
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:
// 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.
nicoSWD ¶
9 years ago
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.
Cloxy ¶
9 years ago
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;
?>
Lyo Mi ¶
7 years ago
Please 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.
martinstoeckli ¶
10 years ago
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.
Mike Robinson ¶
8 years ago
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
?>
ms1 at rdrecs dot com ¶
3 years ago
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.
Anonymous ¶
2 years ago
To use argon, follow these steps:
```
git clone https://github.com/p-h-c/phc-winner-argon2
cd phc-winner-argon2 && make && make install
apt install libsodium-dev
cd ~/php-7.4.5 // Your php installation source code
./configure [YOUR_EXISTING_CONFIGURE_COMMANDS] --with-password-argon2 --with-sodium
```
Anonymous ¶
3 years ago
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
php dot net at marksim dot org ¶
3 years ago
regarding the sentence "...database column that can expand beyond 60 characters (255 characters would be a good choice). "
Considering future hash length increase by factor *2 and considering databases to start counting with 1, a password length of 256 characters (not 255) would probably be the better choice :)
hman ¶
3 years ago
I believe a note should be added about the compatibility of crypt() and password_hash().
My tests showed that yes, password_verify can also take hashes generated by crypt - as well as those from password_hash. But vice versa this is not true...
You cannot put hashes generated by password_hash into crypt for comparing them themselves, when used as the salt for crypt, as was recommended years ago (compare user entry with user crypt(userentry,userentry). No big deal, but it means that password checking routines MUST immediately be rewritten to use password_hash...
You cannot start using password_hash for hash generation without also altering the password check routine!
So the word "compatible" should be, IMHO, ammended with a word of caution, hinting the reader, that compatibility here is a one-way street.
