パスワードに最大長を課すべきですか？
パスワードに最小限の長さを課すことは理にかなっていることは理解できますが（ユーザーを自分自身から守るため）、私のbankはパスワードが6〜8文字の長さで、私は疑問に思い始めました...
- これにより、ブルートフォース攻撃が簡単になりませんか？ （悪い）
- これは、パスワードが暗号化されずに保存されていることを意味しますか？ （悪い）
（うまくいけば）優秀なITセキュリティプロフェッショナルが働いている人がパスワードの最大長を課している場合、同様のことを考えるべきでしょうか？これの長所と短所は何ですか？
パスワードは、32、40、128の長さにハッシュされます。最小の長さの唯一の理由は、簡単に推測できるパスワードを防ぐためです。最大長の目的はありません。
必須の [〜＃〜] xkcd [〜＃〜] 最大長を課した場合にユーザーにサービスを提供しない理由を説明します。
パスワードフィールドで指定された最大長はセキュリティ警告として読む必要があります：賢明でセキュリティを意識したユーザーは最悪の事態を想定し、このサイトがパスワードを文字通り保存することを期待する必要がありますエポックウルフ）.
その場合：（a）可能な場合、このサイトをペストのように使用することは避けてください[彼らは明らかにセキュリティに関するナッツを知っています]（b）サイトを使用する必要がある場合、パスワードが一意であることを確認してください-他で使用するパスワードとは異なります。
パスワードを受け入れるサイトを開発している場合は、同じブラシでタール色にされたくない限り、愚かなパスワード制限を設定しないでください。
[もちろん、巨大なパスワードの処理を避けるために、コードは最初の256/1028/2k/4k（何でも）を「有意」として扱うことができます。
信頼できないソースからのパスワードを受け入れる場合、完全に無制限のパスワード長を許可することには1つの大きな欠点があります。
送信者は、他の人にサービス拒否をもたらすほど長いパスワードをあなたに与えようとする可能性があります。たとえば、パスワードが1GBのデータであり、メモリがなくなるまでパスワードを受け入れることに時間を費やす場合。ここで、この人がこのパスワードをあなたが受け入れようとする回数だけ送信するとします。関係する他のパラメーターに注意しないと、DoS攻撃につながる可能性があります。
上限を256文字のようなものに設定することは、今日の基準では過度に寛大に思えます。
第一に、銀行が彼らのために働いている優秀なITセキュリティ専門家を持っていると仮定しないでください。 たくさんありません 。
ただし、パスワードの最大長には意味がありません。多くの場合、ユーザーは新しいパスワードを作成する必要があります（一時的にすべてのサイトで異なるパスワードを使用することの価値についての議論）。また、ブルートフォースからソーシャルエンジニアリングへのあらゆるベクトルによって、攻撃を受けやすくなります。
パスワードの最大長の制限は、OWASP認証に関するチートシートで推奨されなくなりました
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
段落全体を引用：
パスワードが長いほど、文字の組み合わせが大きくなるため、攻撃者が推測しにくくなります。
パスワードの最小長は、アプリケーションによって強制される必要があります。 10文字より短いパスワードは脆弱であると見なされます（[1]）。最小長の強制は一部のユーザー間でパスワードを記憶する際に問題を引き起こす可能性がありますが、アプリケーションは、通常のパスワードよりもはるかに長く、覚えやすいパスフレーズ（文または単語の組み合わせ）を設定することを奨励する必要があります。
パスワードの最大長は、ユーザーがパスフレーズを作成できないようにするため、あまり短く設定しないでください。通常の最大長は128文字です。 20文字より短いパスフレーズは、小文字のラテン文字のみで構成されている場合、通常弱いと見なされます。すべてのキャラクターがカウント!!
ユーザーが入力するすべての文字が実際にパスワードに含まれていることを確認してください。ユーザーが提供した長さより短い長さでパスワードを切り捨てるシステムを見てきました（たとえば、20を入力したときに15文字で切り捨てられました）。これは通常、すべてのパスワード入力フィールドの長さを最大長パスワードとまったく同じ長さに設定することで処理されます。これは、パスワードの最大長が20〜30文字のように短い場合に特に重要です。
パスワードの最大長を強制する理由として考えられる理由の1つは、フロントエンドが多くのレガシーシステムバックエンドとインターフェイスする必要がある場合です。
別の思考プロセスは、ユーザーが短いパスワードを使用することを余儀なくされた場合、簡単に推測される（友人/家族によって）キャッチフレーズまたはニックネームよりもランダムな意味不明な言葉を発明する可能性が高いことです。このアプローチは、フロントエンドが数字/文字の混合を強制し、l33t-speakで書かれた単語を含む辞書の単語を含むパスワードを拒否する場合にのみ有効です。
何らかの最大パスワード長を課す可能性のある正当な理由の1つは、（bcryptなどの低速なハッシュ関数の使用による）ハッシュ処理に時間がかかりすぎることです。サーバーに対してDOS攻撃を実行するために悪用される可能性のあるもの。
再度、サーバーは、時間がかかりすぎる要求ハンドラーを自動的に削除するように構成する必要があります。だから、これが大きな問題になるとは思わない。
どちらの箇条書きでも非常に正しいと思います。ハッシュされたパスワードを保存している場合、パスワードの長さはDBスキーマにまったく影響しません。無制限のパスワード長を設定すると、ブルートフォース攻撃者が考慮しなければならないもう1つの変数がスローされます。
設計が悪いことに加えて、パスワードの長さを制限する言い訳を見つけるのは困難です。
パスワードの長さを最大にすることでわかる唯一の利点は、過度に長いパスワードによって引き起こされるバッファオーバーフロー攻撃のリスクを排除することですが、その状況を処理するためのより良い方法があります。
任意のサイズのパスワードを受け入れる場合、ハッシュされる前に、パフォーマンス上の理由でカーテンの長さに切り捨てられていると想定されます。切り捨ての問題は、ハッシュが明らかに異なるため、時間の経過とともにサーバーのパフォーマンスが向上するため、切り捨て前の長さを簡単に増やすことができないことです。もちろん、両方の長さをハッシュおよびチェックする移行期間を設定できますが、これにより多くのリソースが使用されます。
長いパスワードを検証しないと言っている人々を無視します。 Owaspは文字通り128文字で十分だと言っています。十分なブレススペースを確保するために、気分がよければ300、250、500と言ってもよいでしょう。
https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length
パスワードの長さパスワードを長くすると文字の組み合わせが大きくなり、その結果、攻撃者が推測しにくくなります。
...
ユーザーがパスフレーズを作成できないようにするため、パスワードの最大長を短くしすぎないでください。 典型的な最大長は128文字です。 20文字より短いパスフレーズは、小文字のラテン文字のみで構成されている場合、通常弱いと見なされます。
私の銀行もこれをしています。以前はすべてのパスワードを許可していましたが、20文字のパスワードがありました。ある日、私はそれを変更しました、そして、見よ、それは私に最大8を与えて、私の古いパスワードにあった非英数字を切り取りました。私には意味がありませんでした。
銀行のすべてのバックエンドシステムは、以前に20文字のパスワードを英数字以外で使用していたときに機能していたため、レガシーサポートが理由ではありませんでした。そして、たとえそうであったとしても、彼らはあなたに任意のパスワードを持たせ、それからレガシーシステムの要件に適合するハッシュを作るべきです。さらに良いのは、レガシーシステムを修正することです。
スマートカードソリューションは私にはうまくいきません。私はすでにあまりにも多くのカードを持っています...別のギミックは必要ありません。
ストレージは安価です。パスワードの長さを制限する理由。単にハッシュするのではなく、パスワードを暗号化する場合でも、64文字の文字列を暗号化するのに6文字の文字列よりも多くはかかりません。
銀行システムが古いシステムをオーバーレイしているため、パスワード用に一定のスペースしか許可できなかった可能性があります。
最大長が必要ですか？これはITの好奇心をそそるトピックです。一般に、長いパスワードは覚えるのが難しく、したがって書き留められる可能性が高くなります（明らかな理由から、大きな問題ではありません）。また、パスワードが長くなると忘れられる傾向がありますが、これは必ずしもセキュリティ上のリスクではありませんが、管理の手間や生産性の低下などにつながる可能性があります。これらの問題が差し迫っていると考える管理者は、パスワードに最大長を課す可能性があります。
私は個人的にこの特定の問題を、各ユーザー自身に信じています。あなたが40文字のパスワードを覚えていると思うなら、あなたにはもっともっと力があります！
とはいえ、パスワードは急速に時代遅れのセキュリティモードになりつつあり、スマートカードと証明書認証は、あなたが述べたようにブルートフォースが非常に難しいか不可能であることがわかり、公開鍵のみがサーバー側にプライベートで保存される必要があります常にカード/コンピューターのキー。
長いパスワード、つまりパスフレーズは、単純に長さに基づいて解読するのが難しく、複雑なパスワードを要求するよりも覚えやすいです。
かなり長い（10+）最小長を選択し、無駄な長さを制限するのがおそらく最善です。
パスワードがハッシュされない理由の1つは、使用される認証アルゴリズムです。たとえば、一部の ダイジェストアルゴリズム は、入力されたパスワードに対して同じ計算を実行するクライアントとサーバーの両方が認証メカニズムに関係するため、サーバーでパスワードのプレーンテキストバージョンを必要とします（通常は生成されません）パスワードがランダムに生成された2回のマシン間で共有される「nonce」と組み合わされるたびに同じ出力が生成されます）。
多くの場合、ダイジェストは一部のケースで計算される場合がありますが、常にではないため、これを強化できます。より良い方法は、パスワードを可逆暗号化で保存することです。これは、暗号化キーが含まれるので、アプリケーションソースを保護する必要があることを意味します。
Digst authは、暗号化されていないチャネルでの認証を許可するためにあります。 SSLまたはその他のフルチャネル暗号化を使用する場合、ダイジェスト認証メカニズムを使用する必要はありません。代わりに、パスワードをハッシュ化して保存できます（パスワードは安全に（指定された値の）プレーンテキストで送信できるため）。
必要がない限り、制限を課さないようにしてください。注意してください：多くの異なる場合に必要になる可能性があります。レガシーシステムに対処することが、これらの理由の1つです。非常に長いパスワードのケースをよくテストしてください（10MBの長いパスワードをシステムで処理できますか？）。使用するキー定義関数（KDF）（通常はPBKDF2、bcrypt、scrypt）には多くの時間とリソースがかかるため、サービス拒否（DoS）の問題が発生する可能性があります。実際の例： http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/ =
レガシーシステム（既に説明）または外部ベンダーのシステムとのインターフェイスには、8文字の大文字が必要になる場合があります。また、ユーザーを自分自身から救おうとする見当違いの試みである可能性もあります。そのように制限すると、システム内のpssw0rd1、pssw0rd2などのパスワードが多すぎます。