PBKDF2とパブリックソルトを使用したWebサービス認証-ソルトはリクエストごとに変更する必要がありますか？
一部のWebサービスにPBKDF2認証を実装しました。
クライアントには次の情報が提供されるため、PBKDF2関数を複製できます。
- ハッシュアルゴリズム（SHA256）
- 30バイトの長さの秘密のパスワード
- 反復回数（4096）
- ハッシュ長（32）
クライアントは、暗号的に安全なランダムソルトを生成し、それをPBKDF2関数で使用することが期待されています。結果として得られるPBKDF2ハッシュとソルトのbase64エンコーディングは、すべてのリクエストでX-Authorizationヘッダーに追加されます。
例えばX認証：882fac38qkf98ff1ed29W4bd2f95P214 = ＆＆ = 2c55a195
すべてのリクエストはhttps：//を介して行われます。レインボーテーブルの攻撃を防ぐため、リクエストごとに新しいソルトを生成する必要があるという印象を常に受けていました...しかし、これは本当に必要ですか？
誰かがTLSレイヤーを突破し、パスワードハッシュと使用されたソルトを確認できるとしましょう。彼らはこのパスワードを破ることに熱心であるため、この目に見えるソルトを使用してレインボーテーブルを作成します。 30バイトのパスワードを解読しようとしているのではないかと思いますが、解読した場合は、クライアントに送信したパスワードを使用できるようになります。
この時点で、パスワードを使用して、好きなリクエストを行うことができます。将来のリクエストで新しいソルトが使用されるかどうかは関係ありません。すでにパスワードを持っているので、それらをクラックするために別のレインボーテーブルを作成する必要はありません。
私が見落としている、または誤解しているものはありますか？新しいソルトを生成し、すべてのリクエストでPKDF2関数を実行することには利点がありますか？
ソルトを使用するポイントは、一度に複数のパスワードに対するブルートフォース攻撃を防ぐことです。それらがすべて異なるソルトを持っている場合、ディクショナリまたはレインボーテーブルは1つの特定のソルトに対してのみ有効です。
したがって、実際には、同じパスワードに異なるソルトを使用することは役に立ちません。
注：誰かがTLS接続を切断できる場合、おそらくWebアプリよりも興味深いものを攻撃するでしょう。 ;）
正直なところ？必要はありません。余分な処理オーバーヘッドがあります。一意のソルトを作成すると、それをすべての通信に使用できます。それを破る唯一の方法は、攻撃者がソルトを取得し、ソルトを使用してパスワードを攻撃することです。複雑なパスワードを使用した場合、何も起こらない可能性はほとんどありません。