一部のWebサイトやプログラムがパスワードの特性を制限するのはなぜですか？
私が使用しているいくつかのWebサイトやプログラムでさえ、とんでもないパスワード制限があります。たとえば、多くのフォーラムでは、パスワードを最大32文字に制限しています。その他は、制限された文字セットを強制します。
開発者が何をそのような制限に置くのでしょうか？クライアントでパスワードの初期ハッシュを行う限り、膨大な自動生成パスワードのハッシュを計算する必要があるため、サーバーに負荷がかかりません。そのような制限を使用するメリットはないようです
その理由は、他の入力検証と同じだと思います。処理および保管中に問題が発生しないことを確認します。現在、パスワードはハッシュ化されているため、クリアテキストで保存も処理もされていないため、これは完全に見当違いです。
このような制限は、開発者がセキュリティ面で何をしているのかわからず、おそらくパスワードをクリアテキストで保存することを示していると考えます。近づかないで。
私は行くつもりです：人々が奇妙なことをするのと同じ古い理由。
当時は、それは良い考えのように思われたためです。開発者は、意欲的であるが、十分な情報を得られていない可能性があります。パスワードの長さを制限する必要はありませんが、開発者はそれを認識していない可能性があります。たぶん開発者はそれについてさえ考えなかったでしょう。
他の方法よりも簡単だったため。多分、彼らは任意の長さのパスワードを処理できないAPIを使用しています。これにより、より良いAPIを使用するよりも、パスワードの長さを制限する方が簡単になる場合があります。おそらく、データベースにSQLインジェクションの欠陥があるため、SQLインジェクションの欠陥を回避するために適切にコーディングするよりも、一部の文字をブラックリストに登録する方が簡単です（たとえば、ユーザーがパスワードに単一引用符を含めることを禁止します）。おそらく何らかの理由で、可変長文字列よりも固定長配列を使用する方が簡単でした。知るか。
ボトムライン：そのような制限を正当化する正当な理由はありません。市販のソフトウェアには、あらゆる種類の奇妙なデザインのミスフィーチャーが含まれていることが多いことに慣れていると思います。それが起こります。それは人生の事実です。 「十分」は「完全」よりもはるかに安いという事実の結果です。
パスワードの長さと可能な文字セットを制限する合理的な理由は、ユーザーに適切なパスワード管理手法を適用するように促すことです。簡単に言えば、パスワードが巨大または奇妙な文字でいっぱいの場合、ユーザーがパスワードを紙に書き留める（従来はキーボードの下に貼り付けられていた）、および/または同じパスワードを複数のシステムに再利用する可能性が高くなります。 。
概念的には、ユーザーが自分のパスワードをどのように管理するかはユーザーの責任であり、ウェブサイトのビジネスは一切責任を負いません。しかし、実際には、ユーザーはセキュリティ面で無知であり、即時の報復がないものには飽きられません（特にユーザーが潜在的な顧客の場合）。したがって、ユーザーを保護するためにできることを実行しようとするのは、Webサイト次第です。
適切なパスワード管理を実施しようとしていると主張していないことに注意してくださいis特定のサイトがパスワードの長さを制限する理由。 [〜＃〜] i [〜＃〜]が自分のサイトでパスワードの長さの制限を想定する理由にすぎません（ユーザーパスワードでWebサイトを管理する場合）。
制限付きの許可された文字セットのもう1つの理由は、相互運用性を促進することです。できれば、ユーザーは幅広い入力デバイスでパスワードを入力できる必要があります。非ASCII文字はUSキーボードのように見えるものには適していません（USキーボードでは非ASCII文字を入力することができますが、常にそれを行いますが、方法はオペレーティングシステムと構成によって異なります。パスワード入力の慣例であるブラインドタイピングではうまく機能しません）。スマートフォンにはさらに大きな制限があります。ここでも、相互運用性は（私の見方では）制限された文字セットを適用する正当な理由ですが、多くのWebサイトにはbadの理由でこのような制限があります（たとえば、パスワードを不注意にSQLにダンプできるようにするため）適切な文字列エスケープなしのリクエスト。これは、ずさんなエンジニアリングとしか言えません）。
私はこのような質問があると思ったが、今夜の検索風は弱いか、別のサイトにあった。
基本的に、ほとんどのアプリケーションまたはデータベースでは、入力文字列に有効な制限を定義することは理にかなっています。これにより、制限に達したら（オーバーフローなどを回避できる）入力を停止でき、コードのパフォーマンスを予測できます。
また、パスワードがハッシュ化される前にパスワードを検証するときに一時的なストレージが必要になる場合があります。ここでも、任意の長い入力を許可すると問題が発生する可能性があります。
なぜ32か？ほとんどの目的にとって妥当な数値です。32文字のエントロピーは巨大です。もちろん、一部の環境ではこれで十分ではありませんが、それらの多くにとって、証明書または2番目の要素（トークンなど）がいずれにしてもより適切な場合があります。
私の最初の質問は正解を逃したので、私は別の答えを提供します。主な理由は、制限が必要であることです。ストレージスペースとデータのチャンクに関する懸念は正確ですが、いくつかの問題があります。
まず、以下の私の元の回答を読むと、推奨事項の1つが反復ハッシュ（つまり、pbkdf）であることがわかります。これが本当に効果的であるためには、多数の反復が必要です。ユーザーが大きな文字列を送信できる場合、この反復ハッシュ値を計算するコストは、単純な認証関数の予想よりもすぐに高くなります。
サーバー上の単一の計算コストの高いタスク、特に認証されていないユーザーが明示的に利用できるタスクは、悪意のあるユーザーによるサービス拒否攻撃を悪用される可能性があります。
次に、固定長のパスワードを実装することにより、非常に長いリクエストが送信された場合に早期に終了する機会を提供します。リクエスト内のパラメータが予想される長さを超えている場合、エラーメッセージを発行して接続を閉じるのは簡単です。
多くのサイトでパスワードの複雑さの要件が適用されるのは、ユーザーが弱いパスワードを選択できないようにするためです。最近の歴史には多くの例があり、ほとんどのユーザーは複雑なパスワードよりも弱い、入力しやすく、覚えやすいパスワードを選択することを示しています。これが発生した場合、パスワードが盗まれたりクラックされたりした場合、ユーザーは常にサイトのせいになり、サイトと影響を受けるユーザーの両方に影響を与える可能性があるため、サイトの所有者は自分自身を危険にさらしています。
強力なパスワード要件を実装することにより、攻撃者がパスワードを簡単に推測できる可能性が低くなります。パスワードは、2つの異なる攻撃経路から保護する必要もあります。最初のオンライン攻撃では、サイト開発者がブルートフォース攻撃の成功を防ぐポリシーを持っている必要があります。これは、ユーザーが適切に長く複雑なパスワードを選択することを要求し、速度を落とす前に失敗したログオン試行の数を制限する（つまり、一時的なロックアウト、キャプチャなど）か、ログインの試行を停止する（永続的なロックアウト、必須のパスワードのリセット、アカウントの確認）ことによって実現されます。 、など）。
2番目の攻撃はオフライン攻撃で、攻撃者はパスワードデータベースのコピーを取得し、レインボーテーブルまたはオフラインパスワードクラッカーを使用して複数のアカウントをクラックしようとします。このタイプの攻撃は、強力なハッシュアルゴリズムをユーザーごとのソルトと組み合わせて使用し、オフラインクラッキングの計算コストを増やすために、pbkdf2またはbcrypt/scryptスタイルの再ハッシュを使用することで防止されます。
最終的に、サイトがユーザーにさまざまなアカウントに固有のパスワードを選択するように勧めていない場合、これらの手法はどちらも失敗します。多くのユーザーは複数のアカウントに同じパスワードを選択し、そのパスワードが公開された場合、特にメールアカウントで、攻撃者が別のサービスでその認証情報を使用する可能性があります。このため、各サイトまたは少なくとも異なるサイトグループに対して一意で強力なパスワードを生成し、安全なパスワードマネージャーを使用して、すべての異なるパスワードを保存するのが最善です。