パスワードハッシュのランダムでないソルト
更新：私は最近この質問から、以下の全体の議論で私（そして他の人もそうだったと確信しています）は少し混乱していることを学びました：私がレインボーテーブルと呼んでいるものは実際にはハッシュテーブルと呼ばれます。レインボーテーブルは、より複雑な生き物であり、実際にはヘルマンハッシュチェーンのバリアントです。解答は同じであると私は信じていますが（解読には至らないため）、一部の議論は少し歪んでいる可能性があります。 質問：「レインボーテーブルとは何ですか。どのように使用されますか？」 通常、Rainbow Tableの攻撃から保護するなど、ハッシュ関数（パスワードなど）と共に使用するために、暗号として強力なランダム値をソルトとして使用することを常にお勧めします。 しかし、実際にはソルトがランダムであることは暗号的に必要ですか？これに関して、一意の値（userIdなどのユーザーごとに一意）で十分でしょうか？実際には、単一のRainbow Tableを使用してシステムのすべて（またはほとんど）のパスワードをクラックする ことはできません... しかし、エントロピーの欠如は、ハッシュ関数の暗号強度を本当に弱めるのでしょうか？ ソルトを使用する理由、それを保護する方法（保護する必要はない）、単一の定数ハッシュを使用する（しない）、または使用するハッシュ関数の種類については尋ねていません。 塩がエントロピーを必要とするかどうかだけです。 これまでの回答に感謝しますが、私が（少し）あまり慣れていない領域に焦点を当てたいと思います。主に暗号解読への影響-誰かが暗号数学PoVから何らかの入力を持っている場合、私は最も感謝します。 また、考慮されていなかった追加のベクトルがある場合、それも素晴らしい入力です（複数のシステムでの@Dave Sherohmanポイントを参照）。 それ以上に、理論、アイデア、またはベストプラクティスがある場合は、証明、攻撃シナリオ、または経験的証拠のいずれかでこれをバックアップしてください。または、許容できるトレードオフについての有効な考慮事項...私はこのテーマのベストプラクティス（大文字のBの大文字P）に精通しています。これが実際に提供する価値を証明したいと思います。 編集：ここでいくつかの本当に良い答えがありますが、@ Daveが言うように、それは一般的なユーザー名のレインボーテーブルに帰着します...そしてあまり一般的ではない名前も考えられます。ただし、ユーザー名がグローバルに一意である場合はどうなりますか？必ずしも私のシステムで一意である必要はありませんが、ユーザーごとに-たとえば、電子メールアドレス。 （@Daveが強調しているように、saltは秘密にされていないため）シングルユーザー用のRTを作成するインセンティブはなく、これはクラスタリングを妨げます。唯一の問題は、別のサイトで同じメールアドレスとパスワードを使用している可能性があることです。 それで、それは暗号解読に帰着します-エントロピーは必要ですか、それとも不要ですか？（私の現在の考えでは、暗号解読の観点からは必要ではありませんが、他の実際的な理由からです。）