Bruce Schneierには、パスワードポリシーに関する興味深い記事がいくつかあります。
実世界のパスワード -パスワードの長さ、複雑さ、一般的なパスワードをカバーします。
パスワードのアドバイス -以下を含む、またはしないもの：
- パスワードマネージャーを使用してください
- パスワードは頻繁に変更してください。半年ごとに交換します...
- 古いパスワードを再利用しないでください。
- 辞書の単語、誕生日、家族やペットの名前、住所、その他の個人情報で構成されるパスワードは使用しないでください。
- Https経由でサイトが保護されている場合を除き、オープンなWi-Fiネットワークや信頼できないその他のネットワークを介して、パスワードで保護されたアカウントにアクセスしないでください。
などなど
パスワードの変更 -使用状況と脅威環境に基づいて変更する頻度についての詳細な説明。
これに対する答えは、セキュリティに関する多くの質問と同様に、「状況によって異なります」です。
パスワードの長さを検討する際に考慮すべきいくつかの要因があります。まず最初に、長いパスワードが保護するように設計されているもののいくつかがあります。これは、通常、パスワード推測攻撃（オンラインまたはオフライン）の総当たりです。
オンラインパスワードを推測する場合、比較的攻撃的なロックアウトポリシー（たとえば、3回の不正な試行とその後の不明確なロックアウト）がある場合、攻撃者がパスワードをよく理解していない限り、単一のアカウントに対する攻撃は成功しません。になるだろう。
同じロックアウトポリシーを持つ多数のユーザーに対する攻撃を阻止する場合、攻撃者はユーザー名（Webフォーラムなど）を突き止めることができますが、最も重要な要素は、使用されるパスワードが本当に一般的なもの。
余談ですが、アカウントロックアウト側で注意する必要があるのは、ここでのオンラインアプリケーションに対する攻撃的なポリシーにより、追加の対策を講じなくてもサービス拒否攻撃が非常に簡単になる可能性があることです。
オフライン総当たりのリスクがある場合は、パスワードの強度がより重要になります。ここでの問題は、処理能力と攻撃方法の改善により、これが強度の点で動くターゲットになることです。現実的には、10個以上の文字と、パスワードが一般的な辞書リストにないことを強く強制していると思います（@andyは、ここではパスフレーズが適切なオプションであると言っています）。
ここで考慮すべきもう1つの要素は、ユーザーベースと、アプリケーションの使用方法です。場合によっては、非常に強力なパスワード要件が実際には安全性の低いアプリケーションにつながる可能性があると私は言います。ユーザーが同じ場所にいるアプリケーション（多くの企業アプリケーションなど）で、パスワードポリシーを（パスワードの長さとローテーション要件の両方で）非常に「強力」にすると、ユーザーが起動する可能性があります。パスワードを書き留める。これはおそらく、そもそもそのアプリケーションのセキュリティの目標の1つを無効にするものです。
これに関するより多くの情報の1つの良い情報源は と呼ばれる本です。認証：パスワードから公開鍵へ
これまでのところ良い答えですが、別の可能性を提案したいと思います： パスフレーズ 。 StackOverflow 自身のJeff Atwoodが示唆しているように、技術的な制限によって禁止されていない場合は、パスフレーズの許可と提案を検討することができます。あなたはそれらを強制することができますが、それはおそらくほとんどのサイトの一部のユーザーを遠ざけるでしょう。その長さのために、それらは解読するのが大幅に難しくなる可能性があり、また「A1lUrB @ se！」のようなパスワードより覚えやすくなります。またはそのようなもの。
パスワードをハッシュする場合は、なぜ上限を設定するのですか？
Webベースなど、テキストフィールドの最大文字数制限に達することを心配する必要はありません。したがって、使用しているテキストフィールドの境界条件を制限するために、最大数百文字を設定することが考えられます。
もちろん、複数のサイトで使用するパスワードの生成について話している場合は、気にしないでください。それに同意する人はいません。さらに悪いことに、入力フィールドごとに最大文字数の制限が異なるサイトを見つけたので、ログインするには、たまたま文字を許可する別のフィールドが表示される前に、間違って入力する必要があります。もちろん、すべてのサイトがそれを人工的に制限しようとせずに、それを典型的なテキストフィールドの最小の期待される能力とするだけであれば、約2000文字が許可され、これについてまったく心配する必要はありません。
追加するために編集：渡すときに言及された何か ここ は私を一時停止させました：
ハッシュ処理を、サーバーまたはデバイスで利用可能で妥当なものにスケーリングする必要があります。たとえば、Discorseにマイナーなサービス拒否のバグがあり、ログインフォームに最大20,000文字のパスワードを入力できました
したがって、可能な限り計算コストが高くなるような方法でハッシュを行う場合は、パスワードの設定と試行の両方に妥当な制限を設けることをお勧めします。数百の文字は、ユーザーが試してみるよりもはるかに大きいものでありながら、物事が爆発しすぎないようにするかもしれません。
パスワードの最大長は指定しないでください。ユーザーが非常に長いパスワードの使用を受け入れる場合は、ブロックではなく推奨にする必要があります。
ソフトウェアとは何か、いくつかのシステムでは、主にGUIの問題、不十分なプログラミング、またははるかに古いシステムとの下位互換性のために、パスワードサイズに制限が適用されます。たとえば、古いUnixシステムは最初の8文字のみを使用するパスワードハッシュプロセスを使用し、他のすべてのシステムを完全に無視していました。同様に、古いWindowsシステムの内部制限は14文字です。したがって、パスワードを最初の14文字に切り詰めた場合でも、「強力」であることが最適です。
ただし、最大パスワードサイズの制限は、ユーザーの忍耐力のみです。ここで何かを強制しても意味がありません。
今日の一般的な最小値は12文字です。これは、妥当な時間内に十分に資金のある組織によるブルートフォースクラックを防止するのに十分な大きさです。
最大長まで;ここにいくつかの考えがあります：数百バイトより長いパスワードはほぼ確実に悪意があります（SQLインジェクションの試みなど）。また、パスワードをハッシュしている場合（およびそうでない場合は、最初からやり直す必要があります）、パスワードlongerはハッシュ出力よりもエントロピーを追加しません。 「より長い」とは、キースペース内の同じビット数を意味し、同じ文字長ではないことに注意してください。したがって、ハッシュ長よりも長いパスワードを許可することは許可にする必要がありますが、そのようなことを数学的な観点から必須にすることは意味がありません。 。
大文字と小文字を混在させる必要があると、アルファベットのサイズが2倍になり、非常に複雑な結果が得られ、おそらく必要になります。数字が必要な場合、アルファベットが20％増える可能性がありますが、それほど大きな問題ではありません。記号を必要とする場合は、さらに16％から40％増加します（カウントする記号によって異なります）。かなりのリターンですが、決して許されるべきではありません。
私は個人的にはパスワードジェネレーター（lastpass.comや1passwordなど）を使用して、8文字以上32文字以下のパスワードを生成して使用し（すべてのサイトが10または15を超えるパスワード長をサポートしているわけではないため）、1つのマスターパスワードを使用します認証用です（これも、lastpass.comなどのサイトでの信頼に依存します）、またはMacとWindows用のクライアント側の暗号化された1passwordユーティリティ）。
すべてのサイトに一連のパスワードを使用することはお勧めできません。特にフォーラムはパスワードをプレーンテキストで私にメールします。一部のサイトには、「パスワードを忘れた」機能を使用する場合にプレーンパスワードを送信する機能があります。
通常、制限はサーバーで設定されます（Webサイトの場合）。ユーザーのパスワードに制限を設定しないように、使用しているサーバーを非難する必要があります。
つまり、毎回異なるパスワードを使用します。 10〜15個を超えるパスワードを覚えておく必要がある場合は、「安全な」パスワードマネージャの使用を開始する時間です。 （参考までに、firefoxパスワードマネージャーはまったく安全ではありません）
16文字。
Wikipedia によれば、これは96ビットを提供します。これは、その記事によるとクラック可能なものをはるかに超えています。
個人的には、携帯電話のパスワードプログラムとFirefoxのマスターパスワード機能を組み合わせて使用しています。私のマスターパスワードは25文字以上で、Dice Wareに基づいているため、覚えやすくなっています。 Firefoxはとにかくパスワードを記憶しているので、ほとんどすべてのパスワードはランダムに再生成されます。
私は警備員が気が狂っていた顧客のところにいました。彼は可能な限りすべてのパスワード複雑度ポリシーを使用したいと考えていました。 （Novell eDirectoryにはパスワードの複雑さに関する多くの問題があり、さらにプラグインを使用してさらに追加したいと考えていました！）
要するに、記憶できるパスワードを生成することは不可能です。私は洗っていない大衆が彼を見つけ、それが実行された後彼にタールと羽をつけることを期待していました。
言い換えれば、あなたはそれを行き過ぎることができます。
助言
2019では、安全なパスワード/パスフレーズに必要なランダム性は次のとおりです。
- ランダムに生成された小文字、大文字、数字の12文字。または
- 6つのランダムに生成された単語。 （しないでください自分で単語を選択してください！パターンが作成されます。）
それらの20を覚えておくのは不可能なので、定期的に使用するいくつかの重要なものだけを覚えておいてください。たとえば、メールアカウント用のものとパスワードマネージャー用のものを記憶することができます。それ以外の場合は、パスワードマネージャーにパスワードを保存します。
関連： 平均的なユーザーは本当にパスワードマネージャーを必要としますか？
トップ投票の答えは明確な「はい」です。
関連： パスワードマネージャはどのくらい安全ですか？
paj28（強調は私の）によるトップの回答から：
ほとんどの人にとってこれらのリスクは許容可能であり、ほとんどすべてのパスワードに[パスワードマネージャ]を使用する方が、どこでも同じパスワードを使用するよりも優れている-これが主な代替手段のようです。しかし、すべてのパスワードをそこに保存することはしません。オンラインバンキングなど、最も重要なものを暗記するようにしてください。
一般的に言及されるパスワードマネージャーは、KeePass（X）、1Password、LastPassです。ブラウザーでの設定は、マスターパスワードでFirefoxを使用する場合、専用のパスワードを使用する場合とほぼ同じです。パスワードにアクセスする前にブラウザーがパスワードを必要としない場合、ブラウザーの安全性はあまり高くありません（ただし、詳細は、それ自体が全体的なトピックである正確な実装によって異なります）。
開発者
アプリケーションを作成するとき、いくつかの便利な考慮事項があります。
パスワードを安全にハッシュする方法？
概要：可能な限り遅いScryptまたはArgon2を使用します。これらが利用できない場合は、BcryptまたはPBKDF2を使用できます。 salt と pepper の両方を追加します。
パスワードの最大長は必要ですか？
要約：DoS攻撃のみに対して、数キロバイト程度。
クライアント側のパスワードハッシュを実装する
完全な開示：最も完全なものだと思うので、自分の回答にリンクします。他の人の意見も必ず読んでください。
細部
「なぜ私のPINコードは4桁だけですか？それは私の銀行口座を安全に保つのに十分です！）」と疑問に思うかもしれません これに専用の質問 がありますが、概要は2つあります。アクセスには銀行カードが必要で（認証の第2要素）、チップは3回試行するとロックアウトされます。
Webサイトの方がはるかに寛大なので、攻撃者はより多くの試みを行うことができます。さらに、Webサイトは遅かれ早かれハッキングされることが予想され、その後、攻撃者はハッシュされたパスワードを効率的にクラックできます。
ほとんどのウェブサイトは、ハッシュと呼ばれる一方向の暗号化の一種でパスワードを保存します。復号化キーはありません。同じハッシュアルゴリズムを再度適用することにより、システムは（入力したばかりの）パスワードを（データベースからの）保存されたパスワードと比較し、それらが等しいかどうかを知ることができます。しかし、データベースだけでは、元のパスワードを知ることはできません。
以前は、高速ハッシュ法が一般的でした。これはまた、ハッシュを取得した攻撃者が、平均的なゲーム用コンピュータで毎秒数十億回の試行をコンピュータに行わせることができることを意味します。 1秒あたり100億回の試行を想定すると、11文字のランダムなパスワードが約165年間有効です。そして、それはたった1人のゲーマーです。いくつかの外国の競合他社が関心を持っている会社のデータにアクセスできると想像してください。いくつかの追加の計算能力により、それらの165年が突然数か月のひび割れに変わります。そして来年には、同じ価格でより高速で、強度を再び低下させる新しいCPUが登場します。そのため、強力なパスワードでは12文字が最低限必要です。1文字追加すると、文字通り1万年がクラッキング時間に追加され（165年に対して10 230年）、当面は安全です。
ちなみに、パスワードの安全度の計算は簡単です：variations^length / guesses_per_time。バリエーションは、固有の要素の数であり、長さは使用する要素の数です。したがって、数字のみを使用する場合、10のバリエーション（0から9）があります。辞書の単語を使用する場合、辞書には多くの単語があります。次に、guesses_per_timeは、攻撃者がクラックできると想定する速さです。妥当な値は、毎秒数百億です。
例：10^14/10e9/3600は、1秒あたり10e9の試行を想定すると、14桁のコードを解読するのにかかる時間を示します（1時間に3600秒あり、60 * 60）。
一部のWebサイトはスマートで、低速ハッシュアルゴリズムを使用しています。サーバーがハッシュ化を行うため、それらがどれであるかはわかりません。そのため、外部から見ることはできません。これが事実である場合、単一の推測は計算にはるかに長い時間がかかります（サーバーの場合も攻撃者の場合も）。妥当なケースでは、十分な資金のある攻撃者は1秒あたり5万回の推測しかできません。その場合、9文字のパスワードで十分です。しかし、9つのランダムな文字は、特にすべてを定期的に使用しない場合は特に、多くの異なるアカウントで記憶するのは非常に困難です。したがって、パスワード管理者は、パスワードのセキュリティを確保する必要があります。
しかし、本当にユニークなパスワードが必要なのでしょうか？いくつかの異なるサイトで強力なパスワードを再利用してみませんか？ Webサイトが頻繁に侵害されるためです。これは日常の出来事ではありませんが、電子メールアドレスを haveibeenpwned.com に入力してみてください。これは、アカウントが最も頻繁にハッキングされる方法です：パスワードの再利用。パスワードマネージャーのセキュリティ侵害はそれほど一般的ではありません。