NISTは本当にパスワードハッシュにPBKDF2を推奨していますか？
パスワードハッシュについては、BCryptとPBKDF2の間で躊躇しました。多くのフォーラムやブログで、人々は「彼らの Special Publication SP 800-132 NISTは基本的にパスワードハッシュにPBKDF2を使用することを推奨しています。
これは私たちのクライアントにとって非常に重要な議論かもしれません（彼らは標準を崇拝しています）。しかし、私はまだこの推奨事項を平文で読むことはできません...だから私はそれを快適に主張することはできません。要するに、NISTは多かれ少なかれ言う：
派生したキー情報は、マスターキー（MK）と呼ばれ、mkと表記されます。 MKは、1）1つ以上のデータ保護キー（DPK）を生成してデータを保護するため、または2）中間キーを生成して1つ以上の既存のDPKを保護するため、またはMKから承認されたキー派生関数（KDF）を使用して生成されます。 ）[2]で定義されています。 MKを他の目的に使用しないでください。
そのような推奨事項はありますか、これは単なる神話ですか？
パスワードから暗号化キーを生成するアルゴリズムとしてPBKDF2を使用することをお勧めします。認証のために安全に保管するためにパスワードをハッシュするnotです。 （私もあなたが塩漬けしていると信じていますか？）だから答えはノーです、あなたのユースケースではそのような推奨はありません。これは適切ではないという意味ではありませんが、引用するNISTの推奨事項はありません。
私はあなたが見つけていると思います this ：
検証者は、オフラインの攻撃に耐える形式で記憶された秘密を保存する必要があります（SHALL）。 [SP800-132] で説明されているように、PBKDF2などの承認されたハッシュ関数を使用して、シークレットをソルト値でハッシュする必要があります（SHALL）。ソルト値は、承認されたランダムビットジェネレーターによって生成された32ビット（またはそれ以上）のランダム値である必要があり（SHALL）、ハッシュ結果とともに格納されます。ハッシュ関数の少なくとも10,000回の反復を実行する必要があります（SHOULD）。キー付きハッシュ関数（HMACなど）と、ハッシュ済みオーセンティケータ（たとえば、ハードウェアセキュリティモジュール）とは別に格納されたキーを使用して、格納されたハッシュ済みオーセンティケータに対する辞書攻撃にさらに抵抗する必要があります。
NIST SP 800-132は特にパスワードハッシュについてではなく、特に認証用のパスワードについてではありませんが、特に力ずくで抵抗しているため、PBKDF2を使用することを強くお勧めします。
今後の NIST SP 800-63B ドラフト（Digital Identity Guidelines Authentication and Lifecycle Management ）ただし、PBKDF2を明示的に言及しているが、[〜＃〜] hmac [〜＃〜] ベースのコショウ：
検証者は、オフラインの攻撃に耐える形式で記憶された秘密を保存する必要があります（SHALL）。 [SP 800-132]で説明されているように、秘密はPBKDF2などの承認されたハッシュ関数を使用してソルト値でハッシュする必要があります（SHALL）。ソルト値は、承認されたランダムビットジェネレーターによって生成され、ハッシュ結果と共に保存される32ビット以上のランダム値である必要があります（SHALL）。ハッシュ関数の少なくとも10,000回の反復を実行する必要があります（SHOULD）。キー付きハッシュ関数（例：HMAC [FIPS1981]）と、ハッシュ済みオーセンティケーター（たとえば、ハードウェアセキュリティモジュール）とは別に格納されたキーは、格納されたハッシュ済みオーセンティケーターに対する辞書攻撃にさらに抵抗するために使用する必要があります。
これについては多くの議論がありますが、いずれの場合も、scryptを除外する「承認されたハッシュ関数」を要求します（部分的に意図的にPBKDF2ステップ）およびbcrypt。そして、コショウを別々に保管する必要があるという事実が気に入っています。これが、一般的なPBKDF2形式を定義するための私の試みを復活させた理由です： https://github.com/ecki/habibi-passwordhash