私は最近、パスワードを20文字以上に設定するようにとの勧告を受けました。暗号化に使用されるアルゴリズムは、256ビットの主キーを持つAESです。暗号化されたファイルを解読するためのブルートフォース攻撃に対する8文字のパスワードはどのくらい安全ですか?
これは、ほとんどのWebサイトで適切なパスワードサイズと見なされています。この理由の1つは、3回程度の試行後に攻撃を停止できることです。
これは興味深い記事です http://www.lockdown.co.uk/?pg=combi&s=articles 異なる長さとシンボルセットに対してパスワードをブルートフォースで強制するのに理論的にどのくらい時間がかかるかを詳しく説明しています。
そのポリシーを書いた人に Bruce Schneierからのこのブログ投稿 を指摘したいと思うかもしれません。
これは、パスワードの強度がWeb上の誰の問題でも最も少ない理由の良い記事です。
この投稿 で受け入れられた答えを見てください。全範囲の文字を使用した8文字のパスワードでも、解読に最大10,000年かかる可能性があることを示しています。
Rainbowテーブルの使用をブルートフォース(意見はさまざまです)として数えると、8文字の場合、パスワードにすべての文字を含むRainbowテーブルを使用して約10秒です。 20文字のパスワード(同じ文字、同じRainbowテーブル)、30秒未満。問題は、テーブルの生成にlong時間かかることです。鉱山は、3GHzのマシンで処理するのに夜間だけ生成するのに約1か月かかりました。一方、それを行う必要があるのは一度だけです。
長いパスワードを思い出そうとする問題は、文字の置換とフレーズの使用を組み合わせることで簡単に解決できます。 "#Fr3ddy M3rcury#"のような単純なものでも、ほとんどの用途には十分に複雑ですが、覚えることは非常に簡単です。
8文字のパスワードが記憶される場合があることを考慮してください。 20文字のパスワード予定書き留めます。
そして、誰かがそれを読むことができます。
「 パスワードvsパスフレーズ 」という記事に興味があるかもしれません。彼らの結論は、9文字完全にランダムのパスワードは、6ワードのパスフレーズとほぼ同等であるということです。しかし、6ワードのフレーズの方が覚えやすいと感じています。
これは、使用する文字の組み合わせによって異なります。これにより、組み合わせの数が変わります。 8文字を想定:
辞書の単語:
egrep "^。{8} $"/usr/share/dict/words | wc -l 15601
小文字:268 または208827064576
小文字と大文字:528 または53459728531456
下、上、数字:628 または218340105584896
句読点やその他の記号を追加すると、ブルートフォースには時間がかかります。
これらの数字は、試さなければならない組み合わせの合計です。明らかに、ハッカーはパスワードを取得した後ですべての組み合わせを試すことはないので、必要な組み合わせの平均数を取得するには、2で割ります。
ハッシュが硬いほど、ハッシュを計算するためのCPU時間は長くなるため、合計時間は長くなります。ジョンの例:
ベンチマーク:従来DES [64/64 BS] ...完了 多くの塩:819187 c/s実数、828901 c/s virtual 1つのソルトのみ:874717 c/s実数、877462 c/s virtual ベンチマーク:BSDI DES(x725)[64/64 BS] ...完了 多くのソルト:29986 c/sリアル、30581 c/sバーチャル 1つのソルトのみ:29952 c/sリアル、30055 c/sバーチャル ベンチマーク:FreeBSD MD5 [32/64 X2] ...完了 生:8761 c/s実数、8796 c/s仮想 ベンチマーク:OpenBSD Blowfish(x32)[32/64] ...完了 生:354 c/s実数、356 c/s仮想 ベンチマーク:Kerberos AFS DES [48/64 4K] ...完了 ショート:294507 c/sリアル、295754 c/sバーチャル ロング:858582 c/sリアル、863887 c/s virtual ベンチマーク:NT LM DES [64/64 BS] ... DONE Raw:6379K c/s real、 6428K c/s virtual ベンチマーク:NT MD4 [Generic 1x] ... DONE Raw:7270K c/s real、7979K c/s virtual [.__ __。]ベンチマーク: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回の試みの後に攻撃者を止めることができるとき(彼らがウェブアプリケーションのようにネットワーク経由で攻撃するとき)。このシナリオでは、ほとんどどのような長さのパスワードでも十分と主張できます。
ただし、インサイダーがハッシュされた短いパスワードでこのデータベースを取得し、「ネット越し」の3回の試行制限を回避できる場合、ゲームは変わります。
アカウントあたりの試行回数を制限する際の注意点は、これは1つの特定のアカウントでの対象を絞った試行に対してのみ十分であることです。また、特定の(または置換された)パスワードを使用するすべてのアカウントに対する攻撃から保護する必要があります。これは、アカウントごとの試行回数を制限しただけでは、アラームをトリガーしません。今日のNAT=およびボットネットを考えると、IPあたりの試行回数を制限することはセキュリティを考える良い方法であるとさえ主張することはできません。
読書のための優れたリソースは、すでに他の回答で提供されています。