ユーザー名を変更するときにユーザー名とパスワードが一致しないようにするにはどうすればよいですか？
セキュリティ要件の1つが、ユーザーが自分のユーザー名と一致するパスワードを選択できないようにしているシステムがあるとします。ユーザー名では大文字と小文字が区別されませんが、パスワードでは区別されます。パスワードは、元に戻すことができない安全なハッシュ関数を使用してサーバーによって保存されます。
アカウントが作成されると、ユーザー名とパスワードの両方が最初にプレーンテキストでサーバーに提供され、比較できるようになります。それらをメモリ内で比較して（大文字と小文字は無視して）、一致するかどうかを確認し、一致する場合は別のパスワードを選択するようユーザーに指示できます。このチェックが完了すると、ユーザー名がプレーンテキストで保存されている間、パスワードは安全にハッシュされて保存されます。ここで要件を満たす問題はありません。
ユーザーが自分のパスワードを変更する場合、または変更する場合、サーバーはユーザー名のレコードを取得し、それを新しく選択されたパスワードの値と比較して（大文字と小文字を区別しない）、一致するかどうかを確認します。ここでも要件を満たす問題はありません。
ただし、システムはユーザー名の変更も許可します。このID変更プロセス中、ユーザーは必ずしもパスワードをプレーンテキストでサーバーに提供していません。認証時にそうした可能性がありますが、ユーザー名を変更する場合に備えて、サーバーはそのパスワードをプレーンテキストで保存しません。したがって、プレーンテキストのパスワードは、新しく選択されたユーザー名の値との一致をチェックするために使用できません。
要件を満たすために、サーバーは同じ安全なハッシュ関数を使用して新しいユーザー名をハッシュし、記録されたハッシュされたパスワードと比較できます。それらが一致する場合、サーバーはユーザーに別のユーザー名を選択するように指示できます。ただし、ユーザー名では大文字と小文字が区別されないため、間違いなくこのチェックは失敗する可能性があります。 「PwdRsch1」を新しいユーザー名の選択肢として送信し、パスワードが「pwdrsch1」の場合、ハッシュが一致しないため、システムで許可されます。その後、私（またはさらに悪いことに、攻撃者）は、一致するユーザー名とパスワード "pwdrsch1"で後で認証に成功する可能性があります。
ユーザー名をハッシュしてパスワードと照合する前に小文字にすることもできますが、その逆のシナリオも可能です。ユーザー名は、「PwdRsch1」のパスワードに対して「pwdrsch1」としてチェックされ、これらが一致しないため許可されます。しかし、後で「PwdRsch1」の一致するユーザー名とパスワードで認証に成功します。
大文字と小文字を区別しないユーザー名とパスワードが一致するこのリスクを軽減するには、どのような合理的なオプションがありますか？
ユーザーが自分のユーザー名を変更したときにパスワードを要求するのが、必要なものを取得するための唯一の賢明な方法です。このようにして、サーバーは変更中にユーザー名とパスワードを正確に比較し、一致を防ぐために必要な情報を常に持っています。
パスワードの変更、またはユーザー名の場合はユーザー名などの機密性の高い操作は、（XSSの損傷を制限するために）とにかくパスワードを要求するはずなので、これは問題になりません。
他の唯一の選択肢は、考えられるすべてのケースの組み合わせを試し、それをハッシュし、ユーザーがユーザー名を変更したときに、保存されているハッシュと比較することです。
細かいところに少し反する-しないでくださいユーザー名がパスワードとして「実質的に類似した」文字列に変更されているかどうかに注意してください。同じパスワードを選択する危険性についてユーザーに警告し、同一の一致を確認します。
いくつのルールを設定したとしても、ユーザーが決心すれば、それらを回避する方法が見つかります。必要な場合は、ユーザー名の変更時にパスワードの入力を要求することで、ユーザーに同じ大文字小文字の区別を強制するか、そのまま許可して次回ログイン時にユーザー/パスの変更を強制するかを確認できます。
only問題が発生するのは、ユーザーが標的型攻撃を受けた場合です。ランダムなスクリプトキディ（または他の日和見主義者）がユーザーリストを入手した場合、ユーザー名を照合するよりも高度なツールを使用してパスワードを解読できます。同様に、標的となった攻撃者もそうですが、キーボードに直接入力できる簡単なことから始めます。そして、それがパスワード「PwdRsch1」を解読しようとしているインテリジェントな人物である場合、大文字と小文字の違いを確認するだけで本当に安全ですか？ 「pwdr5ch1」はどうですか？ 「PwdRsch2」？ 「1hcsRdwP」？考えられるこれらのシナリオのいずれかのルールを記述できますが、忘れたルールがあるか、ユーザー名とパスワードの組み合わせを選択するのが非常に難しくなるため、「P4ssw0rd！」を使用するだけです。そしてそれで終わります。
教育はonlyを使用してユーザーに本物の安全なパスワードを使用させる方法であり、準拠していないパスワードが常に存在します。
ユーザー名に10文字あるとします。これは、大文字と小文字の1024通りの組み合わせです。それらすべてをチェックしてください。
小文字のパスワードハッシュを保存しないでください。その1024は不便に思えるかもしれませんが、攻撃者にとって1日と3年の違いです。
ユーザーIDとパスワードを異なるセットから取得するように強制する必要があります。コメントでは、ユーザーIDはユーザーの正式名から「John Smith」->「jsmith」および「Jane Doe」->「jdoe」の形式で続かなければならないようです。次に、JaneがJohnと結婚して名前を取得した場合、彼女のユーザーIDは「jsmith2」のようなものに変更する必要があります。
したがって、パスワードの最初の文字を記号にするか、パスワードに記号を含める必要があると規定できます。
ユーザーIDが8文字で切り捨てられる場合は、パスワードに少なくとも9文字を含める必要がある場合があります。
リストの姓と名のリストのデカルト積を取り、それをパスワードのブラックリストとして使用できます。従業員がリストにない名前を持っている場合は、それを追加します。人々がパスワードを変更すると、問題は自動的に修正されます。
これは答えではありません。人々にこれを行わないでくださいになるように、私はそれについてのみ言及しています。
大文字と小文字が区別されるパスワードの通常のハッシュに加えて、すべて小文字に変換されたパスワードのハッシュを保存することが理にかなっていると判断する場合があります。
これで問題は確実に解決します-変更するユーザー名を小文字にして、格納されている小文字のパスワードのハッシュと比較するだけです。
明らかな欠点は、これが最初にハッシュされたパスワードの目的を部分的に無効にすることです。つまり、パスワードリストへの攻撃をはるかに難しくします。ハッシュされたパスワードリストにアクセスする攻撃者は、大文字と小文字を区別するハッシュではなく、はるかに弱い（2 ^ n倍弱い）小文字のハッシュを攻撃することができます。
したがって、言及されている他のオプション（変更時にパスワードを要求する、管理者がパスワードを変更する場合はすべての大文字と小文字の順列を試す、理想的には最も可能性の高い順序で最初に行う）の方がはるかに良いと思われます。
すでにいくつかの素晴らしい答えがありますが、これはこの問題に取り組む別の方法です。新しいユーザー名を既存のパスワードと比較する代わりに、ユーザーがユーザー名を変更するたびにパスワードを強制的に変更することができます。
当然、ユーザー名を変更するにはパスワードを変更する必要があることをユーザーに警告する必要がありますが、既存のプロセスを簡単に使用して、ユーザー名に対して新しいパスワードをチェックできます。
ユーザーが愚かなパスワードを選択できないようにする唯一の方法は、パスワード生成ポリシーを強制することです（ひどく一般的なパスワード形式とは対照的） ポリシー）。
ここで、ユーザーに対してそれほど多くの権限がない場合（ほとんどのWebサイトにはありません）、少なくともパスワードマネージャでパスワードを生成するように指示する必要があります（そして dice でマスターパスワードを生成します） =）、そしてあなたはこの方針に従わないことを困難にすることができるかもしれません：
これを行う方法の1つは、パスワードフィールドにキーボード入力を許可せず、貼り付けたデータまたはマシンタイプのデータのみを入力することです（文字の入力速度を確認することをお勧めします）。次に、パスワードポリシーを説明するボックスを赤または何かで概説して、注意を引き付けることができます。
最も賢明な解決策はすでに言及され受け入れられていますが、ユーザー名を変更するときにパスワードを要求するのは、とにかくそうする必要があるためです。別の方法として、小文字のパスワードのハッシュ（別のsaltを使用して？）も保存し、すべて小文字のユーザー名と比較します。