特定のサイトがパスワードにスペースを入れないのはなぜですか？

新しいWebサイトではあまり一般的ではないようですが、アカウントを必要とする多くのWebサイト（請求書の支払いなど）で、スペースを含むパスワードを作成できません。これは物事を覚えるのをより難しくするだけであり、パスワードのスペース、暗号化された、または（天国では禁止されている）データベースまたはプログラミングの制限がないことを認識しています。では、なぜ、サイトへのサインアップに関して、スペースバーはそれほど一般的に差別されているのですか？

Webサイトのパスワードに関しては、非常に多くの愚かさがあります。

• いくつかは純粋に技術的な理由があります（有効かどうか、それは別の質問ですが、ほとんどすべてはそうではありません）：

パスワードは4文字で、数字のみである必要があります。

（パスワードを0001 .. 9999の範囲に制限することにより、単純に数字としてプレーンテキストでデータベースに保存できます）

• その他は、パスワードをより安全にするという誤った考えによって説明されます：

パスワードは大文字で始まり、数字で終わる必要があります。

（これを行うことにより、開発者またはマネージャーは、これによりユーザーが安全なパスワードを選択するよう強制されると想定しましたが、「パスワードには6文字以上、大文字、小文字、 「数字」は魔法のように失敗します）

• 最後に、パスワードはプレーンテキストで保存されるという事実によって説明されます。また、パスワードの保存、処理、または取得方法についていくつかのあいまいさがあり、それらを単体テストする時間はありません。

パスワードに無効な文字が含まれていますé。

または、

パスワードy$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dに無効な文字が含まれています。ラテンアルファベットと数字のみを使用してください。

または、

パスワードに空白文字を含めることはできません。

3つのケースすべてにおいて、開発者はこのようなパスワードが正しく保存されることを保証していました。

• 最初のケースでは、送信時に何にé変換さ%C3%A9れますか？または、データベースがé正しく保存されない場合はどうなりますか？

• 2番目のケースでは、PHP（なぜPHP？）がUnicodeを処理できず、このようなパスワードを受け取ったときに何かひどいことをした場合はどうでしょうか？<キャラクターがトラブルを起こすとどうなりますか？&文字がURLの区切り文字として解釈された場合（何らかの理由で、パスワードがPOSTではなくGETで送信されていると仮定した場合）'データベースが解釈した場合、SQLインジェクションとは何か、それを回避する方法がわからないので、どうすればよいでしょうか？それとも、何に'変換され\'ますか？

• 3番目のケースで、PHPが（場合によっては）他のケースではなく空白を削除する場合はどうなりますか？ユーザーが3つの連続した空白を設定している間に、空白が1つしか表示されないために管理者（プレーンテキストでユーザーのパスワードに驚くほどアクセスできる）が失われた場合はどうなりますか？

3つすべてのケースで、これらのあいまいさは、テスト、特に単体テストによって簡単に解決されます。しかし、膨大な量のプロジェクトでは、テストがまったく行われず、テストする時間もありません（ただし、後でデバッグするのに十分な時間はあります）。

これは、開発者がスペース、Unicode文字、またはASCII 48..57∪65..90∪97..122（数字、小文字、大文字）以外の任意の文字を許可した場合に考えられる結果について考えようとすることを意味します。 、テストが不可能な場合の最も簡単な方法は、それらを禁止することです。

私の意見では、これがスペースを禁止する唯一の理由です。Yannis Rizosは、UXに関連する別の理由を示しました。理論的にはもっともらしい理由ですが、実際にはまったく機能しません。実際にUXを気にする人が作成したWebサイトは、愚かなパスワード規則を修正しません。その代わり、ホワイトスペースが実際に禁止されているウェブサイトの大部分は、UXについて聞いたことがない人々によって行われています。UXの観点から見ると、有効な制限を含むパスワード関連の制限が最小文字数であるため、文字を禁止するのは本当に面倒なので、これは特に当てはまります。

答えは歴史です

これらすべてのものを管理する当社の能力は、それが今であるよりもやや少なかったとき、私たちは多くの根拠が、これはストレージが（ディスク上またはメモリ内に）効果的に自由ではなかった時間から来ていることを忘れているように見える均等に自動化されたシステムの能力同じものをクラックしようとするのも少し少なかった。

私たちが今知っていることと今できることを基にしたパスワードに関する暴言はたくさんありますが、単純な事実は、私たちはしばしばレガシー思考とレガシーシステムの組み合わせを扱っているということです。

現在、新しいシステムには制限が必要ですか？私はそうしないことを望みます-今でははるかに少ない理由

私見、それはパスワードにスペースを許可しないためにパスワードを保存するために現代のハッシュおよび/またはソルティングを使用するサイト/アプリのまったく愚かです。しかし、一部のレガシーシステムは、（このどこかで読ん）まだ平文でパスワードを周りに渡す-ので、スペースができていないことが意味をなします。また、一部のアプリは、受け取ったすべての文字列入力を「削除」する場合があります。そのため、スペースで始まるパスワードまたはスペースで終わるパスワードは適切ではありません（もちろん、それは不自然でしたが、自分のサイトを作成するほとんどすべての人に起こり得ないことを想像できます）。パスワードにスペースを許可することには「悪い」ことは何もありません-あなたが指摘するように、DBはハッシュまたはプレーンテキストバージョンを禁止しません。

実際、私のWindowsの友人のほとんどは、パスワードにスペースを使用できることを知りません。そのため、Tim Medoraの回答によると、サイト所有者はラマ（チャンス）でチャンスを取りたくないでしょう。誤解および/またはスペースが提供できる利点を知らない。

多くのサイトが名前にハイフン、アポストロフィ、または非ASCII文字を許可していないのと同じ理由で行われていますが、これらは米国内だけでも非常に一般的な慣行であり、これらの文字を単に許可するよりも多くの作業が必要ですそれら。

また、多くのサイトの単語フィルターで「生意気」、「遅延」、「累積」などの単語を使用できないという同じ理由で行われています（ただし、多くの一般的な人種的中傷は完全に大丈夫です）。

それは、多くの開発者が明らかに常識的に完全に欠けているか、少なくとも可能なユーザー入力とシナリオを検討する際の想像力が非常に限られているためです。それらのごく一部は、誤った情報を処理している可能性があります（英数字以外の文字を除外することが何らかの形で標準的な慣行であるか、ハッシュアルゴリズムまたはストレージメソッドがスペースまたは特殊文字を処理できないこと）。他の人は単に怠け者かもしれません。文字セットの問題を心配しているので、入力を最小限の文字スペースに制限します。そして、実際の脅威を理解していないために、妄想のために熱心な入力検証/衛生を行使している人がいるかもしれません。