レインボーテーブルベースのブルートフォースの実際的な制限は何ですか？
パスワードのハッシュがあるとしましょう。パスワードは完全にランダムな文字で構成されていると見なすことができ、固定長はNです。ハッシュはSHA1（password + salt）で、ソルトの長さはMです。
レインボーテーブルベースのブルートフォース攻撃に抵抗するために、M + Nはどのくらい大きくなければなりませんか？
シナリオ＃1：攻撃者が政府などの最先端の計算リソースとストレージスペースにアクセスできることを検討します。
シナリオ＃2：機器またはクラウドベースのサービスに費やすために、攻撃者がより限られたリソース（より具体的にしたい場合は$ 10,000）を持っていることを考慮します。
関連質問：全長（M + N）が攻撃者に知られている場合、複雑さはどの程度削減されますか？
ソルトとパスワードの両方にランダムに英数字（A-Za-z0-9記号なし）を選択したとしましょう。たとえば、サンプルスペースは（62）^ M可能なソルトと（62）^ Nのパスワードです。
ファーム内に100万のGPUがあり、それぞれが1秒間に10億のハッシュを生成できるとします（単純なMD5またはSHAタイプのハッシュ-bcryptまたはPBKDFベースのハッシュははるかに遅いと仮定）。したがって、特定のソルトでは、8文字のパスワードを0.2秒（200 000 GPU秒）、10文字のパスワードを14分（26 GPU年）、37日で12文字のパスワード（100 000 GPU）解読できます。年）、150万年（1.5兆GPU年）のパスワードの16文字。
またはそれについて考える別の方法; 1秒間に10億ハッシュをクランクアウトする一般的なGPUでは約200 Wを使用します。したがって、電気代がkWHrあたり0.10ドルで、起動コストを無視すると、GPU時間は0.02ドルかかります。したがって、8文字のパスワードのコストは約$ 1、10文字の$ 4600、12文字の$ 1800万、16文字-260兆ドルです（世界のマネーサプライは約10兆ドルです）。 （そして、これは100万GPUの購入/維持のコストを無視します-電力だけです）。
レインボーテーブルについては、ある時点で作成する必要があります。したがって、4文字すべてのプレフィックス用の完全なRainbowテーブルが必要です。 8文字までのすべてのパスワード（たとえば、合計12文字のパスワード）をカバーしたい場合、10万GPU年（100万GPUの37日間）かかり、電気料金は約1,800万ドルになります。
基本的にランダムな英数字のM + N>〜12の場合、それは実行不可能になり始めます（たとえば、M + N = 16では実行不可能になります）。
編集：新しい要約表、ここにパスワードの長さとタイプをリストします（たとえば、8 A-Za-z0-9は8文字の大文字+小文字+数字のパスワードを意味します）。
google application-specific password （16個のランダムな小文字）も含まれますが、明らかにgoogleタイプのパスワードは通常、オンラインで攻撃する必要があります（GPUファームによって攻撃されるオフラインハッシュとは異なります） ）。
PW Length | # of PW | PW Entropy | GPU-time | Electricity Cost at $0.10/kW-hr
-------------------------------------------------------------------------------------------
8 A-Za-z0-9 | 2x10^14 | 47.6 bits | 60 hours | $1
10 A-Za-z0-9 | 8x10^17 | 59.5 bits | 26 years | $4 600
12 A-Za-z0-9 | 3x10^21 | 71.4 bits | 100 000 years| $18 000 000 ($18 million)
14 A-Za-z0-9 | 1x10^25 | 83.4 bits | 390 million yrs| $69 000 000 000 ($69 billion)
16 A-Za-z0-9 | 5x10^28 | 95.2 bits |1500 billion yrs|$260 000 000 000 000 ($260 trillion)
-------------------------------------------------------------------------------------------
16 a-z | 4x10^22 | 75.2 bits | 1.4 million yrs| $242 000 000 ($242 million)
この回答はあなたの質問への直接の回答にはならないので、事前に謝罪しますが、あなたが尋ねている質問が実際には学術的なものだけであることを人々に知らせるために、それを投稿したかったのです。この質問に対する本当の答えは、sha1を使用しないでください bcrypt を使用します。世界のsha1とmd5は高速になるように設計されており、高速はパスワードのハッシュに適した品質ではありません。 Bcryptは、パスワードをハッシュするのにかかる時間を設定できるように設計されているため、ユーザーが違いに気付かないほどハッシュプロセスを遅くすることができますが、攻撃者が実行するのに何桁も時間がかかります。レインボーテーブルを生成するか、ブルートフォースパスワードを使用します。 bcryptの詳細とそれを使用する理由については、この question を参照してください。
これらすべてに加えて、bcryptにはソルティングスキームも含まれています。上記の理由により、woliveirajrによって言及された20バイトのソルトが将来にわたって実行可能であると確信できます。
レインボーテーブルがあり、ブルートフォースがあります...これらは2つの異なるものです。
Rainbow table は、ハッシュされたパスワードの大きな事前計算済みテーブルの特殊なケースです。そのため、Rainbowテーブルはハッシュを「反転」することができます。つまり、テーブルの構築中のある時点で、そのパスワードが考慮されてハッシュされた場合にのみ、一致するパスワードを回復できます。これに対応して、パスワードがRainbowテーブルで見つかった場合、単純な dictionary attack でパスワードを見つけることができ、コストはテーブルの構築にすぎません。 「レインボー」はそれを変えません。実際、Rainbowのものは実際にテーブルを構築するのにより高価に約1.7倍にします（それはテーブル構築がいくつかを考慮してハッシュする傾向があるためです）同じパスワードを数回使用しますが、それは避けられません）。
結果として、少なくとも2回適用できない限り、労力に値するRainbowテーブルはありません。 saltsを正確に使用して、それが起こらないようにします。ソルトはハッシュ関数のバリアントを作成するものと見なすことができ、新しいソルトはそれぞれ新しいバリアントを意味します。事前計算されたテーブルは、攻撃されるハッシュ値と同じバリアント（同じソルト）で事前計算された場合にのみ価値があります。ソルト値が2回以上使用されない場合、インテリジェントな攻撃者はKleenex Rainbowテーブルの作成に時間を浪費しません。彼はただ辞書攻撃を実行します。
攻撃者は塩を知っていると考えます。どうして ？サーバーがそれを知っているため、攻撃モデルは、攻撃者がサーバーデータベースのダンプを取得する可能性があるためです。サーバーが知っていることは何でも、攻撃者も知っています。したがって、ハッシュされたパスワードを攻撃する場合、ソルトの長さや内容は重要ではありません（攻撃者はソルト値を計算に含める必要がありますが、ソルト長を指定しないとタスクが簡単または難しくなります）。
したがって、私たちは防御線としてのみパスワードを持っています。攻撃にかかるコストを知りたい場合、これは経済的になり、そのため、ある程度の複雑さが生じます。特に、oneの後の攻撃者について話しているのかどうかを知りたいです。地球を消滅させようとしているエイリアンの力）、または多くのパスワードを破って生計を立てる攻撃者。後者の場合、ハードウェアコストは電力消費に関して無視できるほどになります。
@jimbobの推定を採用すると、10を計算するハードウェア9 1秒あたりのハッシュは200W相当の電力を使用し、電力はkWhあたり$ 0.1になります（電力コストには冷却が含まれます。計算に費やされるすべてのワットも熱になり、何らかの形で放散される必要があります）。これにより、1.8 * 10が得られます14 ドルあたりのハッシュ値。その結果、以下を取得します。
10,000ドルで、攻撃者は1.8 * 10を試すことができます18 ハッシュ値。これは多かれ少なかれ10文字の英数字（大文字、小文字、数字）の可能なパスワードの数です。
6837億ドル（つまり 2010年の米軍の総予算 ）で、攻撃者は約1.23 * 1026日 約14.5文字の英数字に対応するハッシュ値。この数字は、約100基の原子力発電所の年間出力に対応しているので、クラッキングの努力はほとんど目立ちません。
結論：ランダムな15文字の英数字を使用すると、SHA-1の単一の呼び出しを使用してハッシュを完全に失敗させたとしても、パスワードは信じられないほどの敵にも抵抗します、 bcrypt または PBKDF2 を使用する代わりに、高い反復回数を使用する必要があります。これはrandom文字にのみ有効であり、あなたの脳のプライバシーで思いつくかもしれない種類の文字にはまったく有効でないことに注意してください。人間の脳はまったくランダムではありません。
レインボーテーブルは、CPU時間とストレージの間のトレードオフを表すため、理論的にはこの質問に対する答えはわかりません。それはあなたの攻撃者が好むトレードオフのどちら側に依存します：彼らが利用可能なCPU時間をたくさん持っている場合、新しいソルト値に遭遇すると攻撃者は新しいテーブルの計算を開始できるため、実質的に価値がありません（この極端は攻撃者は、事前に計算されたテーブルを使用せずに、キーをブルートフォースで強制できます。大量のストレージがある場合は、ソルトの任意の値についてテーブルを事前計算できますが、時間がかかるため、大きいほど良いです。
もちろん、理論上機能しないものは、実際には非常によく機能します。この時点で現実の世界が感染し、多くの攻撃者にとって、ストレージとCPU時間の両方が制限されていることがわかります。ソルトが長いほど、攻撃を成功させるためのリソースを持たない攻撃者が増えます。その関係を受け入れると、ソルトサイズの選択に上限を提供する不等式があります。
ソルトハッシュを処理するために必要なリソースの合計は、アプリケーションの他の要件を満たすために必要なリソースよりも少なくなければなりません。
これは私の理解です。とにかくこれが間違っているとすみません。
パスワードにソルトを使用すると、ほとんどの場合、レインボーテーブルが攻撃にほとんど役に立たなくなります。パスワードの長さPとソルトの長さSでは、単純なブルートフォースルックアップでスペースP * Sが必要になります（ランダムなソルトを追加してSを追加する必要があります各パスワードの表）。レインボーテーブルは、パスワードのルックアップを保存するために必要なスペースを削減しますが、Sによる乗算を排除しません（私のUniの計算は、正しい Big O表記）を与えるのに十分ではありません ;それは読者のための練習になります：P）。
計算は、受け入れられる文字セット（c）の長さを、パスワードの長さ（p）に可能な塩の数（s）。
(c^p) * s
言うまでもありませんが、これは非常に急速に非常に大きな数になる可能性があります。
シナリオ1
政府は、レインボーテーブルを使用してパスワード+ソルトスキームを破るのに適した大きなシステムを構築できますか？これは、パスワードのサイズ、使用可能な文字セット、ソルトサイズによって異なります。特定のサイズを超えると、物理的な限界に達し始めます（実際の問題/エネルギーを使用して、デバイス上のすべての順列を実際にエンコードできますか？）。多くの場合、政府はほとんどの機関よりも多くのリソースを持っていますが、これらの物理的な限界を使い果たすことはできません。
これを回避する唯一の方法は、直感または事前知識を使用して、検索スペースを減らすことです。一般的に使用されているシステムの場合、人々のパスワードは一定の長さを下回るため、わざわざチェックするだけです。また、使用可能な文字セットのサブセットのみを使用する可能性もあります。これらを使用して、Rainbowテーブル（pおよびc）の入力に使用されるハッシュを集中させることができます。しかし、ランダムなソルト（s）を掛けるという事実に常にぶつかります。
あなたはランダム塩を持っていますか？これは、人々が乱数のエントロピーについて心配し始めるところです。実際のランダムデータが必要な場所で非ランダムデータが使用されている場合、悪用するのはかなり困難ですが、これは、データが関係する状況の1つです。パスワードの性質について直感的に（p ^ c）を削減できた前の問題を考えてみましょう。塩がどの程度「ランダム」であるか（または何らかの形で塩に影響を与える可能性がある）ことがわかっている場合は、sのサイズを小さくし始めることができます。 sが特定の値のセットの間にあることがわかっている（または影響する可能性がある）ため、Rainbowテーブルの順列を大幅に減らすことができます。攻撃者がこれを妥当な物理的制限未満に取得できる場合、政府（そのような傾向があった）はRainbowテーブルを使用してパスワードを解読する可能性があります。
（私はこれがあなたの関連する質問にも答えたことを願っています）
シナリオ2
現在の2012年のレベルでは、信じられないほど幸運でない限り、パスワード+ソルトハッシュ（実装の技術的な弱点を無視）を信じられないほどスリムにできる可能性があります。これは、p、c、およびsに適切な長さを使用することを前提としています。
参照 http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-Rainbow-tables-what-you-need-to-know-about-s.html =と http://www.codinghorror.com/blog/2007/09/Rainbow-hash-cracking.html この問題についての興味深い読み物について（ほぼ間違いなく使用し、乱用してきた） 。