何も考えずに、すべてのキャラクターを許可する必要があると言いたいだけです。いずれにせよハッシュ化されるので、強力なパスワードを作成したい人を制限したくありません.
ただ、よく考えてみると、どのような影響があるのかわからないキャラクターがたくさんいます。カップルの名前を付ける外国の文字、アスキー記号など。
Google で調べてみましたが、人々の行動に関する決定的な基準を見つけることができません。ほとんどの専門組織でさえ知らないようです。多くのサイトでは、特殊文字を完全に禁止するのが一般的であるように思われますが、これはばかげたことであり、私がやりたいことではありません。
とにかく、長さ、許可される文字などについて標準的な推奨事項はありますか?
問題があるかどうかはわかりませんが、C# で ASP.NET を使用します。
通常、印刷可能な空白以外の ASCII 文字 (33 から 126 までの範囲) をパスワードに使用できます。多くのセキュリティ専門家 (および SO コメンター) は、パスワードの代わりにパスフレーズを使用するようアドバイスしているため、スペースを許可する必要があります。議論は、パスフレーズが長いことと、語句が辞書に載っていないことから、パスフレーズはパスワードよりもクラックするのが難しいというものです。(パスフレーズは覚えやすいので、正当なユーザーはモニターの付箋にメモしておく必要がありません。)
一部の強力なパスワード ジェネレーターはハッシュを使用するため、長さを含めるために非常に高い制限 (512 または 1024) を設定します。現在のパスワード ジェネレーターは 32 ～ 128 文字の文字列を生成することがよくありますが、今後数年間でどのようなハッシュが使用されるかは誰にもわかりません。
限られたデバイス (モバイル、コンソールなど) でパスワードを入力する場合、非 ASCII 文字は確かに難しくなりますが、通常は不可能ではありません。おそらく、ユーザーがそうしたいのであれば、許可する必要があります。合理的で一貫したことを行うのは簡単です-たとえば、ハッシュする前にUTF-8でエンコードします。一部の入力デバイスが文字をコンポジションとして送信した場合にのみ問題が発生します (たとえば、「e アキュート」の代わりに e + アキュート アクセント)-しかし、実際には起こらないと思います。(自分ですべてを分解することもできますが、エッジ ケースに行くのは大変です。)
ただし、印刷可能な文字に制限します。タブやフォーム フィードなどをパスワードに入れると、本当に問題が発生します。
簡単な答え：それがサポートできる限りのシステムバッキングを許可します。今日では、テキスト入力に完全なUnicodeサポートを使用しないという言い訳はありません。これにはパスワードが含まれます。文字通りに処理される限り、文字の問題について心配する必要はないと思います（ただし、私はこの分野のプロではありません。SQLインジェクションに注意してください）。
私は、パスワードに制限を課しているサイトに対してペットを飼っています...あらゆる種類の制限。パスワードの強度を教えてくれるサイトが好きで、パスワードを強くすることをお勧めしますが、ユーザーに8文字以上の入力を強制したり、文字と数字の両方を要求したりするのは、まったくイライラします。
最大フィールドサイズが必要な場合（たとえば、データベースに格納するため）、人が手で入力するものすべてに十分な大きさにするようにしてください。自動化され、生成された強力なパスワードを使用する可能性は常にあるため、パスワードフィールドが大きすぎるなどのことは実際にはありませんが、64〜128文字で十分です。
基本的に、ほとんどの Unicode クラスの文字を許可する必要があります。ただし、制御文字 (たとえば、スペース以外の 0-31)、バイト オーダー マーク (0xfffe および oxfeff) はスキップしてください。さらに、最初に表現を正規化して、異なる表現によって引き起こされる問題を取り除きたいと考えています。入力するのが難しすぎると思われる文字に対して警告を発することもありますが、ユーザーはそれを自分でガードします。
専門家ではありませんが、私が選んだ奇抜ではないキャラクターが拒否されるのは嫌いです。だから、私はあなたの腸に同意すると思います。
注意: パスワードを保存する場合、すべてのパスワードは sha1 の md5 のような一方向アルゴリズムで暗号化する必要があります。これらのアルゴリズムは常に 16 進数を生成するため、SQL インジェクションなどについて心配する必要はありません。
そのため、文字を md5 または sha1 できる限り、それは受け入れられるはずです。
「ユーザーがインターフェイスで入力できるすべての文字を含めるようにする」に別の投票を追加します。タブや制御文字も禁止しません。ソフトウェアには、任意のバイト文字列を受け入れてハッシュする機能があるため、任意のバイト文字列をパスワードとして受け入れます。そうしないと、攻撃者がブルート フォース攻撃または辞書攻撃で検索しなければならないスペースが減少します。
(もちろん、すべてを許可したとしても、ユーザーの 99% はペットの名前をパスワードとして使用します...)
SQL インジェクション タイプの攻撃を防止することについて話している場合は、入力を制限して問題を簡単にすることに頼るのではなく、コードが本来の動作を行うようにする方がおそらく良い考えです。
非ASCII文字の場合、入力を（テキストではなく）バイナリ文字列として正しく表現でき、それがハッシュ関数またはキージェネレーターなどに渡される場合、それがより難しい問題だとは思いません.
最終的には、ユーザーに送信される確認メールでクリア パスワードを印刷しなければならない場合があります。
PS: メールのエンコーディングの問題も考慮する場合があります。標準の ascii (日本語の文字など) ではない場合、ユーザーがメールを適切な形式で受信できないか、フォントが原因で別のシステムで読めない可能性があります。インストールされていません。
これはすべて、「印刷可能な」ASCII文字の範囲に含まれています。