クライアント側でパスワードハッシュを実行する必要がある場合、サーバー側のソルティングをどのように実装できますか?
私が考えることができる最初の解決策は、ハッシュを実行する前に、サーバーの users テーブルからユーザーのソルトを要求することです。しかし、それは、ユーザーの有効なソルトを彼に与えるので、ユーザーが「存在する」ことを確認していることを意味します。
また、ソルトをユーザーのテーブルに保存する代わりに、ソルトをユーザーが利用できるもの、たとえばユーザー名のバリエーションにすることもできると考えました。しかし、サーバーとクライアントは、提供されたユーザー データからどのように正確にソルトを取得したかを覚えておく必要があるため、一貫性の問題が発生する可能性があります。
これを行う最善の方法は何ですか？
ログインに HTTPS がない場合、クライアント側のハッシュは便利ですが、ハッシュやソルトの方法が明らかになるなど、いくつかの欠点がある可能性があります。そうは言っても、彼らがあなたのパスワード ハッシュ データベースにアクセスできる場合、彼らはおそらく既にその情報にアクセスしています。
サーバー側のソルトのみを行うには、ソルトとパスワード ハッシュを使用してパスワードを再ハッシュする必要があります。このシナリオでは、ユーザー名、ソルト (ユーザー名とパスワードのハッシュ ソルトを使用しない場合)、および 2 番目のハッシュのみを保存します。
あなたの例のように、クライアントとサーバーの両方でソルトを実行したい場合は、ユーザー名と初期パスワード ハッシュを組み合わせてソルトすることをお勧めします。誰でもあなたのソルト方法をチェックし、それをパスワード クラッカーに適用することさえできるので、ソルトがクライアントに知られることはありませんが、レインボー テーブルを使用して同じパスワード ユーザーをクラックすることは避けられます。
ユーザー名を単独でソルトとして使用しないでください。一般的なユーザー名 (例: admin) の場合、このソルトを含むテーブルが既に存在する可能性があります。
nyde1319 の回答を使用する際の問題 (申し訳ありませんが、回答にコメントする権利がありませんでした) は、パスワード + ソルト ハッシュを実行するために、データベースに暗号化されていないバージョンのパスワードが必要になることです。ハッシュの目的を無効にする。ハッシュ化されたバージョンのパスワードを使用して行われた場合、最初のハッシュを保存する必要があり、ソルトの目的を無効にしてそのハッシュをクラックできます。
私はこのトピックに関して専門家ではありませんが、あなたが言及した解決策と一緒に1回限りの塩のようなものを使用するのはどうですか.
つまり、短い時間枠でランダム シードに基づいてソルトを生成するソルティング関数をクライアントに提供します。シード自体は動的で、しばらくすると変化し、サーバーとクライアント間で同じでなければなりません。結局のところ、塩は秘密である必要はありません。
クライアント側で、一意であると仮定して、ユーザー名 (または利用可能なユーザー データ) を使用してソルトを生成します。次に、連結されたパスワードとソルトでハッシュを生成し、サーバーに送信します。
サーバー側では、ユーザー名を入力としてクライアントで同じソルティング関数を使用してソルトを計算します。次に、同じようにハッシュを生成し、2 つの値が一致するかどうかを判断します。認証を成功させるのに十分な時間枠を確保する必要があります。