パスワードにラテン語以外のUnicode文字を使用することは良い考えですか？
現実的な時間で解読できないように、適切なパスワード（推測しにくい、辞書の単語やその順列ではなく、少なくとも一定の長さなど）を作成する方法については、多くの提案を聞いています。ただし、私が理解していることから、パスワードクラッキングテクニックとソフトウェアは、USキーボードで通常見られるラテン文字、数字、特殊文字を使用しようとします。したがって、いくつかの非ラテン文字をパスワードに含めることは良い考えでしょうか？
たとえば、「passw密码rd」です。
おそらくそうではありません-パスワードの入力に必要となる可能性のあるデバイスのサポートされている文字セットによっては、多くの互換性の問題が見つかります。
強力なパスワードを持っていることを確認する方法は2つあります。
- 攻撃者が認識していないエントロピーのソースを使用します。
- ブルートフォースが実行不可能になるように、十分なエントロピーを使用してください。
提案する方法のアプローチは前者です。通常、後者のアプローチの欠点は少なくなります。 128ビット以上のエントロピーを持つパスワードを使用する場合、妥当な時間内に推測することはできません。それは平均です-攻撃者がveryラッキーである場合、彼らは最初にそれを推測するかもしれませんが、すべてのパスワードで同じことが当てはまります。
したがって、128ビットのエントロピーを取得するには、少なくとも20個の完全にランダムな文字（大文字と小文字、数字とASCII記号を使用）を含む）が必要か、ランダムに選択された10個が必要です ダイスワード 。
だから私の意見では、これはすでに解決された問題です。安全なパスワードジェネレータを使用して、覚える必要がない場合はランダムな20文字のパスワードを作成します。覚えている場合はDicewareを使用します。
通常、はい。一部のシステムでは、非ラテン文字をサポートまたは許可しない場合があります。バックエンドでは、非ラテン文字を処理するためにデータベースと他のシステムを適切に設定する必要があります。そうしないと、予期しないことが発生する可能性があります。たとえば、1つのマルチバイユニコード文字が複数のシングルバイト文字として解釈される場合があります（または、予期されるサイズが、使用されているエンコーディングにある場合）。
システムが入力を受け入れ、パスワードを入力するすべての場所で言語を切り替えることができる場合は、問題ありません。すぐに頭に浮かぶのは、許可される最大文字数があるかどうか、マルチバイト文字を使用しているために制限を超えてしまうか、または何らかのタイプの切り捨てを実行するかどうかです。ラテン文字のみが許可され、入力にフラグが付けられるかサニタイズされる可能性があると想定して、組み込みのセキュリティフィルターの種類がある場合もあります。これらの条件はすべて、特定のシステムとそれがサポートするものに依存します。
互換性の問題があるかどうかをテストして確認する必要があるかもしれません。ただし、1つの文字を2つ以上考慮した場合のボーナスポイントは、より多くの部分を覚える必要なく、より長いパスワードを提供します。システムが入力を受け入れ、それが適切に機能する場合。奇妙な問題に遭遇した場合、うまくいけば、リセットしてプレーンラテンセットを使用できるようになります。
参考までに、基本的なテキストからバイナリへの変換を行うだけです。
passw密码rd = 01110000 01100001 01110011 01110011 01110111 11100101 10101111 10000110 11100111 10100000 10000001 01110010 01100100
(9 "characters", 13 bytes)
password = 01110000 01100001 01110011 01110011 01110111 01101111 01110010 01100100
(8 "characters", 8 bytes)
ある意味、これはコンピュータが実際に見るものです。そのため、システムがユニコードに対応していない場合は、問題が発生したり、passw密码rdをpasswå¯ç rd、passw密码rdなどとして解釈したりする可能性があります。パスワードをハッシュすると、ある方法でパスワードが表示される場合があり、ハッシュを後で比較する関数では別の方法で表示される場合があります。
はい、それらのキャラクターを使用するのは素晴らしい考えです。
passw密码rdは、パスワードから2文字離れているため、おそらく最良の例ではありませんが、password11、p4ssw0rd、または類似の置換よりも確かに安全です。
これらの文字は平均的なキーボードではそれほど便利ではないため、ログインプロセス中に追加の作業が必要になるため、ほとんどのユーザーはおそらくこれらの文字を使用しません。ハッカーはこれを知っており、可能性が高いこれらの文字を頻繁に試さないでしょう。これは、これらの文字の使用が総当たり攻撃からユーザーを保護するいくつかのキーであることを意味するものではありませんが、大幅に保護が強化されます。このようなUnicode文字を使用すると、可能な文字数が大幅に増加し、ブルートフォース攻撃の可能性が高くなります。このため、ハッカーは「可能性が低い」より小さな文字セットを使用する人々である「ぶら下がっている果物」をターゲットにすることを決定する可能性が最も高いでしょう。
それは非常に悪い考えだと思います。 Webサイトがパスワードをサニタイズしている方法についての洞察がないため、サニテーションの後に（aとして保存されることになる、大量のエントロピーを含む長いUnicodeパスワードを入力する状況に簡単に終わる可能性があります。ハッシュ）ASCIIこのパスワードに含まれる印刷可能な文字（またはUnicodeから正規化された衛生コード）のみ、または空の文字列（ハッシュが含まれていない場合）としても（ハッシュ）。
したがって、あなたは非常に優れたセキュリティを持っていると思い、実際にはパスワードが（ハッシュ）非常に少数のASCII印刷可能な文字または前述の空の文字として保存されることになります。文字列です。Unicodeパスワードでログインすることはできますが、少数のASCII文字をブルートフォースで強制したり、サニタイズされた十分なUnicodeを挿入したりすることができる他の誰もが保存できます。ストリング）。
さらに、彼らが衛生コードを変更した場合、あなたはあなたのアカウントから締め出されるかもしれません。
非ASCIIのUnicode文字は、ホテルのビジネスセンターなど、管理されていないマシンから入力する必要がある場合、表現の問題を引き起こす可能性があります。最初に、予期されたエンコーディングがありませんでした。たとえば、éはU + 00E9またはラテン小文字E WITH ACUTEです。通常、UTF-8では2バイトの"\xc3\xa9"としてエンコードされますが、Latin-1文字セットでは1バイトの"\xe9"です。
さらに、2つの異なる正規化形式があります （1）。 U + 00E9：正規化形式C（または正規化合成）および正規化形式D（または正規化分解）がU + 00E5の場合U + 0301：ラテン小文字Eと組み合わせたアクセントのアクセント。定義により、これらの2つのフォームは同じグリフに対応しますが、ほとんどすべてのアプリケーションは、言語が異なる文字列であると言っています。また、キーボードからASCII以外の文字を入力した場合、どのフォームが使用されるかはほとんどわかりません。
簡単に言えば、非ASCII文字を追加すると、エントロピーが大きくなりますが、フォアシステムからパスワードを入力できないというリスクがあります。そして、より長い長さは一般に、いくつかの非ASCII文字を追加するより高いエントロピーゲインです...
（1）nicode正規化形式