パスワードに最小の長さを課すことは（ユーザーを自分自身から救うために）非常に理にかなっていることは理解できますが、私の銀行ではパスワードの長さを6〜8文字にする必要があり、疑問に思い始めました...
（うまくいけば）彼らのために働いている優秀なITセキュリティ専門家がいる誰かが最大パスワード長を課している場合、私は同様のことを考える必要がありますか？これの長所/短所は何ですか？
パスワードは、長さに関係なく、32、40、128にハッシュされます。最小の長さの唯一の理由は、パスワードを簡単に推測できないようにすることです。最大長の目的はありません。
最大長を課した場合にユーザーにサービスを提供しない理由を説明する必須のXKCD ：
パスワードフィールドで指定された最大長は、セキュリティ警告として読み取る必要があります。賢明でセキュリティに敏感なユーザーは、最悪の事態を想定し、このサイトがパスワードを文字通り（つまり、epochwolfで説明されているようにハッシュされていない）保存していることを期待する必要があります。
その場合：
パスワードを受け入れるサイトを開発している場合は、同じブラシでタールを塗る場合を除いて、ばかげたパスワード制限を設定しないでください。
[内部的には、もちろん、巨大なパスワードの処理を回避するために、コードは最初の256/1024 / 2k / 4k /（何でも）バイトのみを「重要」として扱う場合があります。]
完全に無制限のパスワード長を許可すると、信頼できないソースからのパスワードを受け入れる場合に 1 つの大きな欠点があります。
送信者は非常に長いパスワードをあなたに渡そうとする可能性があり、他の人へのサービス拒否につながる可能性があります。たとえば、パスワードが 1 GB のデータであり、メモリが不足するまですべての時間を費やしているとします。この人がこのパスワードを何度でもあなたに送ってきたとしましょう。関連する他のパラメーターに注意しないと、DoS 攻撃につながる可能性があります。
上限を 256 文字などに設定することは、今日の基準では過度に寛大に思えます。
まず、銀行には優れたITセキュリティ専門家が働いていると思い込まないでください。 たっぷりしないでください。
とはいえ、パスワードの最大長は無意味です。多くの場合、ユーザーは新しいパスワードを作成する必要があります（現時点では、すべてのサイトで異なるパスワードを使用することの価値についての議論）。これにより、ユーザーがパスワードを書き留める可能性が高くなります。また、ブルートフォースからソーシャルエンジニアリングまでのあらゆるベクトルによる攻撃に対する感受性を大幅に高めます。
パスワードの最大長を 128 文字未満に設定することは、OWASP 認証チート シートによって推奨されなくなりました
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
段落全体を引用：
パスワードが長いほど、より多くの文字の組み合わせが提供されるため、攻撃者が推測するのがより困難になります。
パスワードの最小長は、アプリケーションによって強制される必要があります。10 文字未満のパスワードは脆弱であると見なされます ([1])。最小長の強制は、一部のユーザーの間でパスワードを記憶する際に問題を引き起こす可能性がありますが、アプリケーションは、一般的なパスワードよりもはるかに長くても覚えやすいパスフレーズ (文または単語の組み合わせ) を設定するようユーザーに推奨する必要があります。
ユーザーがパスフレーズを作成できなくなるため、パスワードの最大長をあまり短く設定しないでください。通常の最大長は 128 文字です。20 文字未満のパスフレーズは、小文字のラテン文字のみで構成されている場合、通常は脆弱であると見なされます。すべての文字がカウントされます!!
ユーザーが入力するすべての文字が実際にパスワードに含まれていることを確認してください。ユーザーが提供した長さよりも短いパスワードを切り詰めるシステムを見てきました (たとえば、20 文字を入力したときに 15 文字で切り捨てられます)。これは通常、すべてのパスワード入力フィールドの長さをパスワードの最大長とまったく同じ長さに設定することで処理されます。これは、パスワードの最大長が 20 ～ 30 文字のように短い場合に特に重要です。
最大パスワード長を適用する理由の1つは、フロントエンドが多くのレガシーシステムバックエンドとインターフェイスする必要がある場合です。バックエンドの1つ自体が最大パスワード長を適用します。
別の思考プロセスは、ユーザーが短いパスワードを使用することを余儀なくされた場合、（友人/家族が）簡単に推測できるキャッチフレーズやニックネームよりもランダムなジブリッシュを発明する可能性が高いということかもしれません。もちろん、このアプローチは、フロントエンドが数字/文字の混合を強制し、l33t-speakで書かれた単語を含む辞書の単語を含むパスワードを拒否する場合にのみ効果的です。
パスワードの最大長を課す正当な理由の 1 つとして、(bcrypt などの遅いハッシュ関数を使用するため) ハッシュのプロセスに時間がかかりすぎることが挙げられます。サーバーに対して DOS 攻撃を実行するために悪用される可能性のあるもの。
この場合も、サーバーは、時間がかかりすぎる要求ハンドラーを自動的にドロップするように構成する必要があります。したがって、これが大きな問題になるとは思えません。
私はあなたが両方の箇条書きで非常に正しいと思います。ハッシュ化されたパスワードを保存している場合、パスワードの長さはDBスキーマにまったく影響しません。無制限のパスワードの長さを持つと、ブルートフォース攻撃者が説明しなければならないもう1つの変数がスローされます。
悪いデザイン以外に、パスワードの長さを制限する言い訳を見つけるのは難しいです。
パスワードを最大長にすることで得られる唯一の利点は、長すぎるパスワードによるバッファ オーバーフロー攻撃のリスクを排除できることですが、その状況を処理するためのより良い方法があります。
私の銀行もそうしています。以前は任意のパスワードを許可していましたが、私は 20 文字のパスワードを使用していました。ある日、パスワードを変更したところ、見よ、最大 8 文字になり、古いパスワードに含まれていた英数字以外の文字が切り取られていました。私には意味がありませんでした。
銀行のすべてのバックエンド システムは、英数字以外の 20 文字のパスワードを使用していた以前は機能していたので、レガシー サポートが理由であるはずはありません。たとえそうであったとしても、任意のパスワードを持つことを許可し、レガシー システムの要件に適合するハッシュを作成する必要があります。さらに良いことに、レガシーシステムを修正する必要があります。
スマート カード ソリューションは私には合いません。このままではもうカードが多すぎる… もうギミックはいらない。
任意のサイズのパスワードを受け入れると、ハッシュされる前に、パフォーマンス上の理由からカーテンの長さに切り捨てられていると想定されます。切り捨ての問題は、サーバーのパフォーマンスが時間の経過とともに向上するにつれて、ハッシュが明らかに異なるため、切り捨て前の長さを簡単に増やすことができないことです。もちろん、両方の長さがハッシュされてチェックされる移行期間を持つこともできますが、これはより多くのリソースを使用します。
必要な場合を除き、制限を課さないようにしてください。注意してください: さまざまなケースで必要になる可能性があります。これらの理由の 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/
ストレージは安価です。なぜパスワードの長さを制限するのですか。パスワードをハッシュするだけでなく暗号化する場合でも、64文字の文字列を暗号化するのに6文字以上かかることはありません。
銀行のシステムが古いシステムをオーバーレイしている可能性があるため、パスワード用に一定量のスペースしか許可できませんでした。
最大の長さを設定する必要がありますか? 通常、パスワードが長いほど覚えにくくなるため、書き留められる可能性が高くなるという点で、これは IT の興味深いトピックです (明らかな理由から、大したことではありません)。また、パスワードが長いほど忘れられる傾向があり、必ずしもセキュリティ上のリスクではありませんが、管理上の煩わしさや生産性の低下などにつながる可能性があります。これらの問題が差し迫っていると考える管理者は、パスワードに最大長を課す可能性があります。
私は個人的に、この特定の問題を各ユーザー自身に信じています。40 文字のパスワードを覚えることができると思われる場合は、さらに力を発揮できます。
とはいえ、パスワードは急速に時代遅れのセキュリティモードになりつつあり、スマートカードと証明書認証は、あなたが述べたように総当たり攻撃が非常に困難または不可能であることが証明されており、サーバー側に秘密鍵とともに公開鍵のみを保存する必要がありますカード/コンピュータのキーを常に使用してください。
複雑なパスワードを要求するよりも、パスワードまたはパスフレーズが長いほど、単に長さに基づいて解読するのが難しく、覚えやすいです。
おそらく、かなり長い (10 以上) 最小の長さを選択するのが最善であり、長さを制限しても無駄です。
レガシー システム (前述) または外部ベンダーのシステムとのインターフェイスでは、8 文字の上限が必要になる場合があります。また、ユーザーを自分自身から救おうとする誤った試みである可能性もあります。そのように制限すると、システム内の pssw0rd1、pssw0rd2 などのパスワードが多すぎます。
パスワードがハッシュ化されない理由の 1 つは、使用される認証アルゴリズムです。たとえば、認証メカニズムにはクライアントとサーバーの両方が入力されたパスワードに対して同じ計算を実行する必要があるため、一部のダイジェスト アルゴリズムでは、サーバーでプレーンテキスト バージョンのパスワードが必要になります (通常、パスワードが入力されるたびに同じ出力が生成されるわけではありません)。 2 台のマシン間で共有される、ランダムに生成された「ノンス」と組み合わされます)。
場合によってはダイジェストを部分的に計算できるため、これを強化することができますが、常にではありません。より良い方法は、パスワードを可逆暗号化で保存することです。これは、暗号化キーが含まれるため、アプリケーション ソースを保護する必要があることを意味します。
ダイグスト認証は、暗号化されていないチャネルを介した認証を許可するためにあります。SSL またはその他のフルチャネル暗号化を使用している場合は、ダイジェスト認証メカニズムを使用する必要はありません。つまり、代わりにパスワードをハッシュ化して保存できます (パスワードはネットワーク上で安全にプレーンテキストで送信できるためです (安全な値が指定されている場合))。
たった 8 文字の長さのパスワードは、単純に間違っているように聞こえます。制限が必要な場合は、少なくとも 20 文字にすることをお勧めします。
適用する必要がある唯一の制限は、2000文字の制限、または何か非常に高いものだと思いますが、それが問題になる場合にのみデータベースのサイズを制限します