HMAC SHA1を使用するRfc2898DeriveBytesは、パスワードをハッシュするために「十分に安全」と見なされていますか？
[〜＃〜] cissp [〜＃〜] から、.NETクラスRfc2898DeriveBytesはSHA1をまだ使用しているため、今日はセキュリティ監査に合格しないと言われました。 SHA1に依存しているため、繰り返しを含めても、ブルートフォースクラッキングに対して脆弱すぎます。私自身の理解のため、およびこの質問に遭遇した他の人のために、Rfc2898DeriveBytesは依然としてパスワードをハッシュするための安全な方法と見なされていますか？同じように、HMAC SHA256はソルトを使用していますが、反復は十分ではありませんか？
記録のために、私はRfc2898DeriveBytes以外のものを使用するように義務付けられており、自分でゼロからロールバックするよりもわかっているため、Rfc2898DeriveBytesを逆アセンブルし、SHA1の代わりにSHA256を使用してコードを複製します。
Rfc2898DeriveBytesPBKDF2 として知られ、 RFC 2898 で定義されている標準的なアルゴリズムを実装します（したがって、名前です）。そのアルゴリズムは、通常 [〜＃〜] hmac [〜＃〜] である構成可能な基本的な擬似ランダム関数を使用し、HMAC自体は、構成可能な基本的なハッシュ関数、通常はSHA-1に依存しています。これはすべて構成可能ですが、特定の実装はそれほど柔軟ではない場合があり、実際、Rfc2898DeriveBytesalwaysはHMACを使用し、alwaysはSHA-1の基本機能としてSHA-1を使用します。
現在、「監査人」として集合的に知られている人々は、 SHA-1 に関連する何かを見ると、泣き叫び、泣き声を上げ、悲鳴を上げ、嘲笑し、輪になって走る傾向があります。これは科学的に不当です。 たった今、公開されているすべてのサイエンスの中で、SHA-1 HMACで使用した場合弱い。 SHA-1の既知の弱点は、約collisionsであり、HMACに影響を与えません（これらはいずれにしても理論上のものです）。 SHA-1がPBKDF2をブルートフォースに対してより脆弱にすることをCISSPを持つ一部の男が主張する場合、その男は自分の教訓を再学習する必要があります。
それでも、SHA-256を切り替えることは悪い考えではありません。そのため、SHA-1を回避することが監査人を排除するために必要なものである場合は、そうしてください。
ただし、次のことは言う必要があります。
分解してから変更するのはかなり大雑把な方法であり、保守不能なコードにつながる傾向があります。実際のソースコードから開始することもできます（例： here から）。または、さらに簡単に（そしてより明確な法的ステータスで）、最初から再実装できます。 .NETは HMAC/SHA-256実装 を提供します。それを使用してPBKDF2コードを実行することは難しくありません。
あるいは、 this one のような他の既存の実装を再利用することもできます。
「パスワードをハッシュ化」したい場合にPBKDF2を使用しますが、その点ですべての機能が同じというわけではありません。ハッシュ関数は、攻撃者が計算するのにコストがかかる場合にのみ有効です。その点では、SHA-1またはSHA-256を備えたPBKDF2は最良の選択ではありません。間違いなく、SHA-512を備えたPBKDF2の方が適切です（既存のGPUはSHA-256よりもSHA-512を最適化するのに時間がかかるため）が、他のソリューション、特に bcrypt の方が好ましい場合があります。この問題の詳細については、 this 、より一般的には this を参照してください。
つまり、SHA-1の「弱点」によってPBKDF2が弱くなることはありませんが、それでもGPUで非常に適切に最適化できる関数であり、その場合は問題になりますが、ここで重要な点です。 SHA-256運賃はこれ以上ありません。
いずれの場合も、純粋なC＃実装を使用することにより、このCPUを集中的に使用することで、そのテクノロジ固有のスローダウンで実行されることを受け入れます。これは、最適化されたCコード（またはアセンブリ）と比較した場合、2〜3倍と推定できます。 。つまり、攻撃者に2倍または3倍のアドバンテージを与えます。したがって、純粋なC＃ではなく、いくつかのネイティブコードを使用したい場合があります。