ハッシュの反復を増やすのではなく、長いパスフレーズを好むのはなぜですか？
オフラインパスワードのブルートフォーシングに関しては、 長くても単純なパスワードの方が短く複雑なパスワードよりも優れている という合意があるようです。最近、GPGで 暗号化の反復回数を増やす に関連する質問を目にしました。たとえば、他のオプションでは速度を落とすことになるため、代わりに強力なパスワードを考え出すことを提案する人もいるようですARMの実装。反復回数を増やさず、パスワードを短くすることについて他に議論はありますか？
1つのサンプルアイデア：定義上、アルゴリズムはレインボーテーブルを作成し、それらを使用してメッセージを復号化することに問題がないことを公に知っているためです。反対側から、長いパスワードのためにそのようなテーブルを構築することは、ほとんどの場合実行可能/不可能です
ブルートフォーシングは、文字列内の文字の種類を推測することを中心に展開されます。次のクラスで5文字のパスワードを想定します。-小文字の英字（26）-大文字の英字（26）-0から9までの数字（10）
これにより、ポジションごとに合計62のオプションが得られます。つまり、次のようになります。
62 x 62 x 62 x 62 x 62 = 916 132 832
916 132832可能な組み合わせ。次に、もう1文字追加します。
62 x 62 x 62 x 62 x 62 x 62 = 56 800 235 584
文字が追加されるたびに対数的に増加します。この場合、さらに急なジャンプになるシンボルはカウントしていません。 7文字のパスワードを推測するのに10時間かかる代わりに、8文字のパスワードを推測するのに40日かかる場合があります。
ブルートフォースを使用してパスワードを推測する場合、通常、長さや関連するクラスがわからないため、記号も試してみる必要があります（できれば強調されていない文字）。今日の処理能力をもってしても、デスクトップコンピュータでは、これらすべての組み合わせを試すのにかかる時間は通常、多すぎます。 （私は パスワードクラッキングはここにあります 興味があればもっと投稿しました）。
パスワードをより多くハッシュすると、ラウンドごとに消費される時間が長くなります。たとえば、パスワードごとに1秒かかるのではなく、1.5秒かかるため（これも単なる例です）、攻撃を効果的に軽減します。ただし、システムにリソースの消費も追加されます。ビジーなサービスでは、より少ない認証メカニズムを実装するリスクを受け入れるのに十分な場合があります。