8

Unicode パスワードのサポートを追加することは、開発者が無視してはならない重要な機能です。

それでも、パスワードに Unicode のサポートを追加するのは難しい作業です。なぜなら、Unicode では同じテキストがさまざまな方法でエンコードされる可能性があり、そのためにユーザーがログインするのを妨げたくないからです。

パスワードを UTF-8 として保存するとします。この質問は Unicode エンコーディングとは関係なく、Unicode の正規化に関連していることに注意してください。

問題は、Unicode データをどのように正規化するかです。

比較できるかどうかを確認する必要があります。次の Unicode 標準がリリースされたときに、パスワードの検証が無効にならないようにする必要があります。

注: Unicode パスワードがおそらくまったく使用されない場所もいくつかありますが、この質問はUnicode パスワードを使用する理由や時期に関するものではなく、適切な方法でそれらを実装する方法に関するものです。

1回目の更新

OSを使って正規化するように、ICUを使わずにこれを実装することは可能ですか?

4

2 に答える 2

6

良いスタートは、Unicode TR 15：UnicodeNormalizationFormsを読むことです。次に、それは多くの作業であり、奇妙なエラーが発生しやすいことに気付きます。ここで質問しているので、おそらくこの部分をすでに知っているでしょう。最後に、ICUのようなものをダウンロードして、それを実行させます。

IIRC、それは多段階のプロセスです。最初に、それ以上分解できなくなるまでシーケンスを分解します。たとえば、éはe +´になります。次に、シーケンスを明確に定義された順序に並べ替えます。最後に、UTF-8または同様のものを使用して、結果のバイトストリームをエンコードできます。UTF-8バイトストリームは、選択した暗号化ハッシュアルゴリズムにフィードして、永続ストアに保存できます。パスワードが一致するかどうかを確認する場合は、同じ手順を実行し、ハッシュアルゴリズムの出力をデータベースに保存されているものと比較します。

于 2010-05-09T19:34:14.090 に答える
0

もう一度質問です。「ICU を使用せずに」を追加した理由を説明していただけますか? 多くの質問で、ICU がかなりうまく機能している (私たち*が考えている) ことを尋ねられますが、「ICU を使用せずに」です。ちょっと興味があるんだけど。

次に、単なる正規化ではなく、StringPrep/NamePrep に関心があるかもしれません: StringPrep - 比較のために文字列をマップします。

第三に、他の Unicode セキュリティへの影響について、 UTR#36とUTR#39に興味があるかもしれません。

* (開示: ICU 開発者 :)

于 2010-05-10T17:40:35.160 に答える