php - PHPパスワードの安全なハッシュとソルト

Question

現在、MD5は部分的に安全ではないと言われています。これを考慮して、パスワード保護にどのメカニズムを使用するかを知りたいです。

この質問、「ダブルハッシュ」パスワードは、一度だけハッシュするよりも安全性が低くなりますか？個々のファイルにパスワード保護を実装する方法に対して、複数回ハッシュすることは良い考えかもしれないことを示唆しています。塩の使用をお勧めします。

私はPHPを使用しています。安全で高速なパスワード暗号化システムが必要です。パスワードを100万回ハッシュする方が安全かもしれませんが、遅くなることもあります。速度と安全性のバランスをとるには？また、結果には一定の文字数を含めることをお勧めします。

ハッシュメカニズムはPHPで利用可能である必要があります
安全でなければなりません
それは塩を使うことができます（この場合、すべての塩は等しく良いですか？良い塩を生成する方法はありますか？）

また、データベースに2つのフィールド（たとえば、MD5を使用するフィールドとSHAを使用するフィールド）を格納する必要がありますか？それはそれをより安全にしますか、それとも安全ではありませんか？

十分に明確でない場合は、安全で高速なパスワード保護メカニズムを実現するために、使用するハッシュ関数と適切なソルトを選択する方法を知りたいと思います。

私の質問を完全にカバーしていない関連する質問：

PHPのSHAとMD5の違いは何ですか
 単純なパスワード暗号化
 キー、asp.netのパスワードを安全に保存する方法
 Tomcat5.5でソルトパスワードをどのように実装しますか

score 1013 · Accepted Answer

免責事項：この回答は2008年に書かれました。

それ以来、PHP は私たちpassword_hashに andを与えpassword_verify、その導入以来、これらは推奨されるパスワードのハッシュとチェック方法です。

ただし、答えの理論はまだ読みやすいです。

TL;DR

してはいけないこと

ユーザーがパスワードに入力できる文字を制限しないでください。こんなことするのはバカだけ。
パスワードの長さを制限しないでください。ユーザーが supercalifragilisticexpialidocious を含む文を必要としている場合は、その使用を妨げないでください。
パスワードの HTML および特殊文字を削除またはエスケープしないでください。
ユーザーのパスワードを平文で保存しないでください。
ユーザーがパスワードを紛失した場合を除き、ユーザーにパスワードを電子メールで送信しないでください。一時的なパスワードを送信しました。
決してパスワードをログに記録しないでください。
SHA1や MD5、さらには SHA256でパスワードをハッシュしないでください。最新のクラッカーは、1 秒あたり 600 億および 1800 億のハッシュを (それぞれ) 超える可能性があります。
bcrypt とhash()の生の出力を混在させないでください。16 進出力を使用するか、base64_encode を使用してください。\0(これは、セキュリティを著しく弱める可能性のあるローグが含まれている可能性のある入力に適用されます。)

ドス

可能な場合は scrypt を使用してください。できない場合は bcrypt を使用してください。
SHA2 ハッシュで bcrypt または scrypt を使用できない場合は、PBKDF2 を使用します。
データベースが侵害された場合、全員のパスワードをリセットします。
合理的な 8 ～ 10 文字の最小長を実装し、さらに少なくとも 1 つの大文字、1 つの小文字、数字、および記号を必要とします。これにより、パスワードのエントロピーが向上し、解読が困難になります。(議論については、「良いパスワードの条件」セクションを参照してください。)

とにかくパスワードをハッシュするのはなぜですか？

パスワードをハッシュ化する目的は単純です。データベースを侵害して、ユーザーアカウントへの悪意のあるアクセスを防止することです。したがって、パスワードハッシュの目的は、ハッカーやクラッカーが平文のパスワードを計算するために多大な時間や費用を費やすことで、ハッカーやクラッカーを抑止することです。そして、時間とコストは、武器庫の中で最も抑止力になります。

ユーザーアカウントに適切で堅牢なハッシュが必要なもう 1 つの理由は、システム内のすべてのパスワードを変更するための十分な時間を確保するためです。データベースが侵害された場合、データベース内のすべてのパスワードを変更しない限り、少なくともシステムをロックダウンするのに十分な時間が必要です。

Whitehat Security の CTO である Jeremiah Grossman 氏は、パスワード保護を力ずくで破る必要があった最近のパスワード回復の後、White Hat Security ブログで次のように述べています。

興味深いことに、この悪夢を生き抜く中で、パスワードのクラッキング、ストレージ、複雑さについて知らなかった多くのことを学びました。パスワードの複雑さよりも、パスワードの保管が重要である理由を理解するようになりました。パスワードがどのように保存されているかがわからない場合、信頼できるのは複雑さだけです。これは、パスワードと暗号化の専門家にとっては常識かもしれませんが、平均的な情報セキュリティまたは Web セキュリティの専門家にとっては、私はそれを非常に疑っています.

（私のものを強調してください。）

とにかく良いパスワードを作るものは何ですか?

エントロピー。(ランドールの見解に完全に同意しているわけではありません。)

簡単に言えば、エントロピーとは、パスワード内の変化の量です。パスワードが小文字のローマ字のみの場合、それはわずか 26 文字です。それはたいしたバリエーションではありません。36 文字の英数字パスワードの方が優れています。ただし、記号を含む大文字と小文字を使用できるのは、およそ 96 文字です。それはただの手紙よりもはるかに優れています。1 つの問題は、パスワードを覚えやすくするためにパターンを挿入することです。これにより、エントロピーが減少します。おっとっと！

パスワードのエントロピーは簡単に概算できます。ASCII 文字の全範囲 (約 96 文字の入力可能文字) を使用すると、1 文字あたり 6.6 のエントロピーが得られますが、パスワードの 8 文字では、将来のセキュリティにはまだ小さすぎます (52.679 ビットのエントロピー)。ただし、良いニュースは、より長いパスワードや Unicode 文字を含むパスワードを使用すると、パスワードのエントロピーが実際に増加し、解読が困難になることです。

Crypto StackExchangeサイトには、パスワードエントロピーに関するより長い議論があります。優れた Google 検索でも、多くの結果が得られます。

@popnoodles とのコメントで、X 個の文字、数字、記号などを含む X 長のパスワードポリシーを適用すると、パスワードスキームがより予測しやすくなり、実際にエントロピーを減らすことができると指摘しました。私は同意しますよ。可能な限り真にランダムなランダム性は、常に最も安全ですが、記憶に残りにくいソリューションです。

私が知る限り、世界最高のパスワードを作ることはキャッチ 22 です。記憶に残らない、予測しにくい、短すぎる、Unicode 文字が多すぎる (Windows/モバイルデバイスでは入力しにくい)、長すぎる、などのいずれかです。私たちの目的に本当に十分なパスワードはありません。フォートノックスにいました。

ベストプラクティス

Bcrypt とscryptが現在のベストプラクティスです。Scryptはいずれ bcrypt よりも優れたものになるでしょうが、Linux/Unix または Web サーバーによる標準としての採用は見られず、そのアルゴリズムの詳細なレビューはまだ投稿されていません。それでも、アルゴリズムの将来は有望に見えます。Ruby を使用している場合は、役立つscrypt gemがあり、Node.js には独自のscryptパッケージがあります。PHP で Scrypt を使用するには、Scrypt拡張機能またはLibsodium拡張機能 (どちらも PECL で利用可能) を使用します。

bcrypt の使用方法を理解したい場合は、 crypt 関数のドキュメントを読むか、適切なラッパーを見つけるか、よりレガシーな実装にPHPASSなどを使用することを強くお勧めします。15 から 18 ではないにしても、最低でも 12 ラウンドの bcrypt をお勧めします。

bcrypt が可変コストメカニズムを備えたフグのキースケジュールのみを使用することを知ったとき、bcrypt の使用についての考えが変わりました。後者を使用すると、blowfish のすでに高価なキースケジュールを増やすことで、パスワードをブルートフォースするコストを増やすことができます。

平均的な慣行

この状況はもうほとんど想像できません。PHPASSは PHP 3.0.18 から 5.3 までをサポートしているため、考えられるほぼすべてのインストールで使用できます。また、使用している環境が bcrypt をサポートしているかどうかわからない場合に使用する必要があります。

しかし、bcrypt も PHPASS もまったく使用できないとします。じゃあ何？

環境/アプリケーション/ユーザーの認識が許容できる最大ラウンド数で PDKBF2の実装を試してください。私が推奨する最小数は 2500 ラウンドです。また、操作の再現を困難にするために使用可能な場合は、必ずhash_hmac()を使用してください。

今後の実践

PHP 5.5 で登場するのは、bcrypt での作業を抽象化する完全なパスワード保護ライブラリです。私たちのほとんどは、ほとんどの一般的な環境、特に共有ホストで PHP 5.2 および 5.3 に行き詰まっていますが、@ircmaxell は、PHP 5.3.7 と下位互換性のある今後の API 用の互換レイヤーを構築しました。

暗号化の要約と免責事項

ハッシュ化されたパスワードを実際にクラックするために必要な計算能力は存在しません。コンピュータがパスワードを「クラック」する唯一の方法は、パスワードを再作成し、パスワードを保護するために使用されるハッシュアルゴリズムをシミュレートすることです。ハッシュの速度は、ブルートフォース攻撃の能力に比例します。さらに悪いことに、ほとんどのハッシュアルゴリズムは簡単に並列化できるため、さらに高速に実行できます。これが、bcrypt や scrypt のようなコストのかかるスキームが非常に重要な理由です。

すべての脅威や攻撃手段を予測することはできないため、ユーザーを事前に保護するために最善を尽くす必要があります。そうしないと、手遅れになるまで攻撃されたという事実さえ見逃す可能性があります...そしてあなたは責任を負います. そのような状況を回避するには、まず妄想的に行動してください。自分のソフトウェアを (内部的に) 攻撃し、ユーザーの資格情報を盗もうとしたり、他のユーザーのアカウントを変更したり、そのデータにアクセスしたりします。システムのセキュリティをテストしなければ、自分以外の誰かを責めることはできません。

最後に: 私は暗号学者ではありません。私が言ったことはすべて私の意見ですが、たまたま古き良き常識に基づいていると思います...そして多くの読書. 可能な限り偏執的になり、侵入しにくくすることを忘れないでください。それでも心配な場合は、ホワイトハットハッカーまたは暗号学者に連絡して、コード/システムについて彼らが何を言っているかを確認してください.

score 145 · Accepted Answer

はるかに短くて安全な答え -独自のパスワードメカニズムをまったく記述しないでください。試行済みのメカニズムを使用してください。

PHP 5.5 以降: password_hash()は高品質で、PHP コアの一部です。
PHP 4.x (廃止): OpenWall のphpassライブラリは、WordPress、Drupal などで使用されるほとんどのカスタムコードよりもはるかに優れています。

ほとんどのプログラマーは、脆弱性を導入せずに暗号関連のコードを安全に作成する専門知識を持っていません。

簡単なセルフテスト:パスワードストレッチングとは何ですか? また、何回反復する必要がありますか? 答えがわからない場合は、を使用する必要があります。これは、CPU がはるかに高速になり、 GPU と FPGAを使用して 1 秒あたり数十億回の推測速度でパスワードを解読password_hash()できるようになったため、パスワードストレッチングはパスワードメカニズムの重要な機能になっているためです(GPUを使用) ）。

2012 年の時点で、5 台のデスクトップ PC に取り付けられた 25 個の GPU を使用して、6 時間ですべての 8 文字の Windows パスワードをクラックできました。これは総当たり攻撃です。つまり、特殊文字を含むすべての 8 文字の Windows パスワードを列挙してチェックします。辞書攻撃ではありません。最新の GPU を使用すると、もちろん、より多くのパスワードをクラックしたり、使用する GPU を減らしたり、合理的なコストで数時間クラウドで GPU をレンタルしたりできます。

通常の CPU で実行され、非常に高速な Windows パスワードに対するレインボーテーブル攻撃も多数あります。

これはすべて、 Windows 10 であっても、 Windowsがまだパスワードをソルトまたはストレッチしていないためです。これは 2021 年にも当てはまります。Microsoft が犯したのと同じ過ちを犯さないでください。

以下も参照してください。

理由password_hash()やphpass最善の方法についての詳細を含む優れた回答。
bcrypt、scrypt、および PBKDF2 を含む主要なアルゴリズムの推奨される「作業要素」(反復回数) を提供する優れたブログ記事。

score 45 · Accepted Answer

2 つの異なる方法でハッシュ化されたパスワードを保存することはしません。これは、システムが少なくとも使用中のハッシュアルゴリズムの中で最も弱いものと同じくらい弱いためです。

score 44 · Accepted Answer

PHP 5.5 の時点で、PHP にはパスワードのハッシュと検証のためのシンプルで安全な関数password_hash()とpassword_verify( ) があります。

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

がpassword_hash()使用されると、ランダムなソルトが生成され、出力されたハッシュに含まれます (使用されるコストとアルゴリズムと共に)。password_verify()次に、そのハッシュを読み取り、使用されるソルトと暗号化方法を決定し、提供されたプレーンテキストパスワードと照合します。

PASSWORD_DEFAULTを指定すると、インストールされているバージョンの PHP のデフォルトのハッシュアルゴリズムを使用するように PHP に指示します。正確にどのアルゴリズムが将来のバージョンで時間の経過とともに変更されることを意図しているかを意味するため、常に利用可能な最も強力なアルゴリズムの 1 つになります。

コスト (デフォルトは 10) を増やすと、ハッシュのブルートフォースが難しくなりますが、ハッシュの生成とそれらに対するパスワードの検証がサーバーの CPU にとってより多くの作業になることも意味します。

デフォルトのハッシュアルゴリズムが変更される可能性がある場合でも、使用されるアルゴリズムがハッシュに格納され、それを取得するため、古いハッシュは問題なく検証され続けることに注意してくださいpassword_verify()。

score 33 · Accepted Answer

質問には回答がありますが、ハッシュに使用されるソルトはランダムであり、最初の回答で提案されている電子メールアドレスとは異なります。

詳細については、 http： //www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/を参照してください。

最近、ランダムビットでソルトされたパスワードハッシュが、推測可能なソルトまたは既知のソルトでソルトされたものよりも安全かどうかについて話し合いました。見てみましょう：パスワードを保存するシステムとランダムソルトを保存するシステムが侵害された場合、攻撃者はソルトだけでなくハッシュにもアクセスできるため、ソルトがランダムであるかどうかは関係ありません。攻撃者は、事前に計算されたレインボーテーブルを生成して、ハッシュを解読することができます。ここに興味深い部分があります-事前に計算されたテーブルを生成することはそれほど簡単ではありません。WPAセキュリティモデルの例を見てみましょう。WPAパスワードが実際にワイヤレスアクセスポイントに送信されることはありません。代わりに、SSID（Linksys、Dlinkなどのネットワーク名）でハッシュされます。これがどのように機能するかについての非常に良い説明はここにあります。ハッシュからパスワードを取得するには、パスワードとsalt（ネットワーク名）を知っている必要があります。Church of Wifiは、上位1000のSSIDと約100万のパスワードを持つハッシュテーブルを事前に計算しています。すべてのテーブルのサイズは約40GBです。彼らのサイトで読むことができるように、誰かがこれらのテーブルを生成するために3日間15のFGPAアレイを使用しました。被害者がSSIDを「a387csf3」、パスワードを「123456」として使用しているとすると、これらのテーブルによってクラックされるのでしょうか。いいえ！.. できない。パスワードが弱い場合でも、テーブルにはSSIDa387csf3のハッシュがありません。これがランダムソルトの美しさです。それは、事前に計算されたテーブルで繁栄するクラッカーを阻止します。決心したハッカーを止めることはできますか？おそらくそうではありません。しかし、ランダムソルトを使用すると、防御の追加レイヤーが提供されます。このトピックに取り組んでいる間、別のシステムにランダムな塩を保存することの追加の利点について説明しましょう。シナリオ＃1：パスワードハッシュはシステムXに保存され、ハッシュに使用されるソルト値はシステムYに保存されます。これらのソルト値は推測可能または既知です（例：ユーザー名）シナリオ＃2：パスワードハッシュはシステムXに保存され、ソルト値はハッシュはシステムYに保存されます。これらのソルト値はランダムです。ご想像のとおり、システムXが危険にさらされた場合、別のシステムでランダムソルトを使用することには大きな利点があります（シナリオ＃2）。攻撃者は、ハッシュを解読できるように加算値を推測する必要があります。32ビットソルトを使用する場合、推測されるパスワードごとに2 ^ 32 = 4,294,967,296（約42億）の反復が必要になる可能性があります。パスワードハッシュはシステムXに保存され、ハッシュに使用されるソルト値はシステムYに保存されます。これらのソルト値は推測可能または既知です（例：ユーザー名）シナリオ＃2：パスワードハッシュはシステムXに保存され、ハッシュに使用されるソルト値はに保存されますシステムY。これらのソルト値はランダムです。ご想像のとおり、システムXが危険にさらされた場合、別のシステムでランダムソルトを使用することには大きな利点があります（シナリオ＃2）。攻撃者は、ハッシュを解読できるように加算値を推測する必要があります。32ビットソルトを使用する場合、推測されるパスワードごとに2 ^ 32 = 4,294,967,296（約42億）の反復が必要になる可能性があります。パスワードハッシュはシステムXに保存され、ハッシュに使用されるソルト値はシステムYに保存されます。これらのソルト値は推測可能または既知です（例：ユーザー名）シナリオ＃2：パスワードハッシュはシステムXに保存され、ハッシュに使用されるソルト値はに保存されますシステムY。これらのソルト値はランダムです。ご想像のとおり、システムXが危険にさらされた場合、別のシステムでランダムソルトを使用することには大きな利点があります（シナリオ＃2）。攻撃者は、ハッシュを解読できるように加算値を推測する必要があります。32ビットソルトを使用する場合、推測されるパスワードごとに2 ^ 32 = 4,294,967,296（約42億）の反復が必要になる可能性があります。これらのソルト値はランダムです。ご想像のとおり、システムXが危険にさらされた場合、別のシステムでランダムソルトを使用することには大きな利点があります（シナリオ＃2）。攻撃者は、ハッシュを解読できるように加算値を推測する必要があります。32ビットソルトを使用する場合、推測されるパスワードごとに2 ^ 32 = 4,294,967,296（約42億）の反復が必要になる可能性があります。これらのソルト値はランダムです。ご想像のとおり、システムXが危険にさらされた場合、別のシステムでランダムソルトを使用することには大きな利点があります（シナリオ＃2）。攻撃者は、ハッシュを解読できるように加算値を推測する必要があります。32ビットソルトを使用する場合、推測されるパスワードごとに2 ^ 32 = 4,294,967,296（約42億）の反復が必要になる可能性があります。

score 29 · Accepted Answer

PHP 5.5 には、のラッパーを提供するパスワードハッシュ APIが含まれていることを指摘しておきたいと思いますcrypt()。この API は、パスワードハッシュのハッシュ、検証、および再ハッシュのタスクを大幅に簡素化します。著者は、PHP 5.3.7 以降を使用していて、今すぐこれを使用したい人向けに、互換パック(単純に使用できる単一の password.php ファイルの形式)もリリースしています。require

現時点では BCRYPT のみをサポートしていますが、他のパスワードハッシュ手法を含めるように簡単に拡張することを目的としています。手法とコストはハッシュの一部として保存されるため、好みのハッシュ手法/コストを変更しても現在のハッシュが無効になることはありません。自動的に、検証時に正しいテクニック/コストを使用します。また、独自のソルトを明示的に定義しない場合は、「安全な」ソルトの生成も処理します。

API は次の 4 つの関数を公開します。

password_get_info()- 指定されたハッシュに関する情報を返します
password_hash()- パスワードハッシュを作成する
password_needs_rehash()- 指定されたハッシュが指定されたオプションと一致するかどうかを確認します。ハッシュが現在の技術/コストスキームに準拠しているかどうかを確認するのに役立ち、必要に応じて再ハッシュできます
password_verify()- パスワードがハッシュと一致することを確認します

現時点では、これらの関数は PASSWORD_BCRYPT と PASSWORD_DEFAULT のパスワード定数を受け入れますが、これらは現時点では同義語です。違いは、PASSWORD_DEFAULT は「新しく強力なハッシュアルゴリズムがサポートされている場合、新しい PHP リリースで変更される可能性がある」ことです。ログイン時に PASSWORD_DEFAULT と password_needs_rehash() を使用する (および必要に応じて再ハッシュする) と、ハッシュがブルートフォース攻撃に対して適度に回復力があり、ほとんどまたはまったく作業を行わないことが保証されます。

編集:これは Robert K's answer で簡単に言及されていることに気付きました。この回答は、それがどのように機能するか、およびセキュリティを知らない人に提供する使いやすさについてもう少し情報を提供すると思うので、ここに残しておきます。

score 21 · Accepted Answer

私はPhpassを使用しています。これは、ほぼすべての PHP プロジェクトで非常に簡単に実装できる単純な 1 ファイルの PHP クラスです。Hも参照してください。

デフォルトではbcrypt、Wordpress などのフレームワークとの後方互換性を提供するために、MD5 までの他の暗号化にフォールバックする、Phpass で実装されている利用可能な最強の暗号化を使用しました。

返されたハッシュはそのままデータベースに格納できます。ハッシュを生成するための使用例は次のとおりです。

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

パスワードを確認するには、次を使用できます。

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

score 12 · Accepted Answer

Google によると、SHA256 は PHP で利用可能です。

必ず塩を使用してください。ランダムバイトを使用することをお勧めします（文字と数字に制限しないでください）。通常、選択する時間が長いほど、より安全になり、遅くなります。64 バイトで十分だと思います。

score 8 · Accepted Answer

結局、二重ハッシュは数学的に何のメリットもありません。ただし、実際には、レインボーテーブルベースの攻撃を防ぐのに役立ちます。言い換えれば、ソルトを使用してハッシュすることよりもメリットがありません。ソルトを使用すると、アプリケーションまたはサーバーでのプロセッサ時間が大幅に短縮されます。

score 7 · Accepted Answer

私は通常、SHA1 とソルトをユーザー ID (またはその他のユーザー固有の情報) と共に使用しますが、定数ソルトを追加で使用することもあります (したがって、ソルトには 2 つの部分があります)。

SHA1 も多少侵害されていると見なされるようになりましたが、MD5 よりもはるかに低い程度です。ソルト (任意のソルト) を使用することで、一般的なレインボーテーブルを使用してハッシュを攻撃するのを防ぐことができます (ハッシュを検索することで、Google を一種のレインボーテーブルとして使用することに成功した人もいます)。攻撃者はあなたのソルトを使用してレインボーテーブルを生成する可能性があるため、ユーザー固有のソルトを含める必要があります。そうすれば、システム全体に対して 1 つだけでなく、システム内のすべてのレコードに対してレインボーテーブルを生成する必要があります。このタイプのソルティングでは、MD5 でさえ十分に安全です。

score 5 · Accepted Answer

近い将来には、 SHA1とソルトで十分です (当然のことながら、Fort Knox用に何かをコーディングしているか、買い物リスト用のログインシステムをコーディングしているかによって異なります)。SHA1 が十分でない場合は、SHA256を使用してください。

ソルトのアイデアは、いわばハッシュ結果のバランスを崩すことです。たとえば、空の文字列の MD5 ハッシュはd41d8cd98f00b204e9800998ecf8427e. したがって、十分な記憶力を持つ人がそのハッシュを見て、それが空の文字列のハッシュであることを知っている場合。しかし、文字列が (たとえば、文字列 " MY_PERSONAL_SALT" で) ソルトされている場合、「空の文字列」 (つまり " MY_PERSONAL_SALT") のハッシュはになるaeac2612626724592271634fb14d3ea6ため、バックトレースがわかりません。私が言おうとしているのは、塩を使わないよりは使ったほうがよいということです。したがって、どの塩を使用するかを知ることはそれほど重要ではありません。

実際にこれを行う Web サイトがあります。(md5) ハッシュをフィードすると、その特定のハッシュを生成する既知の平文が吐き出されます。プレーンな md5 ハッシュを格納するデータベースにアクセスできる場合、そのようなサービスに管理者のハッシュを入力してログインするのは簡単です。しかし、パスワードがソルト化されている場合、そのようなサービスは次のようになります。効果がない。

また、二重ハッシングは一般に悪い方法と見なされています。結果スペースが減少するからです。一般的なハッシュはすべて固定長です。したがって、この固定長の有限値のみを持つことができ、結果の変化は少なくなります。これは別の塩漬けと見なすこともできますが、お勧めしません。

score -7 · Accepted Answer

塩は一意でなければならないので、生成させてください

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

また、sha512を使用しているハッシュが必要です。これは最高で、phpにあります

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

これで、この関数を使用して安全なパスワードを生成できます

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

$hash_psw 変数値と $salt 変数をデータベースに保存する必要があります

承認には同じ手順を使用します...

これは、クライアントのパスワードを保護するための最良の方法です...

Ps の最後の 2 つの手順では、独自のアルゴリズムを使用できます...ただし、将来ユーザーを承認する必要がある場合は、このハッシュ化されたパスワードを生成できることを確認してください...