パスワードに最大長を課す必要がありますか？

パスワードに最小の長さを課すことは（ユーザーを自分自身から保護するために）意味があると理解できますが、私の銀行ではパスワードの長さが6〜8文字である必要があるため、疑問に思い始めました...

• これはブルートフォース攻撃を簡単にするだけではないでしょうか？（悪い）
• これは私のパスワードが暗号化されずに保存されていることを意味しますか？（悪い）

（うまくいけば）彼らのために働いている優れたITセキュリティ専門家がいる誰かがパスワードの最大長を課している場合、私は同様のことを考えるべきですか？これの長所/短所は何ですか？

パスワードは32、40、128の長さに関係なくハッシュされます。最小長の唯一の理由は、簡単に推測できるパスワードを防ぐためです。最大長の目的はありません。

最大長を課す場合にユーザーにサービス停止をさせる理由を説明する必須のXKCD：

パスワードフィールドに指定されている最大長は、セキュリティの警告として読み取る必要があります。賢明でセキュリティ意識の高いユーザーは、最悪の事態を想定し、このサイトがパスワードを文字どおりに格納している（つまり、エポックウルフによって説明されているようにハッシュされていない）ことを期待する必要があります。

その場合がそうです：

1. 可能であれば、このサイトをペストのように使用しないでください。彼らは明らかにセキュリティについて何も知りません。
2. 本当にサイトを使用する必要がある場合は、他の場所で使用するパスワードとは異なり、パスワードが一意であることを確認してください。

あなたがパスワードを受け入れるサイトを開発している場合、していないあなたは同じブラシでタール取得したい場合を除き、愚かなパスワード制限を置きます。

[もちろん、内部的には、コードは最初の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つ増えます。

設計が悪いだけでなく、パスワードの長さを制限する言い訳を見つけるのは困難です。

パスワードの最大長を確認できる唯一の利点は、過度に長いパスワードによって引き起こされるバッファオーバーフロー攻撃のリスクを排除することですが、その状況を処理するためのより良い方法があります。

長いパスワードを検証しないように言っている人々を無視してください。Owaspは文字通り128文字で十分だと言っています。十分な呼吸スペースを確保するために、気分が良ければ、300、250、500と言うこともできます。

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

パスワードの長さパスワードが長いほど、文字の組み合わせが多くなるため、攻撃者が推測しにくくなります。

...

パスワードの最大長は、ユーザーがパスフレーズを作成できなくなるため、あまり短く設定しないでください。通常の最大長は128文字です。20文字未満のパスフレーズは、小文字のラテン文字のみで構成されている場合、通常は弱いと見なされます。

ストレージは安価ですが、なぜパスワードの長さを制限するのですか。パスワードをハッシュするだけでなく、パスワードを暗号化している場合でも、64文字の文字列を暗号化するのに6文字の文字列を超えることはありません。

おそらく、銀行システムが古いシステムをオーバーレイしているため、パスワード用に一定量のスペースしか許可できませんでした。

私の銀行もこれを行います。以前はすべてのパスワードを許可していましたが、私は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/

最大長がありますか？これはITの奇妙なトピックです。通常、長いパスワードは覚えるのが難しく、書き留められる可能性が高くなります（明らかな理由により、重要ではありません）。また、長いパスワードは忘れがちになる傾向があり、必ずしもセキュリティリスクではありませんが、管理上の手間や生産性の低下などにつながる可能性があります。これらの問題が差し迫っていると考える管理者は、パスワードに最大長を課す可能性があります。

私は個人的に、この特定の問題を、ユーザーごとに信じています。あなたが40文字のパスワードを覚えることができると思うなら、それならあなたにはさらに力があります！

とはいえ、パスワードは急速に時代遅れのセキュリティモードになりつつあり、スマートカードと証明書の認証は、問題であると述べたように、ブルートフォースを実行するのは非常に困難または不可能であり、公開キーのみをサーバー側にプライベートに保存する必要があります。カード/コンピューターのキーを常に使用します。

長いパスワード、つまりパスフレーズは、単に長さに基づいて解読することが難しく、複雑なパスワードを要求するよりも覚えやすいです。

おそらく、長さを無用に制限して、かなり長い（10+）最小長にすることをお勧めします。

レガシーシステム（既に説明）または外部ベンダーのシステムとのインターフェイスには、8文字の上限が必要になる場合があります。また、ユーザーを自分自身から救うための見当違いの試みである可能性もあります。この方法で制限すると、システム内のpssw0rd1、pssw0rd2などのパスワードが多すぎます。

パスワードがハッシュされない理由の1つは、使用される認証アルゴリズムです。たとえば、一部のダイジェストアルゴリズムでは、認証メカニズムがクライアントとサーバーの両方で入力されたパスワードに対して同じ計算を実行するため、サーバーでプレーンテキストバージョンのパスワードが必要です（通常、パスワードと同じ出力が毎回生成されることはありません）ランダムに生成された「ノンス」と組み合わされ、2つのマシン間で共有されます）。

ダイジェストは一部では計算できる場合もありますが、常にではないため、これはしばしば強化されます。より良い方法は、リバーシブル暗号化を使用してパスワードを保存することです。つまり、暗号化キーが含まれているため、アプリケーションソースを保護する必要があります。

Digst authは、暗号化されていないチャネルでの認証を可能にするためのものです。SSLまたは他のフルチャネル暗号化を使用している場合は、ダイジェスト認証メカニズムを使用する必要はありません。つまり、パスワードをハッシュ化して保存できます（パスワードは平文で安全に送信できます（指定された値のsafeの場合）。

たった8文字の長いパスワードは、間違っているように聞こえます。制限がある場合は、少なくとも20文字をお勧めします。

適用する必要がある制限は、2000文字の制限、または何か他にひどく高いようなものですが、それが問題である場合にのみデータベースサイズを制限するためです。