web-dev-qa-db-ja.com

どちらが速いですか-総当たり、またはすべての可能な置換を含む辞書攻撃を使用していますか?

6文字のパスワードがmixalphanumeric文字セットを使用し、各文字に62の文字セットを与え、パスワード全体に62 ^ 6 = 46.6 billionのキースペースを与えると仮定します(私の計算が正しい場合)...

パスワードをブルートフォースで強制するか、ディクショナリにキースペース全体を生成し、そのディクショナリをディクショナリ攻撃に使用する方が速いでしょうか?

2つのアプローチは同等と見なされますか、それともパフォーマンスに違いがありますか?後者はしばしば行われますか?そうでない場合、なぜそうでないのか、もしそうであれば、なぜそれがより一般的ではないのですか?

上記の例はそれだけであり、特定のパスワードのキースペースや実際にかかった時間に関係なく、2つの方法に関するパフォーマンスに関する質問です。

7
Hashim

実装に入るまで違いはありません...

HashcatやJohn the Ripperなどの効率的なクラッキングプラットフォームは、最適化を使用してGPU/CPUでブルートフォースを直接実行します。

真のブルートフォースおよび関連する攻撃(マスクベースの攻撃やルールベースの攻撃など)は、純粋な辞書攻撃よりも常に高速である必要があります。

更新:私の答えは高速ハッシュに適用されます。パスカルは、ハッシュが十分に遅い場合、それは同じであろうと彼の答えで正しいです。

10
Royce Williams

有意義な回答では、パスワードを保護するためにどのハッシュ関数が使用されたかなど、いくつかの詳細を考慮する必要があります。

「111111」で始まり、「zzzzzz」で終わるすべての可能なパスワードの組み合わせの辞書を作成した場合(大文字、小文字、数字のみを想定)、しないでくださいこの辞書を並べ替えますパスワードの可能性によって、しかし辞書式順序でそれを維持した場合、質問はどちらがより速くなりました-これらの辞書文字列をあなたのパスワード推測器に与えるか、またはパスワード推測者にその場で組み合わせを作成させる。

その質問に答えるには、辞書をどこに格納するかを知る必要があります。辞書は、メモリに完全に収めることができないほど大きいため、ハードドライブに格納する必要があります。

また、ハードドライブ(磁気ディスク、回転ディスクのバリエーション)のアクセス時間がミリ秒の範囲であることを理解することも重要です。 RAMは桁違いに高速ですが、CPUでの直接レジスタアクセスよりもはるかに遅いL1キャッシュと比較すると依然として低速です。残念ながら、汎用CPUレジスタは、128バイトしか格納できません。 L1キャッシュは合計で数KBしか保存しません。

ここでも、使用するために8 GBのメモリが設定されているコンピューターを使用していると仮定すると、約10億の辞書エントリをRAMに同時に保持できます。これは約2%です。キースペース全体。

ハードドライブから辞書をロードした場合、合計325ギガバイトのデータをロードする必要があります(ジャンクではそれぞれ4 GB程度)-他の4 GBのパスワードを試す間は常に4 GBのパスワードをロードします)。 SSDを使用する場合でも、しばらく時間がかかります。

今、md4のようなハッシュ関数を扱っている場合、hashcatは次のバッチをロードする前に候補のパスワードを簡単に使い果たしてしまいます。なぜなら、最新のGPUでは文字通り毎秒数十億のパスワードをテストできるからです。実際には、ハードディスクから高速な候補パスワードをロードすることはできません。一方、bcryptのようなハッシュ関数で暗号化されたパスワードを攻撃しようとした場合、ハードドライブから候補のパスワードをロードしても、パスワードを攻撃するのに必要な時間は短縮されません。これは、最新のGPUでもできないためです。次の5億をハードドライブからロードする前に5億の候補を使い尽くすほど高速なbcrypt。

RAMに大きなチャンクでパスワードをロードする代わりに、オンザフライでパスワードを作成する方が高速であるかどうかを見てみましょう:

CPUにはいくつかの興味深い特性があります。たとえば、命令のプリフェッチ、分岐予測、一時的な実行を使用して、コードを実行する必要があるかどうかが実際にわかる前にコードを実行します。これは、CPUキャッシュとともに、特定のビット長のすべての可能な組み合わせを列挙するコードなど、非常に小さくてタイトなコードを実行した場合、基本的に完全にCPUで実行でき、RAMに触れないことを意味します。 。小さなパスワード(6〜8バイト)は1つのCPUレジスタに簡単に収まり、16バイトのパスワードは2つのレジスタに収まります。最後のパスワード候補から次のパスワード候補を生成するコードは、「add」命令を使用するのと同じくらい簡単です。これは、最も高速なCPU命令の1つです。したがって、すべてのパスワードの組み合わせを、外部ソースからそれらのリスト全体をロードするよりもはるかに速く生成できると私はかなり確信しています。

しかし、繰り返しになりますが、CPU(またはGPU)がハッシュされたパスワードと比較するために実際のbcryptハッシュを計算する必要がある時間は、候補のパスワードを生成するために必要な時間を短縮します。

したがって、パスワードを生成する方法は、十分に保護されたパスワードにとってはそれほど重要ではありません。 md4、md5、sha1などの弱いまたは非常に高速なハッシュ関数を処理する場合にのみ問題になります。

結論

すべてのパスワードが同等である可能性が高いと想定している場合、ハードドライブに膨大な辞書を保持する必要がないため、すべてのパスワードをオンザフライで逐次生成(ブルートフォーシング)する方が理にかなっています。オンザフライですばやく作成できます。これが、愚かなブルートフォースのために、ハードドライブにソートされていないパスワード辞書を保持しない理由です。

一方、一部のパスワード( "123456"と "password"は他のパスワードよりも似ている( "1qHGmR"と考える))と認めた場合、これらのパスワードのディクショナリを作成し、そのディクショナリをRAMにロードし、おそらくいくつかのパスワードを使用します。基本的な辞書エントリ「sarah」から「sarah1997」や「sarah1998」などの派生物を作成するルールは、ほとんどの場合ずっと高速になるため、進むべき道です。

とは言っても、実際に6文字のパスワードと弱いハッシュ関数を扱っている場合は、どちらの方法でもそれほど問題になりません。hashcatと同族は、分、時間、または日単位でブルートフォースによって6文字のキースペースを使い果たす可能性があるためです。 、使用されるハッシュ関数と利用可能なGPUリグの能力に応じて。

4
Out of Band

実装の観点から見ると、ルックアップテーブルを1つずつ実行するのではなく、ブルートフォースを実行していることを認識するアルゴリズムを使用する方が早いと言えます。前者に存在します。

アルゴリズムは、各試行のルックアップ(ディスク読み取りまたはRAM読み取り)のための1つの追加のステップよりも、ネストされたループを含むコードでブルートフォースを実行する方が速くなります。

2
Wadih M.