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