ユーザーは、パスワードを作成するときに必要な特殊文字を使用できるようにする必要がありますか？
使用できる特殊文字のリストがあるログイン構成設定に出くわし、次のように疑問に思っていました。
この制限は、特定のセキュリティまたはユーザビリティのニーズに対応していますか？
例：Oracle Identity ManagerおよびMicrosoft Active Directoryでサポートされているパスワードの特殊文字のリスト：
更新：
寛大な回答をありがとう！
セキュリティとユーザビリティに関する質問をするたびに、双方の支持者の間には明確な隔たりがあるようです。ただし、これは多くの妥協とトレードオフを必要とする1つの領域なので、必ずしもそうである必要はありません。UXはそれに依存しています！
ユーザーが入力できる場合は、パスワードで許可する必要があります。
パスワードで使用できるものと使用できないものを誰かに伝えることは、常にユーザーにとって間違っていると感じます。パスワードは現在、最も一般的な認証方法です。ユーザーがanythingを入力できないようにすることは、本質的に、誰ができるかできないかをユーザーに知らせることです。
1.ユーザーが入力する印刷可能な文字はすべて許可する必要があります。
次の文字は大丈夫です...
'A', 'a', 'á', 'Æ', 'æ', 'Ñ', 'ñ', '-', '_', ' ' (space), '\t' (tab), '\n' (newline), ...
提出方法がわからないから TAB または ENTER 私のパスワードの一部としての文字は、他人がそうすることを防ぐ権利を私に与えません。
（心配しないでください。 ENTER パスワードの一部として文字を使用しますが、その一部を許可すると、敬意が得られます）。
2.印刷可能な文字を表示しないキーは許可されません。
この理由は明白ですが、完全を期すために、検出できるが他のアクションのために予約されている次のキーについて説明します。たとえば、パスワード入力はシフトが複数回ヒットしたことを記録するべきではありません...
[ctrl], [alt], [shift], [arrow keys], [Apple key], [windows key], etc.
3.特定の文字を許可しないと、ユーザーはセキュリティに疑問を投げかけます。
ユーザーがパスワードに特定の文字を入力できないようにすると、ユーザーが不快になるだけでなく、安全ではない他の何をしているのか、多くの人に質問されます。
あなたも言っているかもしれません...
「アプリケーションを修正して特殊文字を適切に処理したくないので、パスワードの安全性を低下させて手伝っていただけませんか？」
以下のルールは、ユーザーがスタックするのを防ぎながら、安全な入力を可能にします。
ユーザーがパスワードフィールドに入力している文字を表示しない（モバイルでは例外があります）
ユーザーが自分のパスワードを2回入力することで、通常は正しいことをユーザーに知らせるのに十分です（つまり、意図しない空白を誤って追加していないなど）。
偶発的なロックアウトのケースを処理するには、パスワードリセットメカニズムを使用することが重要です。
4.ユーザーに追加を促すことは、文字を禁止することと同じではありません。
ユーザーが安全なパスワードを思い付くのを助ける1つの方法は、それからゲームを作ることです...
5.認証の未来
" パスワードを無効にする技術 "は、パスワードに関して私たち全員が直面している問題について論じているかなり優れたgizmodoの記事です。また、ある日パスワードを置き換える可能性のあるいくつかの新しいパターンについても説明します。
多くのモバイルアプリケーションでは、使いやすさを向上し、エントリへの1つの障壁を取り除くために、ユーザーがプレーンテキストでパスワードを表示または非表示にできるようになっています。それが引き起こす問題はそれが解決する問題よりも悪いので、私はまだこれを避けます。
パスワードを表示/非表示にするための非常に直感的なメカニズムを使用しても60％のユーザーは、パスワードをクリアテキストで表示するのは間違っていると感じています。
同じ記事によると、 Touch ID は正しい方向に進んでおり、使いやすさに関しては簡単に勝つようです。 Touch IDには依然としていくつかの大きな問題があり、実用的ではありません。最大の問題は、特定のデバイスでのみ機能し、1人のユーザーが複数のアカウントを制御するという問題があることです。
ますます多くの高ピクセル密度カメラが世界に普及しているため、顔認識はもう1つの候補ですが、このアプローチでは、多くの場合、人々がプライバシーについて心配することになります。
これらすべての新しい認証試行で共有される1つの問題は、これです：あなたはパスワードです
あなたが知っていることよりも、偽造するほうが実際にははるかに簡単ですあなたは。さらに、一度侵害されたら、変更することはほとんど不可能です（たとえば、指紋）
長い間、パスワードは認証メカニズムとして最適です...
パスワードに任意の文字制限を設定しないでください。ありがとう！
サイトでパスワードに特定の文字コードのみを含める必要がある場合、ユーザーはそれらの文字を生成できるほとんどすべてのデバイスにパスワードを入力できます。一部のデバイスでは入力できるが他のデバイスでは入力できない文字コードがパスワードに含まれている場合、デバイスに含まれているコードを入力できるが、後で入力できないデバイスでログインする必要があるデバイスでパスワードを作成するユーザーは、彼のアカウントから事実上ロックアウトされます。
ほとんどすべての妥当なプラットフォームで、94の印刷可能なASCII文字は明確に区別されます。フォントがIとlに同じグリフを使用する場合でも、 0とOの場合、そのような文字を入力した人は通常、どちらを入力したかを疑うことはありません。対照的に、一部のプラットフォームでは、ユーザーはɸのような文字を入力していると思うかもしれません実際にφを入力します。そのようなユーザーが別の文字が入力されたマシンに移動した場合、パスワードの入力に使用した可能性のある文字がわからない限り、またはアクセスするまでアカウントにアクセスできなくなる可能性があります。
ダイアクリティカルマークの組み合わせなどの1つの要因がある場合、状況はさらに複雑になります。 ëのような一部の文字には、2つの正当な表現があります。単一の「ラテン小文字Eの分音符号」[コード0x000EB]または「結合分音符号」[コード0x00308]の後に「ラテン小文字E」[0x00065]があります。 。一部のデバイスでは、ユーザーが入力するフォームを制御できない場合があります。理想的には、パスワードはハッシュの前に既知の正規化された形式に変換されますが、Unicode文字列を「正規化」しようとするすべてのコードが常に同じように機能することは確かではありません（指定されている場合でも、それが意味するわけではありません）実際に）。
DaveAlgerのポイントに追加したいと思います。私は、多くの人と同様に、パスワードをよりよく覚えるためにアルゴリズムを作成しています。パスワードについて多くの人に（非公式な方法で）話しましたが、多くの反対意見を聞いています
- メールの一部またはユーザー名をパスワードに使用できないのはなぜですか？
- なぜ文字数制限があるのですか？ （私のアルゴリズムに影響します）
- なぜ特殊文字を使用できないのですか？
- なぜ大文字、数字、特殊文字を使わなければならないのですか？
ほぼ全員がパスワードの変更を余儀なくされたときにイライラします。送信されたパスワードが安全ではないと見なされた場合（例1234、1111、またはqwerty）、安全ではないと見なされてパスワードが拒否されることをユーザーに伝えます。ただし、パスワードが個々の要件を満たしていない場合でも、パスワードが実際に安全でないことを確認してください。
パスワードblueOrangeMetsWasSheaNowCitiは、数字や特殊文字を使用していなくても＃$ 78rtより安全です。
ユーザーを苛立たせるだけなので、制限はユーザビリティに役立ちません。私はセキュリティの専門家ではありませんが、文字セットの制限がシステムの保護にどのように役立つかはわかりません。
使いやすさとサポートの観点から理解できます。
Altキーまたはコピーアンドペーストを使用しないと、キーボードや電話で文字を入力できない場合。
最もアクティブなインターネット対応デバイスにはタッチスクリーンがあることに注意してください。ユーザーはラップトップからアカウントを作成し、携帯電話でアカウントにアクセスしようとする可能性がありますが、,文字を入力することはできません。
また、すべての空白文字は一般的なスペースとしてクリーンアップされ、前後からトリミングされます。複数の空白文字は連続して無視され、単一の空白として扱われます。どうして？空白、特に先頭、末尾、および複数の空白文字が連続していると、多くの問題が発生します。
おそらく空白を許可する必要がありますが（ユーザーは今すぐフレーズを使用するのが好きです）、ユーザーにパスワードを片付けた方法を通知する必要があるかもしれませんが、ユーザーがパスワードの入力に慣れている場合は、心配する必要はありません。 。
また、HTTPを介してパイプ処理する必要があるUnicode文字を許可することも、サポートの試練の1つです。
場合によります。
パスワード入力メカニズム（キーボードレイアウト、ソフトウェアスタックなど）をかなり強力に制御できる場合は、ユーザーが必要なものを自由に入力できるようにすることをお勧めします。これにより、使用可能なパスワードスペースが最大化されます。英語のサイトを攻撃している人は、おそらく「كلمةالمرور」（Google翻訳で「パスワード」がアラビア語であることを保証します）のような明白なことを試そうとはしないでしょう。このような場合、すべてのシステムですべてのミックスアップが同じになり、それ自体がキャンセルされるため、エンコーディングのミックスアップは実際には重要ではありません。
一方、できるだけ広い範囲のシステムをサポートする場合は、プログラミングを継続し、悪夢をサポートするために、パスワードを95個の印刷可能なASCII文字に制限する必要があります。すべてをサポートするということは、 homoglyphs （Α、А、およびAは人間と同じように見えますが、バイト値が異なる）、 重複する文字 （「マイクロ記号"µと"ギリシャ語の小文字mu "μは同じ文字を表しますが、異なるバイト値でエンコードされます）、異なる 構成形式 （ñとñは同じに見えますが、最初は" n "です次に、チルダを結合します。2番目は単一の合成文字です）、および異なる 結合文字の順序 （ếは、「e +アクセント記号+サーカムフレックスアクセント」または「e +サーカムフレックス」として表現できます。アクセント+アクセント記号 "、これはコンピューターで異なると見なされます）-そして、それはちょうどUnicode内にあります。 Garbledエンコーディング変換 は、誰かが試みたことを意味しますISO 8859-1システムで「Pssword」と入力すると、ISO 8859-7システムでは「Pδssword」と解釈されます。
ASCII以外のパスワードで見た1つの問題は、一部のシステムが文字を処理し、他のシステムがエンコーディング固有のコードポイントを処理することです。 「א」文字は、エンコードに応じてさまざまな方法で表される場合があり、同じ文字が複数の方法のいずれかで表される場合があります（「é」はU00E9またはU0065 U0301の場合もあります）。
Python2-> Python3への移行を検討してください。 Python 2で "שלום"をシリアル化し、Python 3でシリアル化された同じ値と比較すると、方法の変更によりPython 3としてFALSEになります。文字列はPythonで内部的に表現されます。
PHPにも同様の問題があります。文字ではなくバイトを扱います。したがって、CP-1252エンコーディングのページに「שלום」を入力したユーザーは、UTF-8エンコーディングのページにログインできない場合があります。これをmysql_*ドライバーの使用に固有のエンコードの問題のホストと組み合わせると（PDOドライバーではそれが少なくなるため、簡単になります）、問題はさらに複雑になります。
PHPでは、UTF-8を介してデータベースに適切に接続していることを確認することで、英語以外のWebサイトの問題に対処しました（PHP 5.3.3以降、はるかに簡単ですが、その前に問題がありました。PDOを使用しても、準備されたクエリと適切なハッシュを使用して、重要なバージョン番号を覚えているため、常にUTF-8としてページを提供しています。しかし、私はあまり知識のない同僚が問題に直面している問題に終わりはありませんでした。
はい、残念ながら、UXの観点からは、ユーザーがパスワードに使用できる文字の制限は理にかなっています。
世界規模のサービスを運営している場合、ユーザーが世界中のあらゆる場所からログを記録できるようにしたいと考えています。もしそうなら、あなたはそれを考慮に入れなければなりません、それは不愉快ではありません、キーボードではない標準化されています。
イベント基本キャラクターのレイアウトは可変です。たとえば、ドイツでは、神々が「Z」を「Y」に交換し、他のキャラクターとの完全なマッシュマッシュを行った理由を知っています。
ユーザーがキーボードでfindボタンを指定した場合のイベントです。すべての国に独自のキーボードがあるため、選択した「国」の文字を入力できない可能性があります。レイアウト（仮想、または極端な場合、ドイツのように物理的なもの）およびユーザーが選択できるようにするanyキーボードレイアウトは、少なくともWindowsマシンではオプションではありません。
ほとんどのユーザー気づいていないその問題に注意してください。
したがって、パスワードに含めることができる文字の選択を、（おそらく）任意のマシンの任意のユーザーが入力できるセットに制限する実用的な理由があります。
認証とセキュリティは重要です。セキュリティ違反はあなたを殺します。
キーボードとサーバーの間で何が起こっているのか考えていますか？正規化、エンコード、Unicodeのあいまいさ、シリアル化、NAT、中間者、その他の対策があります。これは、セッション全体で使用される安全なエンドツーエンドトランザクションです。悪者はそのようなものを利用したいと考えています。
一般的なセキュリティ対策は、攻撃対象を制限し、兵士のように保護することです。
これは、怠惰なプログラマーではありません。多くの悪者が悪用しようとする非常に敏感で重要な機能を保護することです。
「任意の文字を使いたいが、私を守りたい」と言うのは、「どんな形式のIDも受け入れますが、彼らが本人であることを保証します」と言うようなものです。学校のIDで飛行機に乗ることができません。理由は安全ではありません。
重要なのは、機能する安全なパスワードを128文字から作成できることです。さらにサポートするセキュリティ上の理由はありません。すべてのUnicodeをサポートすることは、不必要なセキュリティの脆弱性です。
いくつかのガイドライン：
ASCII 32（スペース）から126（〜）の範囲の任意の文字をユーザーに入力させます。これらはどの文字コードでも同じでなければなりません。
ユーザーをより少ない文字に制限すると、ユーザーを苛立たせるだけであり、パスワードを覚えるのに安全性が低いか、より難しいものを選択するように強制します。
以下の文字ASCII 32（およびASCII 127 = Delete）は、ESC、Enter（フォームの送信）、Tab（ジャンプフィールド）およびその他の文字などの特別な意味を持っています入力することを意図していないため、受け入れられません。
上記の文字ASCII= 127は一部のキーボードまたはデバイスでは入力できない場合があり（海外では電話または他のPC経由でログインできない場合があります）、Unicodeストレージが必要です（ただし、問題はありませんが、それに注意してください）
長さを制限しすぎないでください。ユーザーに数十文字を入力させます。 50または100まで。
私の答えのパスワードの詳細 ここ 。
自宅の住所に手紙が送信されてパスワードがリセットされるまでに2週間かかり、iPhoneに入力できないパスワードの文字が原因で休日に銀行にアクセスできない場合はどうなりますか。
銀行のせいですか、銀行の変更を検討しますか……
後の段階で、テキストフィールドではなくドロップダウンリストを使用してパスワードを入力したいと思った場合はどうでしょう。
今日使用しているキーボードで£を押したときに別の文字が出力された場合はどうなりますか？
パスワードをリセットする際のリスクを考えると、リセットが必要になる可能性が高いパスワードをユーザーが持つことを許可することで、別のリスクを作成しているだけですか？
ただし、メールを送信するWebサイトだけでパスワードをリセットできる場合は、パスワードに何でも許可する必要があります。
パスワードで使用できる文字を、印刷可能な文字の適切なサブセットに制限することをお勧めします。柔軟性の向上が常に優れているとは限りません。道路に速度制限があるのはそのためです。多くの場合、ユーザビリティとは、ユーザーを自分の足で撃つ自然な適性から保護することです。
サーバー側のセキュリティの観点からは、完全なUnicodeパスワードのサポートに問題はありません。サーバーサイドでクレイジーな文字を処理したくない場合でも、少しのJavaScriptコーディングですべてのパスワードを16進表記に簡単に事前変換してから、サーバーで送信して処理することができます。ただし、上記の理由により、これを行う必要があり、印刷可能な文字の適切なサブセットに制限する必要もあります。