パスワードの強度、不十分なパスワードポリシー、またはパスワードポリシーがないことで何が悪いのですか？
最近、私は Twitter で次のスクリーンショットを見て、明らかにひどいパスワードポリシーについて説明しました。
パスワードの強度は何が悪いのでしょうか。パスワードポリシーをまったく持っていないか、（スクリーンショットで説明されているように）不十分なパスワードポリシーを持っていますか？
問題は、何が悪いのか？
投稿したポリシーでは、可能なパスワードは64⁸（〜2.8 *10¹⁴）未満です。実際には、非常に多くのパスワードは、おそらく[a-z] * 6 [0-9] [special char]（たとえば、aabaab1！）および類似のパスワードになります。
同じ文字を使用し、長さが8未満のすべての可能なパスワードは、64⁶+64⁵+ 64 ... + ...であり、これは〜4.5 * 10〜²です。これは、長さが8のパスワードよりもはるかに少ないため、許可してもセキュリティはそれほど向上しません。 （長いパスワードを許可すると、明らかにセキュリティが大幅に向上します）
ポリシーがないと、多くの人が不正なパスワードを使用することになります。しかし、攻撃者はそれについて確信が持てません。また、より良いパスワードを使用する人もいます。
ポリシーがないと、攻撃者はパスワードを解読するのがどれほど難しいかは決してわかりません。パスワードハッシュのDBをくれたら、私はそれを解こうとするかもしれません。しかし、結果がない場合は、しばらくすると停止する可能性があります。ポリシーが適切に設定されていれば、64 ^ 8回の試行後にすべてのパスワードを確実に取得できます。
悪いパスワードポリシーはもっと悪いと思います。しかし、それは攻撃シナリオに依存します。
パスワードハッシュのダンプを使用すると、パスワードポリシーがないため、パスワードを解読するのは簡単ですが、ほとんどのパスワードを解読することは困難です。与えられたような悪いポリシーでは、すべてのパスワードを解読するのは簡単ですが、最初のパスワードを解読するのは少し難しいでしょう。
自分のパスワードを解読することがどれほど難しいかが懸念される場合は、ポリシーなしで、必要に応じて安全な20文字のランダムパスワードを使用できます。ポリシーを設定すると、安全でないパスワードを使用せざるを得なくなります。 （実際には、パスワードの保存方法などがより重要ですが、ここでは範囲外です）。したがって、ウェブサイト/サービスのユーザーとして、不適切なパスワードポリシーははるかに悪いものです。
組織の観点から見ると、不正なパスワードポリシーは何もないよりもはるかに悪いです。
パスワードポリシーがないということは、おそらく誰もそれについて考えていないことを意味します（セキュリティについて考えていないことはあまり良くありませんが、大丈夫です...）
しかし、不適切なパスワードポリシーは、次のことを意味します。誰かがそれについて考えましたそして、そのがらくたを思い付きました。これは、おそらくセキュリティについての手がかりがないことを意味します。
結局、悪いパスワードポリシーを実装できる場合は、良いものを実装することもできるので、悪いパスワードポリシーの言い訳はありません。ポリシーを「パスワードは8文字以上にする必要があります」に変更するだけで、セキュリティが大幅に向上し、難しくありません。
今、私はパスワードの強度にとって何が悪いか疑問に思っています。パスワードポリシーをまったく持っていないか、写真のように貧弱なパスワードポリシーを持っていますか？
あなたが言及したパスワード強度の要件絶対に良いよりも害を及ぼす、特に最大長。
- 彼らは非常に古い、安全でないハッシュルーチンを使用している可能性があります。 （したがって最大長）
- 特定の領域では、これはセキュリティよりも便利です。
（パスワードをプレーンテキストで表す場合、スペースは不要です。
大文字と小文字を区別しないので、caps-lockサポート呼び出しはありません） - 他のアイテムは単なるばかげています。
詳細な内訳
パスワードは：
- 正確に8文字の長さ
これを妥当な解決策と見なすことができるのは、システムが最初の8文字以外をすべて切り捨てるレガシーハッシュ方式を実行しているときだけです。
たとえば、Solaris 10のユーザーアカウントのパスワードはデフォルトでこのようなスキームを使用していたため、passwordSup@rsecur☺のようなパスワードはpassword !!!に切り捨てられました。 Solaris 11のデフォルトには、この欠点はありません。
この場合
開発者は、8文字を超えるパスワード長をサポートする、より優れたハッシュルーチンへの移行に取り組んでいる必要があります。
そのような修正がロールアウトされるまで、最大長は正気です。
それ以外の状況では、最大長をこのように短くすることは間違いなく愚かです。
少なくとも1つの文字と1つの数字を含めます。
次のセットから少なくとも1つの特殊文字を含めます：...
これらは短い最大長を与えられた必見です。短いパスワードを使用する場合に、このようなプリミティブメソッドを使用してエントロピーを増やす必要性を理解できると思います。
- 注：パスワードでは大文字と小文字は区別されません。
これはユーザーにとっては便利な場合がありますが（caps-lockについて心配する必要はありません）、パスワードのエントロピーが常に減少するため、推奨されません。この場合、最大長が8文字であるため、これはさらに推奨されません。
これは修正する必要がありますbutこれで、既存のユーザーは安全でない構成にすでに慣れているため、問題が発生します。
スペースを含まない
私がこれを見る唯一の理由は、彼らがパスワードをプレーンテキストで提示している場合です。 （つまり、パスワードの電子メールを忘れたか、技術サポートの検索）ほとんどの標準では、貧弱な（安全ではない）ソフトウェア設計です。
より良いポリシーは、検索を禁止し、変更のみを許可することです。実際、コアデザインの一部としてルックアップを本質的に禁止するBCryptなどの強力な（遅い）パスワードハッシュを使用することを強くお勧めします。
?または!で始まらない
非常に奇妙ですが、パスワードエントロピーの大きなキラーではありません。
- 3つの同一の文字で始まっていない
えっと、これについてはあまり気にしていませんが、なぜ彼らが最初だけを見ているのでしょうか。 8文字のパスワードのどこかにある3つの同一/隣接文字は、それよりも弱いです。
- パスワードは、以前の5つのパスワードとは異なる必要があります。
この問題については、おそらくセキュリティスタック交換専用の質問があります。これは、オンラインバンキングやその他の特定の認証システムでは一般的な方法です。
これは、必須のスケジュールされたパスワードの変更と連動していると思います。考えられる結果は次のとおりです。
- ユーザーはメモリを使用する代わりにパスワードを書き留めます
- または、ユーザーは単純なパターンを選択します。
ただし、パスワードの変更が必須ではない場合、唯一の問題は
- 比較を機能させるには、未使用のパスワードのハッシュ値を引き続き保存する必要があります。
それは深刻な問題ではありませんが、眉をひそめています。
このような悪い政策は、どれよりも悪いです。
このポリシーは、通常「123」を使用している人々がもう少し安全なパスワードを持っていることを意味しますが、それでもまだ弱いです。また、「fzFEZ＃5 $ 3rt4564ezezRTyht」（ランダムに生成された）、または単に「茶色の塗られた壁412上の猫j_umps」（強力なエントロピー）などを使用している人々は、はるかに弱いパスワードを持つことになります。
いずれにしても、弱いパスワードを使用している人々はこの場合もハッキングされます（この制限された弱いポリシーと攻撃者が特定の攻撃ルールを設定できるため）。しかし、通常は強力なパスワードを使用している人々もそうします。
つまり、安全性が大幅に低下します。ポリシーがないと、脆弱なパスワードを使用している人だけが脆弱になります。今、誰もが脆弱です。
私の意見では、何もない方が良いでしょう理由のリストは次のとおりです：
- これらのポリシーにより、人々はパスワードを書き留めて、モニターなどに貼り付ける傾向があります。 （パスワードは提供するよりもどのようなセキュリティですか？）
- これらのルールは簡単に推論され、（これらのタイプのボックスを使用することにより）潜在的な侵入者に通知されます。 （同様に、パスワードがどのようになっているのかについての「ルール」を禁止したい人に、限られたセットを実行するだけでよいようにしてみましょう...）
- パスワードのエントロピーは、長くすることで大幅に向上します。 8は、攻撃がモバイルデバイスを使用してパスワードをブルートフォースする可能性があるほど、今日では簡単です。
- 大文字と小文字を混ぜてチェックしないというルールは、パスワードがプレーンテキスト形式で開始されることを示唆しています（ストレージが暗号化されている場合でも、ほとんどの場合、暗号化キーはデータと一緒に保存されるため、クリアテキストで保存されます） 。
- ほとんどのアプリケーションでは、次のように、別のスキーマを使用すると、パスワードをまったく要求せずにはるかに優れたセキュリティを実現できます。
- 2要素認証。
- セカンダリデバイス認証。
- スマートカード認証。
これらのポリシーは、パスワードに対する脅威がシステムに与える影響を完全に理解していない人によって考えられているようです。代わりに、何らかの理由で「すべてのボックス」にチェックマークを付けます。
彼らがこれをした理由には本当の理由があると言われていると。一部の認証と使用では、これらの一部を実装する必要があります（保健セクターや政府による使用を考えてください）。
特に8文字の制限があるため、表示されているものよりも優れているものはありません。
TitanファミリーのGPUとJohn the Ripperを使用すると、8文字すべてのコンボを1秒でテストできます。すべてのパスワードポリシーが有害であるわけではありませんが（最小の長さは適切で、1つ以上の特殊文字は大きなクラックアルファベットを強制し、辞書の単語はありません）、表示されているものは冗談であり、あまりおもしろくありません。つまり、パスワードマネージャーやスマートユーザーがデフォルトのポリシーよりも自分自身を保護することができないためです。
ポリシーは決して良いパスワードを止めるべきではなく、恐ろしいものだけを止めるべきです。
パスワードの強度、不十分なパスワードポリシー、またはパスワードポリシーがないことで何が悪いのですか？
それは、貧弱なパスワードポリシーが何であるかによって異なります。
「パスワードは 'letmein'である必要があります」は、ポリシーがまったくないよりも間違いなく悪いパスワードポリシーです。
「パスワードは2文字以上である必要があります」は、誰もが適切なパスワードを使用できるようにし、一部の不正なパスワードを防ぐことができるため、まったくポリシーがないよりも間違いなく優れたパスワードポリシーです。
すでに良い答えはたくさんありますが、私はいつも少し違う視点からこれを見てみたいです。あなたが何かがパスワードを解読する試みにどのように影響するかを考えているとき、あなたは彼らが言われた解読をしようとする方法を見る必要があります。基本的にこれは2つの方法に要約されます。ブルートフォースと「インテリジェント」な推測なので、これら2つを見てみましょう。
1）ブルートフォース
これはまさにそれがどのように聞こえるかです。彼らはあらゆる可能なパスワードを試みます。これは、4桁の数字ロックで0000から9999までのすべてのピンを試す古典的な方法です。ここで重要な要素は、可能なパスワードの数と、各推測を試行するのにかかる時間です。ここでは、パスワードルールが優れていて、8桁の要件があるため、ブルートフォースを実行可能なオプションとして完全に排除できます。また、十分に弱いハッシュが使用されている場合は完全に壊滅的となる可能性があり、十分なリソースを持つ攻撃者に対して、可能なすべてのパスワードが妥当な時間内にクラックされることが保証される可能性があります。
この場合のルールがバックエンドでかなり古いものを強く示唆しているように思われる場合、MD5やSHA1のようなかなり弱いものでパスワードがハッシュされ、おそらくソルトされておらず、ルールが壊滅的である可能性があります。主に長さですが、大文字と小文字が区別されないため、可能な文字が最大30％減少します。現在、パスワードには、26文字+ 10個の数字+ 64個の異なる文字を表す28個の記号が含まれています。大文字と小文字が区別される場合、90文字になります。
いくつかの迅速な検索に基づいて、妥当な量のリソースを持つ攻撃者を想定し、それらが弱いハッシュの1つを使用している場合、ルールは確かに壊滅的であり、現在ではない場合、それらは確かにコンピューティング能力がクラッキング率を高めるにつれて、近い将来に壊滅的になる危険性。安全のために8文字より長いパスワードが必要になる場合がありますが、実際には許可されていません。
オフライン攻撃で8文字のパスワードすべてを総当たりにすることは可能ですか？
2）「インテリジェント」な推測
ある時点でブルートフォース方式が実用的でなくなり、すべてのパスワードをテストするのに数か月かかるか、不可能です。すべてをテストするのに数千年かかり、「インテリジェント」な推測が引き継がれます。ここでは、辞書攻撃、つまり辞書からの文字通りの単語または以前に使用されたパスワードのリスト、およびルールベースの攻撃が表示されます。ルールベースの攻撃は、辞書を取得し、それらを追加または変更して、それらのパスワードのさまざまなバリエーションを作成します。パスワードの要件を満たす8桁のパスワードを取得するには、6文字のWordの末尾に数字と1つの特殊文字を追加します。パスワードをp @ ssw0rdに変換して、パスワードを「リート」にします。これは、このシステムでは有効ですがすぐに解読されるパスワードです。これらのルールは、理解できると思い、常に進化していくと考えられる、思いつく限りのほとんどすべてのものです。人々が通常、過去のリークに基づいてパスワードを選択する方法について。
クラッキングがこの時点に達したと仮定すると、彼らが与えたパスワード規則は、攻撃者が可能なパスワードを生成するために使用した規則に組み込まれることになります。ここで、彼らのルールは破滅的ではありませんが、有効なパスワードがはるかに少なくなるため、クラッキングの速度が上がります。また、パスワードの最初/最後に、または非常に予測可能な置換の一部として記号/数字が追加された、非常に予測可能なパスワードにつながる可能性があります。
ユーザーがランダムにパスワードを選択する場合、パスワードポリシーは可能なパスワードの選択を制限することによりセキュリティを悪化させますが、ユーザーはランダムにパスワードを選択しません。優れたパスワードポリシーの目的は、ユーザーにプッシュしてより多くの選択肢を提供し、パスワードのスペースを過度に制限することなく、より強力なパスワードを選択することです。
このポリシーには良い面と悪い面があります。
ちょうど8文字の長さ
最小の長さは適切で、最大の長さは不適切です。
少なくとも1つの文字と少なくとも1つの数字を含めます。
これは良いことです。ユーザーは文字ベースのコンポーネントと数字ベースのコンポーネントの両方を選択するように促されます。
パスワードでは大文字と小文字は区別されません。
これにより、パスワードセットのサイズが大幅に削減されます。一方、ほとんどの人はとにかく強制されない限り資本を使用せず、使用する場合は予測可能な方法で使用する傾向があります。
少なくとも1つの特殊文字を含める
もう一度いいますが、パスワードの作成者に別の選択をさせることになります。
禁止されたスペースとルール？そして！
これらが大きな違いを生むとは思えません。
開始時に繰り返される禁止文字
おそらく良いことは、ユーザーがパスワードを1文字の繰り返しで埋めるだけではできないことを意味します。
全体として、無知なユーザーがいる場合、このポリシーはおそらく何もないよりはましですが、ユーザーがまともなパスワードについて手掛かりを持っている場合は、おそらく良いことよりも害が大きいでしょう。
私はこれまでに他のすべての回答とは別のルートに行くつもりです...そして、ある時点でそれは問題ではないと言います。このアルゴリズムは、パスワードルールよりもはるかに重要です。
たとえば、誰かがROT13を使用する可能性があります。
または、MD5を使用して少し良くします。
または、さらに良いことに、SHA-1。
たぶん彼らは塩を加えます。
多分crypt（）を使用してください。
多分次にコショウを追加します。
それでも、GPGUPは1秒間に何十億ものパスワードハッシュを焼き切ることができます。じゃあ他には？
SHA-2-512、128ビットソルト。 GPGPUはこれらの多くを実行できます。
bcryptに変更します。ずっといい。さて、単一のGPGPUがそれらすべてを高速で燃焼できるようになるという点を過ぎています。
完全な塩コショウと10,000ラウンドのPBKDF2に変更します。
それまでにscryptを実行すると、アルゴリズムが非常に遅いため、非常に短いパスワードは「解読不可能」になります。
これは説明するのに役立つかもしれない table です：
Tries/sec
NTLM 350,000,000,000
MD5 180,000,000,000
SHA1 63,000,000,000
SHA512Crypt 364,000
Bcrypt 71,000
したがって、bcryptでハッシュされた安っぽいパスワードは、MD5でハッシュされた優れたパスワードよりも優れています。
それは本当にエンドユーザーにかかっています。私の見方では、会社/ウェブサイトとして誰かが誰かのアカウントが侵害された場合に責任を負わない場合、少なくとも制限的なものである正式なパスワードポリシーを忘れることが最善です。
弱いパスワードなどの影響を理解していれば、ユーザーは自分のセキュリティに責任を持つべきだと私は常に考えていました。
確かに、最後の部分が重要です。ユーザーが何もよく知らない場合と同様に、ユーザーが使用したいパスワードよりも安全なパスワードを強制する必要があります。しかし、パスワードポリシーは、より安全なパスワードを推奨するだけで、パスワードの強度を制限するべきではありません。
私は大学のウェブサイトでこれに個人的に遭遇しました。かなり長い英数字のパスワードは、一部の（すべてではないが：/）特殊文字を禁止するパスワードポリシーを満たしていません。その結果、意図的に脆弱なパスワードになりました。私にとっては、私が意図的にメモリにコミットしていないパスワードを思い出すことはより困難でした。
特にその場合、「パスワードポリシー」は、セキュリティを強化するための正当な方法よりも、バックエンドでの文字列の解析/サニテーションを回避するための言い訳のほうが多かったと思います。
最後に、パスワードポリシーは、実装されている場合、時間とともに変化するはずです。つまり、平均的な消費者がクラウドコンピューティングまたはGPUクラスターを利用して、絶えず増大し続ける膨大な量のコンピューター能力をパスワードに投入できるようになる2016年には、1990年代に安全なパスワードと考えられていたものはもはやそうではありません。