回答:
これは興味深い記事であり、http：//www.lockdown.co.uk/？ pg = combi＆s = articlesでは、長さや記号セットが異なる場合にパスワードをブルートフォースでブルートフォースにするのに理論的にどのくらいの時間がかかるかが詳しく説明されています。
Bruce Schneierからのこのブログ投稿で、そのポリシーを書いた人を指摘したいと思うかもしれません。
これは、パスワードの強度がWeb上の誰の問題でも最も少ない理由の良い記事です。
レインボーテーブルの使用をブルートフォース（意見はさまざまです）として数えると、8文字の場合、パスワードにすべての文字を含むレインボーテーブルを使用して約10秒です。20文字のパスワード（同じ文字、同じレインボーテーブル）、30秒未満。問題は、テーブルの生成に長い時間がかかることです。鉱山は、3GHzのマシンで処理するのに、夜間にのみ1か月かかりました。一方、それを行う必要があるのは一度だけです。
長いパスワードを思い出そうとする問題は、文字の置換とフレーズの使用を組み合わせることで簡単に解決できます。"＃Fr3ddy M3rcury＃"のような単純なものでも、ほとんどの用途には十分に複雑ですが、覚えることは非常に簡単です。
8文字のパスワードが記憶される場合があることを考慮してください。20文字のパスワードが書き留められます。
そして、誰かがそれを読むことができます。
「パスワードとパスフレーズ」という記事に興味があるかもしれません。彼らの結論は、9文字の完全にランダムなパスワードは、6ワードのパスフレーズとほぼ同等であるということです。しかし、6ワードのフレーズの方が覚えやすいと感じています。
組み合わせの数が変わるため、使用する文字によってすべて異なります。8文字を想定：
辞書の単語：
egrep "^。{8} $" / usr / share / dict / words | wc -l
15601小文字：26 8または208827064576
小文字と大文字：52 8または53459728531456
下、上、数字：62 8または218340105584896
句読点やその他の記号を追加すると、力ずくの強制にはしばらく時間がかかります。
これらの数字は、試さなければならない組み合わせの合計です。明らかに、ハッカーがパスワードを取得した後ですべての組み合わせを試すことはないので、必要な組み合わせの平均数を取得するには、2で割ります。
ハッシュが硬いほど、ハッシュを計算するためのCPU時間は長くなるため、合計時間は長くなります。ジョンの例：
ベンチマーク：従来のDES [64/64 BS] ...完了 多くの塩：819187 c / s実数、828901 c / s仮想 1つのソルトのみ：874717 c / s実数、877462 c / s仮想 ベンチマーク：BSDI DES（x725）[64/64 BS] ...完了 多くの塩：29986 c / sリアル、30581 c / sバーチャル 1つのソルトのみ：29952 c / s実数、30055 c / s仮想 ベンチマーク：FreeBSD MD5 [32/64 X2] ...完了 Raw：8761 c / s実数、8796 c / s仮想 ベンチマーク：OpenBSD Blowfish（x32）[32/64] ...完了 Raw：354 c / sリアル、356 c / sバーチャル ベンチマーク：Kerberos AFS DES [48/64 4K] ...完了 ショート：294507 c / sリアル、295754 c / sバーチャル ロング：858582 c / sリアル、863887 c / sバーチャル ベンチマーク：NT LM DES [64/64 BS] ...完了 Raw：6379K c / s実数、6428K c / s仮想 ベンチマーク：NT MD4 [Generic 1x] ...完了 Raw：7270K c / s実数、7979K c / s仮想 ベンチマーク：M $キャッシュハッシュ[汎用1x] ...完了 多くの塩：12201K c / s実数、12662K c / s仮想 1つのソルトのみ：4862K c / s実数、4870K c / s仮想 ベンチマーク：LM C / R DES [netlm] ...完了 多くの塩：358487 c / sリアル、358487 c / sバーチャル 1つのソルトのみ：348363 c / s実数、348943 c / s仮想 ベンチマーク：NTLMv1 C / R MD4 DES [netntlm] ...完了 多くの塩：510255 c / sリアル、512124 c / sバーチャル 1つのソルトのみ：488277 c / s実数、489416 c / s仮想
もちろん、これはすべて完全にアカデミックです。ハッカーはあなたの秘書に電話をかけて、IT出身であり、何かのためにパスワードが必要であり、強力なパスワードは無価値であることを伝えるだけです。
自明ではないパスフレーズを使用して保護する
*重要な資産 * ハンマー対策の対象にならないもの（繰り返し試行した後のロックアウト） *力ずくの/辞書ベースの/ハイブリッド攻撃にさらされる可能性があるもの
私のGmailアカウントについてはあまり気にしていません。そのパスワードをクラックしようとブルートフォースに試みると、アカウントがロックされるだけです（そして、サーバーにアクセスできる人は、ハッシュを自分で選択したものに置き換えるだけで、クラックしようとはしません）。
最適なパスフレーズは長く（> 12文字）、暗号的にランダムです。ただし、それらを覚えるのはより困難です。したがって、複数の単語と一見ランダムな文字を組み合わせたパスフレーズは、適切な妥協案かもしれません（おそらく、お気に入りの曲の歌詞の最初の数行の最初の1文字または2文字）。
たとえば、前述のように、3回の試行後に攻撃者を阻止できる場合（Webアプリケーションのようにネットワーク経由で攻撃する場合）は、クライアント/サーバーの通信から得られるセキュリティがあります。このシナリオでは、ほとんどどのような長さのパスワードでも十分と主張できます。
ただし、内部関係者がハッシュ化された短いパスワードでこのデータベースを取得し、「オーバーネット」の3回の試行制限を回避できる場合、ゲームは変わります。
アカウントあたりの試行回数を制限する際の注意点は、これは1つの特定のアカウントでの対象を絞った試行に対してのみ十分であることです。また、特定の（または置換された）パスワードを使用するすべてのアカウントに対する攻撃から保護する必要があります。これは、アカウントごとの試行回数を制限しただけでは、アラームをトリガーしません。今日のNATとボットネットを考えると、IPあたりの試行回数を制限することがセキュリティを考える良い方法であるとさえ主張することはできません。
読書のための優れたリソースは、すでに他の回答で提供されています。