パスワードハッシュでSHA256-cryptよりもbcryptまたはPBKDF2を選択する具体的な理由は何ですか？
パスワードデータベースリークが発生した場合にパスワードの解読を遅くするために、パスワードはハッシュ形式でのみ保存する必要があることはわかっています。それだけでなく、強くて遅い関数でハッシュされ、ラウンド数を変える可能性があります。
多くの場合、 PBKDF2 、 bcrypt 、および scrypt のようなアルゴリズムが推奨されています。 ここ 、 ここ および ここ 。
しかし、少なくともglibc（ description 、 specification ）に実装され、少なくとも一部のLinuxディストリビューションでデフォルトで通常のログインアカウントに使用されているSHA256およびSHA512ベースのハッシュはどうですか？それらを使用しない理由、またはSHA-2ベースのハッシュよりもbcryptを優先する理由はありますか？
もちろんbcryptは大幅に古く（1999）、そのため確立されていますが、SHA-2ハッシュはすでに9年前（2007）であり、scryptはさらに少し若い（2009）ですが、まだもっと言及されているようですしばしば。それは単に受け入れられている慣行ですか、それとも他の理由がありますか？ SHA-2ベースのハッシュに既知の弱点はありますか？
注：具体的には、マルチラウンドパスワードハッシュリンクされたドキュメントとコード$5$および$6$ in cryptハッシュ、プレーンなSHA256またはSHA512ハッシュ関数の単一ラウンドではありません。
これが重複の可能性があるとマークされている質問を見ました。そこでの答えは、私が探しているSHA256-crypt/SHA512-cryptハッシュについての言及がありません。
特定のパスワードハッシュ関数を使用する主な理由は、攻撃者の生活をより困難にすること、またはより正確には、攻撃者が自分の生活を容易にすることを防ぐことです（防御者の生活と比較した場合）。特に、攻撃者は、GPUを使用して、指定された予算で1秒あたりのハッシュをより多く計算する（つまり、1秒あたりのパスワードをより多く試行する）場合があります。
特にSHA-256は、GPUに実装することで大きなメリットを得ます。したがって、SHA-256-cryptを使用する場合、GPUに効率的に実装するのが難しいbcryptを使用する場合よりも攻撃者が有利になります。
BcryptとPBKDF2の比較については この回答 を参照してください。 SHA-256-cryptはPBKDF2ではありませんが、GPUでのパフォーマンス動作は十分に似ているため、同じ結論が当てはまります。
既存のGPUは64ビットよりも32ビット整数を使用する方がはるかに優れており、SHA-512は主に64ビット演算を使用するため、SHA-512のケースは少し明確ではありません。現代のGPUは、SHA-512-cryptを使用して、CPUが（指定された予算で）1秒あたりより多くのハッシュを許可すると予想されます。
SHA-2ハッシュファミリは高速になるように設計されています。 BCryptは低速になるように設計されています。 どちらも堅牢であると見なされます。十分なラウンド数または作業係数を使用すると、どちらかが他方よりも長くかかる可能性がありますが、私は設計が遅い。 （サーバーの負荷が問題である場合、作業係数は調整可能です）
さらに、BCryptは通常コンパイルされた実装（CまたはC++）であるため、私はBCryptに傾いています。
マルチラウンドSHAは、ハッシュ自体ではない場合でも、少なくとも反復のために高水準言語で簡単に実装できます。高水準言語は、実稼働ハードウェアがミリ秒あたりに完了することができるラウンドの数。
どちらのアルゴリズムも、高水準言語、低水準言語、またはハイブリッドで実装できます。 BCryptでは、利用可能なオプションにより、効率的な実装に到達する可能性が高くなります。 （攻撃者とのより均等な競争の場にあなたを置きます）
/etc/shadowファイルの具体的な例については、いずれにしても低レベル（効率的な）アルゴリズムのみを使用している可能性があります。 （SHAまたはBCrypt）この例では、OSのドキュメントを参照して、ハードウェアの速度に基づいてラウンドを最適化する（作業係数）ことをお勧めします- vs-ハッシュをどれだけ強くしたいか。
scrypt（十分に大きな作業係数を使用）には、追加のRAM /メモリ要件（CPUだけでなく）があり、さらに多くのSHA、BCrypt、またはPBKDF2よりもGPU耐性。
編集：ありがとう BCryptはSHA-2よりもGPU耐性があり、SHA-2とPBKDF2はこの点で実質的に同等であることを指摘したトーマス 。
注：この編集が行われた後、私はこの質問を見て、それを考慮に入れています：
注：私は特に、リンクされたドキュメントによって記述され、暗号化ハッシュでコード$ 5 $および$ 6 $でマークされたマルチラウンドパスワードハッシュを意味します。プレーンなSHA256またはSHA512ハッシュ関数の単一ラウンド。
このリンクを提供した の長い22ステップアルゴリズムを見て、私はむしろ質問をひっくり返します。なぜHMACで PBKDF2 の代わりにこれを使用したいのですか？ -SHA2？なぜなら、少なくとも提示されたとおり：
- PBKDF2の定義ははるかに単純に見えます。 これは、よりモジュール化されているためです。これは、ほとんどの作業を外部から提供される疑似ランダム関数に委ねています。通常、これは [〜＃〜] hmac [〜＃〜] でインスタンス化され、その結果、ほとんどの作業がSHA-1やSHA-2などの外部ハッシュ関数に委ねられます。
- これは、PBKDF2のセキュリティが分析しやすくなることを意味します。
対照的に、提供するドキュメントのアルゴリズムには、モチベーションが理解しにくい大量のステップがリストされています。例えば：
11. For each bit of the binary representation of the length of the
password string up to and including the highest 1-digit, starting
from to lowest bit position (numeric value 1):
a) for a 1-digit add digest B to digest A
b) for a 0-digit add the password string
NB: this step differs significantly from the MD5 algorithm. It
adds more randomness.
それはよりランダム性を追加しますか？これはどのように行うのですか？なぜこのステップが存在するのですか？SHA-2は十分なランダム性を追加しないのですか？ SHA-2が十分にランダムでない場合、そもそもなぜそれを使用するのですか？また、このステップでは secret-dependent branching をアルゴリズムに導入しないでください タイミング攻撃 に対する疑問を投げかけます？
リンクしたアルゴリズムが安全でないと言っているのではありません。それだけです：
- 彼らが紹介する作業要素は、PBDKF2--HMAC-SHA2が行うのと同じことです（多数のSHA2の反復）。
- それらは、PBKDF2-HMAC-SHA2実装を展開した場合とほぼ同じように見えますが、目的がわからない複雑さが追加されています。
- したがって、少なくともこれらのドキュメントに記載されているように、PBKDF2の場合よりも、設計の信頼を得ることが難しいと感じています。
EDIT：これをすべて書いた後、私はこのアルゴリズムを少し調査して、よりよく理解してみました。まず、質問自体の "description" および "specification" リンクから、アルゴリズムが比較的小さな変更を加えることにより、古いMD5ベースのアルゴリズムから派生したことがわかります。
この古いMD5ベースのアルゴリズムは表示されます 1994年にPoul-Henning KampがFreeBSD-2.0のために書いたもの 、これは 安全とは見なされなくなりました 。最初のリンク（関数の履歴を伝える）では、glibcも自分の関数を採用したと述べています。彼はまた Provos andMazièresのbcryptに関する1999年の論文 にリンクしており、不快感を表明し、おかしなことに 上記の私の注意を引いたのと同じステップを強調した ：
MD5cryptは、パスワードとソルトをさまざまな組み合わせでハッシュして、評価速度を低下させます。アルゴリズムの一部のステップでは、スキームが暗号化の観点から設計されたことが疑わしくなります。たとえば、ある時点でのパスワード長のバイナリ表現によって、どのデータがハッシュされるかが決まります。ゼロビットごとに、パスワードの最初のバイトとセットビットごとに、以前のハッシュ計算の最初のバイト。
しかし、これはあなたが尋ねる新しい関数の動機を説明していると思います：それらは、現代のパスワードハッシュ関数のほとんどに先行する古い関数のごくわずかな変更であり、その設計は問題にされていますが、根本的に壊れていない可能性が高いです、ただ無意味に複雑です。
SHA-2ファミリ自体は必ずしも悪いわけではありません。設計上、bcryptまたはscryptを推奨するセキュリティ上の欠陥は実際にはありません。ただし、多くのセキュリティ専門家がSHA=に関して持っている問題は、それが速すぎて多くのメモリを必要としないことです。それと比較して、scryptのようなハッシュ関数ははるかに遅くて高価です。話す。
Scryptは、計算に適切な量のメモリを必要とします。このすべてのメモリに加えて、主に大量のメモリが必要な結果として、scryptはSHAと比較して多くの計算時間を必要とします。 BitCoin Stack Exchangeサイトからのこの回答は、scryptの利点をかなりうまくまとめています： scrypt（）のどの機能がTenebrix GPUを耐性にしていますか？ 本質的に、scryptは低速でメモリを集中的に使用するように設計されています。 GPUはそれを好まない。 GPUは通常、scryptの計算に必要なすべてのメモリを格納するためのメモリ容量がなく、実行ブロックメソッド（を使用する必要はありません。共有メモリは一度に1つ）、したがって、GPUは処理時間の点でCPUよりも大きなメリットを提供できません。 Bcryptも同様です。
Bcryptは、パスワードハッシュに使用されています。それは17年前から存在し、それでも仕事は完了しています。ただし、ある日、GPUテクノロジは、CPUよりも高速かつ効率的にbcryptを計算できるようになるでしょう。テクノロジーは常に進化および発展しているため、最終的には発生します。その日が来ると、bcryptはパスワードハッシュにとってそれほど優れた選択肢ではなくなり、暗号技術者やセキュリティ専門家は、bcryptを既存のbcryptよりも低速でメモリ消費量の多い同様のアルゴリズムに置き換える必要があります。多分それは暗号化されるでしょう、しかし誰が言うべきか。では、なぜSHAが嫌われるのでしょうか？
SHAは一般に、セキュリティ上の欠陥のためではなく、GPUに実装される速度とその能力のために推奨されません。無制限のマシン/計算能力を持つ人は、SHA、bcrypt、scryptなど、あらゆる種類のハッシュアルゴリズムを解読できますが、これは理論的なものです。実際には、攻撃者はハッシュを解読しようとするマシンの数に制限はありません。その結果、攻撃者の速度を落とすほど、パスワードを解読することが難しくなります。すべてに予算の制限があり、パスワードの解読も例外ではありません。攻撃者は、予算が許す限りの速さでパスワードを解読することができます。 （予算内で購入できる最高のテクノロジー、そのテクノロジーを実行するためのコスト（電気代など））もちろん、 SHAの複数ラウンドを実装して攻撃者を大幅に減速させるが、その時点でbcryptを使用しないのはなぜですか？とりわけ、GPUテクノロジーが近い将来に進歩するにつれて、さらに追加する必要があります。 SHA計算をより多くのラウンド/反復で計算すると、bcryptよりも遅くなるまで遅くなります。ただし、GPUテクノロジーが進歩するにつれ、bcryptは段階的ではなく、GPUがテクノロジーにより、bcryptを効率的に計算できます。したがって、SHAが安全でないためではなく、SHAは計算効率が高すぎるためです。
Bcryptの機能の1つは、非常に遅いアルゴリズムであることです。この速度低下により、ブルートフォース攻撃に対するセキュリティが強化されます。しかし、同じ理由で、高負荷のマシンはログインごとにその重い計算を行わなければならないため、これは、たとえば、高度に使用されるWebサーバーには最適なソリューションではない可能性があります。
しかし、あなたのシステムがそれを受け入れることができる限り、その追加の時間は実際に総当たり攻撃を悩ませます。