制限された範囲ではなく、Unicodeの範囲全体を使用してランダムなパスワードを生成することは良い考えですか？
セキュリティが低いサイトやアプリの中には、パスワードを英数字のみに制限しているものや、やや広いASCIIの範囲を許可しているものがあります。一部のサイトやアプリはUnicodeもサポートしています。
パスワードは通常、すべての汎用キーボードで入力できるようになっているため、通常、一般的に利用可能な文字を使用して生成されます。しかし、デジタルでのみ保持されるパスワードの場合、Unicodeの文字範囲全体を使用して推測時間を最大化することは良い考えでしょうか？それとも、一部またはほとんどのUnicode対応サイト/アプリが、許可されている文字の範囲を制限できると信じる理由はありますか？
これはセキュリティの観点からは良い考えです。 Unicode文字を含むパスワードは、同じ長さのASCII文字を含むパスワードよりもブルートフォースを実行するのが困難です。Unicodeは最上位ビットASCIIはそうではありません。
ただし、Unicodeのバグは非常に一般的であるため、実用的ではないと思います。どこでもUnicodeパスワードを使用すると、開発者がパスワードのUnicodeサポートを正しく実装しなかったため、ログインに問題が発生するサイトが2つ以上発生することになると思います。
これはFencepost Securityによく似ています。 500フィートの高さの周りにチェーンリンクフェンスがある施設を運営しているとしましょう。フェンスを3,000フィートの高さにすると、セキュリティはどの程度向上しますか？なし-入ろうとする人は500フィートを登るつもりはないからです。彼らは下を掘ったり穴をあけたりするつもりです。
同様に、たとえば、ランダムな20文字の英数字からなるパスワードがあります。それは62 ^ 20の可能性です。 20個のランダムなUnicode文字に変更することを検討しています。これは、20文字のランダム化されたパスワードを総当たりすることは、物事が危険にさらされる方法ではないことを除いて、可能性のスペースをはるかに高くします。
Security by Obscurityの議論を無視すると、それはエントロピーの基本的な問題です。 8文字のUnicodeパスワードは、8文字より安全ですASCIIパスワードですが、64文字より安全ではありませんASCIIパスワード。
一般的に私はシェードに同意します-これらは利益よりも不便を引き起こす可能性があります。さらに、手動でパスワードを入力する必要がある場合は、ランダムなUnicodeを使用すると、人生が悲惨になる可能性があります。
ただし、パスワードの最大長の制限を適用しながら、Unicodeをアクティブにサポートするサービスを使用する必要があるEdgeの場合（これを無視すると、通常、他のセキュリティエラーが発生することを示します）、そのための引数があります。
パスワードにUnicode文字を使用するために考えられる唯一の正当な理由は、特定のサイトのパスワードの文字数（バイトではない）が制限されている場合です（このダムバンクのように 以前はありました 最大10文字）なので、1日か2日で簡単に推測できます。この場合、Unicodeを使用して（サイトの所有者から許可されている場合）、当面の間、サイトの所有者に準拠を依頼する間に、より多くのエントロピーをパスワードに取り込むことができます NIST 800-63- および長さの制限を取り除きます（パスワードを適切に保存するため、ハッシュは適切にハッシュしてください）。
私もここで誤解を訂正したかった：
Unicodeは最上位ビットを使用しますが、ASCIIは使用しません。
通常のASCIIには当てはまりますが、一部のパスワードマネージャー（KeePassなど）がパスワード生成に使用できる拡張ASCIIは、各バイトのすべてのビットを使用するため、Unicodeよりもエントロピー密度が高く、エントロピー密度はいくつあるかを示す構造を持っています。次のバイトの一部は同じ文字の一部です（ただし、isnicodeの無効なバイトシーケンス ）。
短いパスワードに制限しているサイトでは、おそらくパスワードが適切にハッシュされない（Unicodeパスワードが失敗したり、間違ったエンコードで保存されたりする）ため、Unicodeパスワードに煩わされる時間をほとんど無駄にしないでください。面白い文字に気を取られて（そして、パスワードが奇妙に保存されているためにパスワードをリセットしなければならないという事実）、攻撃者はあなたの （in）-security質問 を推測したり、- chocolate暗号を使用したりする可能性があります。 アカウントにアクセスします。
このアプローチは、特定の場合に全体的なセキュリティを低減できますが、改善することはできません。
情報セキュリティは、機密性、整合性、および可用性（ CIAトライアド ）の3つの属性で構成されます。 1つだけに集中することで、他の重要性を簡単に見過ごすことができます。
パスワードの機密性は、エントロピーの原則によって達成されます。パスワードはどのように「推測不可能」ですか？これは通常、ブルートフォース推測スペースのサイズによって測定され、2の累乗またはビットで表されます。ブルートフォース攻撃者は、推測する能力がそれほど多くありません。より長いパスワードを選択してこのエントロピーを増やすことにより、既知または予測されている機能を超えて推測することができます。 80ビットを超えるエントロピーを取得する（または値を選択する）と、パスワードは国民国家の俳優でさえも手の届かないところに置かれます。上記の過度に簡略化された説明に関係なく、要点は、「到達不能」の範囲を超えても、セキュリティが大幅に向上しないことです。また、10個のUnicode文字または17個のASCII文字を使用して目的のエントロピーを実現する場合、セキュリティには関係ありません。
可用性とは、「必要なときに自分のデータにアクセスできるか」という意味です。完全なUnicode文字セットを使用すると、Unicodeをサポートしていないさまざまなサイト、Unicodeを正しく実装していないブラウザやOS、またはUnicodeを不可視にASCII結果として生じる混乱により、データへの将来のアクセスを制限するリスクが高まります。これは、将来の可用性が低下する可能性があることを示しています。
一般的に、攻撃者が80ビットのパスワードを総当たりする可能性は、Unicodeを適切に処理しない、不十分にコーディングされたサイトに遭遇する可能性ほど高くはありません。したがって、全体的なセキュリティが向上する代わりに低下する可能性があります。
もちろん、多くのサイトにはパスワードの長さや、パスワードのエントロピーを劇的に制限するその他の制限があります。そのような場合、完全なUnicodeセットを使用すると、他の隠れた欠陥がないと仮定して、パスワードのエントロピーが増加する可能性があります。したがって、これらのサイトでは、セキュリティを改善している可能性があります。しかし、サイトがパスワードデータを適切に処理しているかどうかを外部から見分けることは事実上不可能です。
これは直接的な回答ではないかもしれませんが、パスワードがデジタルでのみ保持されている場合は、バイト配列ではなくpasswordを生成する理由を自問する必要があります。全体を単なるバイトとして見ると、質問はもう当てはまりません。
また、パスワードに関連するすべてのものの長さ>複雑さ。
あなたの問題にはRFCがあります： ユーザー名とパスワードを表す国際化された文字列の準備、施行、比較
このドキュメントでは、ユーザー名とパスワードを表すUnicode文字列を処理するための更新されたメソッドについて説明します。以前のアプローチはSASLprep（RFC 4013）として知られており、Stringprep（RFC 3454）に基づいていました。このドキュメントで指定されている方法は、国際化されたユーザー名とパスワードの処理に対するより持続可能なアプローチを提供します。
フランス語を読んでいる場合は、こちらでよく説明されています http://www.bortzmeyer.org/8265.html 。
RFCのセクション8は、「任意の」Unicode文字を使用したパスワードのセキュリティを具体的に扱っており、次のセクションがあります。
- 8.1。パスワード/パスフレーズの強度
- 8.2。パスワード/パスフレーズの比較
- 8.3。識別子の比較
- 8.4。 PRECISの再利用
- 8.5。 Unicodeの再利用
他の良い答えに加えて、whatを指摘したいのですが、パスワードに完全なUnicodeセットを使用すると、パイプがうまくいかなくなります。
多かれ少なかれ有効なUTF-8文字列をランダムに使用すると仮定すると、
- + 2029段落区切り文字 のように、基本的な多言語プレーンの途中で改行として解釈される文字があります。単純な_
<input>_フィールドにそれらを入力できない可能性があります。 - 言語の
trim()メソッドによって削除される場合とされない場合がある両方の空白文字があります - サロゲート文字（U + D800-U + DFFF）、 非文字+ FDD 、プライベート使用文字、または割り当てられていない文字（有効なUTF-8シーケンスですが）特定のツールセットの動作は基本的に定義されていません（ストリッピング、置換、拒否、何もしない、またはこれらの組み合わせ）。
- 分音符号を追加した場合、進行中のツールにより、それが NFCまたはNKD 表現に変更され、パスワードのバイトが変更される可能性があります。
- それは頭のてっぺんからです。 Unicodeの範囲全体からパスワードを選択した場合、他に考えられる多くの問題を忘れたと思います。
したがって、@ JohnDetersが提案したのと同様に、ソーススペースを大きくすることによる利点は、途中のテキスト処理の可動部分に勝るので、悪い考えかもしれません。
他の人は、それらのパスワードを使用するサービスがUnicodeを正しく実装しないリスクについて十分に述べています。 todayがそうする可能性があるサービスを追加しますtomorrowはそうしませんが、そうでない場合はそのトピックをスキップします。
ここで考慮しなければならない1つの要素は、質問することです。特定のセキュリティレベルを達成するために、パスワードはどれくらいの期間必要ですか。私たちのパスワードを128ビットの暗号化キーと同じくらい強くしたいとしましょう（これは、ほとんどのWebサイトのパスワードでは多すぎるので、80ビットをお勧めします）。ランダムに固執する場合ASCIIパスワードの場合、95桁の印刷可能文字から抽出された19文字のパスワードASCII文字はそのレベルに達します。計算：セット約100要素の場合、約6.6ビット/要素（log2（10）、3.3、log2（100）はその2倍であるため）、128÷6.6≈19.4。19ASCII文字は実際には128ビットではなく約126ビットですが、まあ）
Unicodeには現在約130,000のコードポイントが定義されており、この数は2 ^ 17と近似します。つまり、128ビットレベルに到達するには、7つのUnicodeコードポイントが必要です（128÷17≈7.5、したがって、7つのコードポイントは約119ビットですが、繰り返しますが）。
80ビットのセキュリティレベルでは、ほとんどのWebサイトでより適切であると私は考えています。12ASCII文字対5つのUnicodeコードポイント）です。
12文字または19文字ではなく5文字または7文字のパスワードを使用できるようにするために、ユーザビリティに大きな打撃を与え、Webサイトのバグを危険にさらすことをいとわないでしょうか。それだけの価値があるとは思いません。
セキュリティにとって重要なのは、パスワードのエントロピーです。つまり、パスワードには実際の情報が何ビットあるのでしょうか。
問題の反対側は、パスワードを覚えて、パスワードを入力するのがいかに難しいかということです。 iPhoneでパスワードを入力しようとして、それができないことに気付いたとします（任意のUnicode文字を入力するのがどれほど難しいかは確認していません）。または、100％正確に入力することは非常に難しいことに気づくでしょう。または、それは単にあなたの年齢を必要とします-私は同じエントロピーとより多くの文字を持つパスワードを持っているかもしれませんが、2倍の速さで入力できます。そして、あなたはそれを正しくするために4回の試行が必要ですが、私のものは初めて正しいです。
ランダムなUnicodeパスワードを生成することはお勧めできません。生成されたパスワードはユーザーに読めない可能性があるためです。しかし、質問のテキストはUnicodeパスワードの使用について語っています。これは良いアイデアであり、NIST 800-63-3セクション 5.1.1.2記憶された秘密検証 によって推奨されています：
検証者は、加入者が選択した記憶された秘密の長さが少なくとも8文字である必要があります（SHALL）。検証者は、加入者が選択した記憶された秘密を少なくとも64文字の長さで許可する必要があります（SHOULD）。すべての印刷ASCII [RFC 20]文字およびスペース文字は、記憶された秘密で受け入れられる必要があります（SHOULD）。Unicode[ISO/ISC 10646]文字も受け入れられる必要があります（SHOULD）。
上記の長さの要件のために、各Unicodeコードポイントは単一の文字としてカウントされるものとします（SHALL）。
それは続く：
記憶された秘密でUnicode文字が受け入れられる場合、検証者は、Unicode標準付属文書15のセクション12.1で定義されているNFKCまたはNFKD正規化を使用して、安定化文字列の正規化プロセスを適用する必要があります（SHOULD）。
要約すると、Unicodeを使用すると、エントロピーが増加し、英語に習熟していないユーザーの生活が楽になります。
まあ、Unicodeは130000文字を超えるものの「単なる」リストです。 UTF-8は、1つの大きな数値を受け取り、それを一連の規則に従ってbase-256数値（より正確には、バイナリオクテットでより意味のあるもの）に「変換」する最も一般的なエンコーディングです。したがって、utf-8エンコーディングを使用したい場合、多くのルールに縛られて、希望するランダム性を効果的に減らすことができます。また、Unicodeの解釈全体をどのように使用すればよいかわかりません。
印刷可能な文字に関心がない場合は、ASCII（またはより好ましくは8ビットの拡張）全体を検討することもできますが、その時点で、なぜ文字解釈の標準にさえ迷惑をかけているのでしょうか。では、単純なフォームレスランダムバイナリ構造を単に使用しませんか？
デジタルストレージのみを使用している場合でも、何かを入力する必要があり、（と（の違いを認識しなかったユーザーです。（ヒント：ダブルスペースとシングルスペースです）
この幅に敏感な例を使用すると、他の回答で指摘されているように、これらのサポートが機能することを期待しています-ここで設定されたSQL照合に応じて、正しくないパスワードが正しくなります！
いいえ。多くの問題が発生する危険を冒しながら、指数関数のベースを増やしたいと考えています（つまり、特殊文字を入力できないデバイスなど）。 Unicodeパスワードのエントロピーを計算し、ASCIIパスワードをエントロピーが大きくなるまで長くします。
_a-z_のみは26 ^（長さ）です。 256^(length)を取得し、Unicodeで1文字あたり2バイトを取得するとします。そうすれば、どこかで26^(ascii_length) > 256^(2*unicodelength)のブレークを見つけることができます。この長さを_ascii_length_として選択すると、パスワードを書き留めることができ、セキュリティは同じです。
サイトが長いパスワードをサポートしていない（恥ずかしい）場合は、Unicodeの適切なサポートも保証できないと思います。多分あなたは彼らが次にいくつかの内部ライブラリをアップグレードするときにロックアウトされるでしょう。では、なぜ問題が発生するリスクがあるのでしょうか。そして、ユーザーサポートに説明するのが難しい問題です。Unicodeの意味がほとんどわかりません。