パスワードハッシュのランダムでないソルト

更新：私は最近この質問から、以下の全体の議論で私（そして他の人もそうだったと確信しています）は少し混乱していることを学びました：私がレインボーテーブルと呼んでいるものは実際にはハッシュテーブルと呼ばれます。レインボーテーブルは、より複雑な生き物であり、実際にはヘルマンハッシュチェーンのバリアントです。解答は同じであると私は信じていますが（解読には至らないため）、一部の議論は少し歪んでいる可能性があります。
質問：「レインボーテーブルとは何ですか。どのように使用されますか？」

通常、Rainbow Tableの攻撃から保護するなど、ハッシュ関数（パスワードなど）と共に使用するために、暗号として強力なランダム値をソルトとして使用することを常にお勧めします。

しかし、実際にはソルトがランダムであることは暗号的に必要ですか？これに関して、一意の値（userIdなどのユーザーごとに一意）で十分でしょうか？実際には、単一のRainbow Tableを使用してシステムのすべて（またはほとんど）のパスワードをクラックする
ことはできません... しかし、エントロピーの欠如は、ハッシュ関数の暗号強度を本当に弱めるのでしょうか？

ソルトを使用する理由、それを保護する方法（保護する必要はない）、単一の定数ハッシュを使用する（しない）、または使用するハッシュ関数の種類については尋ねていません。
塩がエントロピーを必要とするかどうかだけです。

これまでの回答に感謝しますが、私が（少し）あまり慣れていない領域に焦点を当てたいと思います。主に暗号解読への影響-誰かが暗号数学PoVから何らかの入力を持っている場合、私は最も感謝します。
また、考慮されていなかった追加のベクトルがある場合、それも素晴らしい入力です（複数のシステムでの@Dave Sherohmanポイントを参照）。
それ以上に、理論、アイデア、またはベストプラクティスがある場合は、証明、攻撃シナリオ、または経験的証拠のいずれかでこれをバックアップしてください。または、許容できるトレードオフについての有効な考慮事項...私はこのテーマのベストプラクティス（大文字のBの大文字P）に精通しています。これが実際に提供する価値を証明したいと思います。

編集：ここでいくつかの本当に良い答えがありますが、@ Daveが言うように、それは一般的なユーザー名のレインボーテーブルに帰着します...そしてあまり一般的ではない名前も考えられます。ただし、ユーザー名がグローバルに一意である場合はどうなりますか？必ずしも私のシステムで一意である必要はありませんが、ユーザーごとに-たとえば、電子メールアドレス。
（@Daveが強調しているように、saltは秘密にされていないため）シングルユーザー用のRTを作成するインセンティブはなく、これはクラスタリングを妨げます。唯一の問題は、別のサイトで同じメールアドレスとパスワードを使用している可能性があることです。
それで、それは暗号解読に帰着します-エントロピーは必要ですか、それとも不要ですか？（私の現在の考えでは、暗号解読の観点からは必要ではありませんが、他の実際的な理由からです。）

Saltは伝統的にハッシュされたパスワードのプレフィックスとして保存されます。これにより、パスワードハッシュへのアクセス権を持つすべての攻撃者にそのことが知らされます。ユーザー名をsaltとして使用してもしなくても、その知識には影響しません。そのため、単一システムのセキュリティには影響しません。

ただし、ユーザー名またはその他のユーザー制御値をソルトとして使用すると、システム間セキュリティが低下します。同じパスワードハッシュアルゴリズムを使用する複数のシステムで同じユーザー名とパスワードを使用したユーザーは、同じパスワードハッシュをオンにするためです。それらのシステムのそれぞれ。私は攻撃者として、アカウントを侵害する他の手段を試みる前に、ターゲットアカウントが他のシステムで使用したことがわかっているパスワードを最初に試すので、これは重大な責任とは見なしません。同一のハッシュは、既知のパスワードが機能することを前もって教えてくれるだけであり、実際の攻撃を簡単にすることはありません。（ただし、アカウントデータベースをすばやく比較すると、誰がパスワードを再利用しているか、誰がパスワードを再利用していないかがわかるため、優先度の高いターゲットのリストが提供されます。）

このアイデアからのより大きな危険は、ユーザー名が一般的に再利用されることです-あなたが訪問したいサイトのほとんどが、たとえば「Dave」という名前のユーザーアカウントを持ち、「admin」または「root」がさらに一般的です-これにより、これらの一般的な名前を持つユーザーをターゲットとするレインボーテーブルの作成は、はるかに簡単で効果的です。

これらの欠陥は両方とも、ハッシュする前にパスワードに2番目のソルト値（標準ソルトのように固定または非表示または公開）を追加することで効果的に対処できますが、その時点では、代わりに標準エントロピーソルトを使用することもできます。ユーザー名をそこに組み込む方法。

追加のために編集： 多くの人々がエントロピーについて、そして塩のエントロピーが重要であるかどうかについて話しています。それはそうですが、それに関するほとんどのコメントが考えるように思われる理由ではありません。

一般的な考えでは、攻撃者が塩を推測するのは難しいため、エントロピーは重要であるようです。これは誤りであり、実際には完全に無関係です。さまざまな人が数回指摘したように、saltの影響を受ける攻撃は、パスワードデータベースを持っている人だけが行うことができ、パスワードデータベースを持っている人は、各アカウントのsaltを確認するだけです。推測できるかどうかは、簡単に調べることができる場合は問題になりません。

エントロピーが重要である理由は、ソルト値のクラスタリングを回避するためです。ソルトがユーザー名に基づいており、ほとんどのシステムに「root」または「admin」という名前のアカウントがあることがわかっている場合、これら2つのソルトのレインボーテーブルを作成すると、ほとんどのシステムがクラックされます。一方、ランダムな16ビットソルトが使用され、ランダムな値がほぼ均等に分布している場合、2 ^ 16の可能なすべてのソルトにレインボーテーブルが必要です。

それは、攻撃者が個々のアカウントのソルトが何であるかを知るのを防ぐことではなく、潜在的なターゲットのかなりの部分で使用される単一のソルトの大きくて太いターゲットを与えないことです。

パスワードを安全に保存するには、エントロピーの高いソルトを使用することが絶対に必要です。

ユーザー名「gs」を取得してパスワードに追加すると、「MyPassword」はgsMyPasswordになります。ユーザー名に十分なエントロピーがない場合、特にユーザー名が短い場合は、この値がすでにレインボーテーブルに格納されている可能性があるため、レインボーテーブルを使用すると簡単に壊れます。

もう1つの問題は、ユーザーが2つ以上のサービスに参加していることがわかっている攻撃です。一般的なユーザー名はたくさんありますが、おそらく最も重要なものはadminとrootです。誰かが最も一般的なユーザー名のソルトを含むレインボーテーブルを作成した場合、彼はそれらを使用してアカウントを侵害する可能性があります。

以前は12ビットのソルトを使用していました。12ビットは4096種類の組み合わせです。今日では、多くの情報を簡単に保存できるため、安全性は十分ではありません。同じことが4096の最もよく使用されるユーザー名にも当てはまります。一部のユーザーは、最も一般的なユーザー名に属するユーザー名を選択する可能性があります。

あなたのパスワードのエントロピーを計算するこのパスワードチェッカーを見つけました。（ユーザー名を使用するなどして）パスワードのエントロピーを小さくすると、レインボーテーブルが発生する可能性が高くなるため、少なくともすべてのパスワードを低エントロピーでカバーしようとするため、レインボーテーブルがはるかに簡単になります。

ユーザーが異なるWebサイト間でユーザー名を共有する可能性があるため、ユーザー名だけでは問題が発生する可能性があるのは事実です。しかし、ユーザーが各Webサイトで異なる名前を持っている場合は、問題はありません。それでは、なぜそれを各Webサイトで一意にしないのか。このようなパスワードをハッシュする

ハッシュ関数（ "www.yourpage.com/"+username+"/"+password）

これで問題が解決するはずです。私は暗号解読の達人ではありませんが、高いエントロピーを使用しないという事実がハッシュを弱くすることには疑いがあります。

私は両方を使用するのが好きです：レコードごとの高エントロピーのランダムなソルトと、レコード自体の一意のID。

これにより、辞書攻撃などに対するセキュリティはそれほど向上しませんが、パスワードを自分のものに置き換えることを目的として、誰かがソルトとハッシュを別のレコードにコピーするというフリンジケースがなくなります。

（確かにこれが当てはまる状況を考えるのは難しいですが、セキュリティに関しては、ベルトやブレースに害はありません。）

塩が既知であるか簡単に推測できる場合、辞書攻撃の難易度は増加していません。「一定の」ソルトを考慮に入れる、変更されたレインボーテーブルを作成することも可能です。

独自のソルトを使用すると、BULK辞書攻撃の難易度が上がります。

独自の暗号学的に強力なソルトバリューを持つことが理想的です。

各パスワードでソルトが異なる限り、おそらく大丈夫でしょう。ソルトのポイントは、標準のレインボーテーブルを使用してデータベース内のすべてのパスワードを解決できないことです。したがって、すべてのパスワードに異なるソルトを適用する場合（ランダムでなくても）、各パスワードは異なるソルトを使用するため、攻撃者は基本的に各パスワードに対して新しいレインボーテーブルを計算する必要があります。

この場合の攻撃者はすでにデータベースを持っていると想定されるため、よりエントロピーのあるソルトを使用しても、それほど効果はありません。ハッシュを再作成できる必要があるため、ソルトが何であるかをすでに知っている必要があります。したがって、ソルト、またはソルトを構成する値をファイルに保存する必要があります。Linuxのようなシステムでは、ソルトを取得する方法がわかっているため、秘密のソルトを使用しても意味がありません。あなたのハッシュ値を持っている攻撃者がおそらくあなたのソルト値も知っていると想定する必要があります。

ハッシュ関数の強度は、その入力によって決定されません！

攻撃者に知られているソルトを使用すると、レインボーテーブル（特に、rootのようなハードコードされたユーザー名の場合）の作成が明らかに魅力的になりますが、ハッシュが弱まることはありません。攻撃者にとって未知のソルトを使用すると、システムが攻撃されにくくなります。

ユーザー名とパスワードを連結しても、インテリジェントなレインボーテーブルのエントリが提供される可能性があるため、ハッシュされたパスワードとともに保存された一連の疑似ランダム文字のソルトを使用することをお勧めします。例として、ユーザー名「ポテト」とパスワード「ビール」を持っている場合、ハッシュの連結入力は「ポテトビール」であり、これはレインボーテーブルの妥当なエントリです。

ユーザーがパスワードを変更するたびにソルトを変更すると、大文字と小文字の混在、句読点、最小の長さ、n週間後の変更など、合理的なパスワードポリシーの施行と同様に、長期的な攻撃を防ぐのに役立つ場合があります。

ただし、ダイジェストアルゴリズムの選択はより重要です。たとえば、MD5よりもレインボーテーブルを生成する方がSHA-512を使用するほうが苦痛であることが証明されます。

与えられた入力値が複数回ハッシュされた場合に得られるハッシュ値は、可能な限り近く、常に異なることを保証するために、ソルトはできるだけ多くのエントロピーを持つ必要があります。

常に変化するソルト値をソルトで可能な限り多くのエントロピーで使用すると、ハッシュ（たとえば、パスワード+ソルト）の可能性が完全に異なるハッシュ値を生成することが保証されます。

ソルトのエントロピーが少ないほど、同じソルト値を生成する可能性が高くなるため、同じハッシュ値を生成する可能性が高くなります。

入力がわかっている場合はハッシュ値が「一定」であり、「定数」であるため、辞書攻撃やレインボーテーブルが非常に効果的です。結果のハッシュ値を可能な限り変化させることにより（高いエントロピーソルト値を使用して）、同じ入力+ランダム塩をハッシュすると、多くの異なるハッシュ値の結果が生成され、それによってレインボーテーブルが無効になります（または、少なくとも効果が大幅に低下します）。攻撃。

エントロピーはソルト値のポイントです。

saltの背後に単純で再現可能な「数学」がある場合、saltが存在しない場合と同じです。時間の値を追加するだけで十分です。