パスワードでUnicodeをサポートする必要がありますか？
ユーザーがパスワードにUnicodeを使用できるようにしたいと思います。
ただし、多くのサイトがそれをサポートしていないようです（Gmail、Hotmailなど）。
ですから、私が見落としている技術的または使いやすさの問題があるのではないかと思います。
デフォルトでは.NETはUnicodeを受け入れ、Hotmail（新しいLiveメール）がそれに基づいて構築されている場合、なぜ制限されるのかわかりません。
誰かが同様の問題に遭遇しましたか？
技術的な問題はないと確信していますが、Gmailやhotmailが意図的にサポートしていない可能性があります。この種のWebサイトには幅広いユーザーがいて、どこからでもアクセスできる必要があります。
ユーザーが日本語のパスワードを持っているが、旅行中にサイバーカフェに行き、ユーザーがログインできない日本語のサポートがない場合を想像してみてください。
もう1つの問題は、パスワードの複雑さを分析することです。ユーザーが一般的な単語を英語で入力していないことを確認するのはそれほど難しくありませんが、中国語/ロシア語/タイ語ではどうでしょうか。言語を追加すると、パスワードの複雑さを分析するのがはるかに難しくなります。
したがって、システムにアクセスできるようにしたい場合は、ユーザーがあらゆる種類のデバイス/ OS /環境で自分のパスワードを入力できるようにすることをお勧めします。そのため、最も一般的な記号が付いた英数字のパスワード（!<>"#$%&など）は、どこでも利用できる一種の優れた文字セットです。
一般的に、私はパスワードで許可される文字の種類を制限しないことに強く賛成です。ただし、パスワードやハッシュなど、保存されているものと何かを比較する必要があることに注意してください。前者の場合、比較が正しく行われることを確認する必要があります。これは、ASCIIのみの場合よりも、Unicodeの方がはるかに複雑です。後者の場合、正確にハッシュしていることを確認する必要があります。正規化フォームは、誰が適用するかに応じて、ここで役立つ場合もあれば、呪いになる場合もあります。
たとえば、私が取り組んでいるアプリケーションでは、文字の組み合わせなどの潜在的な問題を取り除くために、事前に正規化されたパスワードのUTF-8変換を介したハッシュを使用しています。
ユーザーの最大の問題may顔は、別のキーボードレイアウトのように、一部の場所で入力できないことです。これは私のパスワードの1つにすでに当てはまりますが、これまでのところ問題にはなりませんでした。そして結局のところ、それはユーザーが自分のパスワードを選択する際に下さなければならない決定であり、アプリケーションがユーザーに代わって下すべき決定ではありません。パスワードに任意のUnicodeを喜んで使用し、別のキーボードレイアウトを使用するときに発生する可能性のある問題について考えていないユーザーはいないと思います。 （ただし、これはWebベースのサービスにとって何よりも問題になる可能性があります。）
ただし、Unicodeが正しく禁止されている場合もあります。そのような例の1つがTrueCryptで、これは起動時のパスワードにUSキーボードレイアウトの使用を強制します（フルボリューム暗号化の場合）。そこには他のレイアウトがないため、Unicodeまたは他のキーボードレイアウトでは問題が発生するだけです。
しかし、それは彼らが通常のパスワードでUnicodeを禁止する理由を説明していません。警告はいいかもしれませんが、私の目には完全な禁止は間違っています。
ですから、私が見落としている技術的または使いやすさの問題があるのではないかと思います。
HTTP基本認証では、非ASCIIパスワード（さらに言えばユーザー名）に技術的な問題があります。私の知る限り、あなたが言及したサイトは一般的に基本認証を使用していませんが、使用しているシステムからの二日酔いである可能性があります。
HTTP基本認証標準は、base64でエンコードされたusername:passwordトークンを定義します。これは、ユーザー名またはパスワードにコロンが含まれている場合、結果があいまいになることを意味します。また、トークンをbase64でデコードすると、バイトのみが表示され、それらのバイトを文字に変換する方法は指示されません。そして、何を推測しますか？異なるブラウザはそれを行うために異なるエンコーディングを使用します。
OperaとChrome UTF-8を使用します。
IEは、クライアントシステムのデフォルトのコードページ（もちろんUTF-8ではありません）を使用し、Windows標準を使用して、それに適合しない文字をマングルします。少し似ているか、そうでないかもしれません（Who Cares）アルゴリズム。
SafariはISO-8859-1を使用し、ユーザー名またはパスワードに収まらない文字が含まれている場合、認証トークンの送信を黙って拒否します。
Mozillaは、コードポイントの下位8ビットを取得します（ISO-8859-1に似ていますが、より壊れています）。結果や進展のない曲がりくねった議論については、 バグ41489 を参照してください。
したがって、ASCII以外のユーザー名またはパスワードを許可すると、基本認証プロセスはせいぜい複雑で一貫性がなくなり、ユーザーは、異なるコンピューターやブラウザーを使用すると、なぜランダムに機能するのか、失敗するのか疑問に思います。
いいえ。パスワードをASCII文字に制限してください。
パスワードを入力すると、パスワードを隠すための箇条書きが表示されます。
ただし、日本語やその他の言語を入力する場合は、入力方法を使用して、キーストロークを目的の文字に変換する必要があります。これには、キャラクターが何であるかを確認する必要があります。
プログラムによるマッチングを行う必要がある場合、Unicodeは最悪です。 「マイナス記号」と「ダッシュ」は同じように見えますが、別々のコードである可能性があります。 「面白いチルダがかかっているn」は、1文字、または発音区別符号と1文字の場合があります。
異なるエンコード方法を使用している場合、パスワードは同じように見えても、パスワードが一致しない可能性があります。 omg-ponies aka humanity = epic fail を参照してください。
正規化することはできますが、次の場合に何が起こりますか。
- 正規化ルールが変更されます
- パスワードに発音区別符号を使用しているユーザーがいます
- パスワードに文字を組み合わせたユーザーがいます
- パスワードはハッシュ化されているため、パスワードを変更することはできません
何を推測しますか-一部のユーザーでパスワードを強制的にリセットする必要があります。
私はすべてのWebアプリケーションでUnicodeパスワードをサポートしています。最近のブラウザを使用している場合、訪問者は優先スクリプトまたはネイティブスクリプトで任意のコードポイントを使用できます。
セキュリティを強化するために、可逆暗号化を使用するのではなく、ソルトハッシュを保存します。
重要なことは、バイトシーケンスをハッシュに追加する前に、パスワード文字列を正しく正規化してエンコードすることです（エンディアンの独立性のためにUTF-8を好みます）。
良いアイデア。
パスワードを強化し、ユーザーにより多くの自由を与えます。そして、それはすでにWindows（少なくともWin 2000以降）、Active DirectoryとLDAP、Novell（少なくとも2004年以降）によって行われています。
一部の顧客はそれを望んでおり（ http://mailman.mit.edu/pipermail/kerberos/2008-July/013923.html ）、それを正しく行う方法についての基準さえあります（ https://tools.ietf.org/html/rfc8265 、廃止 http://tools.ietf.org/html/rfc401 、Johnに感謝）。
hTML 5では、ユーザーにフォントを送信する機能を備えているため、システムにビジュアルキーボードを統合できるため、ユーザーはあなたの言語を使用できます。
ヒント： Deja Vu font を使用し、 FontForge を使用して変更して、小さくしてから、ビジュアルJavaScriptキーボードを使用して可能にします;）
ここを見てください 、それは私がトリックをしたプロジェクトです。
これらのサイトの多言語対応はユニコードをサポートしていると確信しています。技術的な課題というよりは、ユーザー要件の問題のように思えます。
クライアントがパスワードを送信しているエンコーディングがサーバーにわからないという技術的な問題があったとしても、私は驚かないでしょう。
ただし、たとえば、主に日本語、中国語、またはロシア語を母国語とするサイトでは、パスワードに一般的に使用されるそれぞれの非ASCII文字セット（Big5、EUC-KR、koi8など）を使用すると思います。たぶん、Unicode以外のものを使用して、古いWebクライアントに対処するために彼らが何をしているのかを調べることができます。