ハッシュでは、塩がどれほどランダムかは重要ですか？
最近、オンラインディスカッションでコメントがありました。ソルトのランダム性は問題ではないと述べたので、次の応答が返されました。
塩は「安全」である必要はないかもしれませんが、生成方法は重要です。暗号化ランダムデータソースを使用すると、ソルトデータの一意性とランダム性を確保できます。使用されているアルゴリズムによっては、ソルトのランダム性の分布がキーの強度に影響を与える可能性があります。
現在、ほとんどの場合、22文字のソルト（bcryptなど）を使用しても、同じソルトを2回生成する可能性はかなり小さいですが、そのステートメントの2番目のビットです-それが何を意味するのかはわかりません確かにそれを理解しないとその「間違った」とは言えない……。
これは正しいですか？塩のランダム性は重要ですか？誰かがハッシュのテーブルを攻撃している場合、塩は既知のものであるため、塩の品質はどのように重要になりますか？
いいえ。ソルトは単に一意であると想定されているため、パスワードハッシュを1回計算し、その結果を複数のパスワードハッシュに対して使用する攻撃（レインボーテーブルなど）を使用できません。
秘密の知識がなければハッシュを元に戻せないようにする場合は、ハッシュの前に、提供されたパスワード（saltに加えて）にサイト固有のパスワードを追加します。ソルトはハッシュで保存されますwithので、推測しにくくしても意味がありません。
@ Honoki：
それがグローバルな値またはサイト固有のものである場合、あなたが考えているのは塩ではなく、それは何か別のものです。それは良い考えではないというわけではありませんが、塩ではありません。通常、インストール固有のシークレットは「サイトキー」または「サイトパスワード」と呼ばれます。
ただし、ソルトは通常ハッシュとともに保存されます。たとえば、Unix/Linuxログインパスワードが保存される現在の方法は次のとおりです。ここでのパスワードは「foobar」です。
$5$BcjmguyyH.Qrf$ADRXhi/5xb.dYU67I.JdY57uoFjel/rqMqj14QJmTQ1
$はフィールド区切り文字です5はハッシュアルゴリズム指定子（この場合はSHA-256）ですBcjmguyyH.Qrfはソルトです（決して偽装されていません）ADRXhi/5xb.dYU67I.JdY57uoFjel/rqMqj14QJmTQ1はハッシュです
ソルトのポイントは、攻撃者がハッシュを事前に計算するのを防ぐことであると考えると、それは重要なソルトの一意性がほとんどだと思いますが、ランダム性は、特にリソースの豊富な攻撃者の要因である可能性があります-あなたのソルトが非常に予測可能であれば、それは攻撃者は侵入試行の前にRainbowテーブルを生成して、ハッシュを取得した後のパスワードの解読を高速化できると考えられます。
一部の手法は、無塩パスワードより少し優れています-パスワードデータベース全体に単一のソルトを使用すると、データベース全体をクラックするためにハッシュのセットを1つ計算するだけでよく、ユーザー名（または実際のユーザー名）から予測できるソルトを使用できます。攻撃者は、データベースのコピーを取得する前であっても、クラックの対象となるユーザーアカウント（おそらく管理者アカウント、特権を持つ従業員、モデレーターアカウントなど）のハッシュを事前計算できることを意味します。
要約すると、塩は一意である必要があり、最高のセキュリティを得るためには予測不可能である必要があります。ランダム性の暗号化標準は、おそらく予測不可能性を保証する良い方法ですが、おそらく必要ではありません。
塩は一意である必要はありません。これは絶対的な要件ではありません。ただし、使用するソルトの数が多ければ多いほど、セキュリティは向上します。そのため、それらがほぼ一意である場合は問題ありませんが、ランダム化が不十分なためにソルトを共有する可能性がある人については心配しないでください。
Saltは、事前に準備されたRainbowテーブルを使用してパスワードを解読するのを防ぐために使用されます。すべてのパスワードに同じソルトを使用している場合、準備済みのレインボーテーブルは無効になっていますが、ソルトされたパスワード用のカスタムレインボーテーブルを作成するクラッカーの時間は価値があるかもしれません。一部のユーザーのソルトを変更すると、レインボーテーブルを作成するクラッカーの潜在的な利益が減少します。たとえば、ランダムに使用される2つのソルトがある場合、クラッカーは2つのレインボーテーブルを作成する必要があります。 50個のソルトをランダムに使用する場合、クラッカーは50個のレインボーテーブルを作成する必要があります。ユーザーごとにランダムに生成されたソルトを使用する場合、クラッカーはユーザーごとに新しいRainbowテーブルを再作成する必要があります。これは非常に多くの作業であり、クラッカーはわざわざ試みず、代わりに別の攻撃を使用します。
ユーザーごとにランダムに生成されたソルトがある場合、2人以上のユーザーのソルトが同一になる可能性があります。これは、サイトのセキュリティにわずかに影響するだけです。クラッカーは、カスタムのレインボーテーブルを使用して、同じソルトパスワードをすべてクラックできるようになりました。同じソルトを持つユーザーの数が十分に多い場合、これは実行可能な攻撃となる可能性があります。同一の塩の数が単一の数値にある場合、それは大きな問題にはなりません。
塩の価値は秘密である必要はありません。ソルト値の非表示は一部の人によって行われますが、主流のパスワードシステムでは通常行われません。塩の秘密を守っても、セキュリティはそれほど向上しません。ソルトの目的は、各ユーザーのパスワードアルゴリズムが類似していないことを確認し、レインボーテーブル攻撃をブロックすることです。塩が一般的にほぼ一意である限り、塩を知っていてもハッシュを解読するのは簡単ではありません。
ほとんどのパスワードハッシュ方式では、ソルトはグローバルに一意である必要があります。つまり、理想的には、全世界のすべてのパスワードインスタンスに独自のソルト値を設定し、他のパスワードと共有しないようにする必要があります（特に、2つの異なるサーバーで同じソルト値を使用しないでください。また、ソルトも変更する必要がある場合）ユーザーが自分のパスワードを変更した場合）。
割り当てられたソルトの中央リポジトリがないため、グローバルな世界的な一意性は困難です。簡単な方法は、randomnessに依存することです：暗号的に強力なランダムジェネレーター（つまり、「非常に良い」ジェネレーター）からソルトを生成した場合、そして塩を十分に長くすると、塩の衝突の可能性は非常に低くなります-無視できるほど十分に低くなります。グローバルな一意性を目指しても、偶発的な衝突はすぐには致命的ではないので、そのリスクに耐えられることに注意してください。 16バイトは「十分な長さ」です。
グローバルな一意性を確実に保証する方法はどれも優れています。しかし、ランダム性は、純粋にローカルであるため（ネットワーク全体のボトルネックがないため）、多くの場合、最適にスケーリングされます。
Mutatis mutandi、これは [〜＃〜] uuid [〜＃〜] の場合と同じ問題です。 「バージョン4」のUUIDは、実際にはランダムな122ビットです。そのようなUUIDは非常に適切な塩です。