ハッシュとソルティングの必要性は理解していますが、ハッシュ全体が安全であるため、ソルトを同じ (潜在的に侵害された) データベースに保存する方法がわかりません。たとえば、私が勉強している本では、整数をランダムに生成し、RNGCryptoServiceProvider を使用して byte[] を作成することにより、ユーザーごとに一意のハッシュを作成するように指示されています (良い)。これで問題ありませんが、ログイン時にユーザーのパスワードを検証するには、データベース (または他のファイル) から一意のソルトを読み取る必要があります。これは塩を保存する安全な方法ですか?
5 に答える
ソルトにアクセスしても、ハッシュのプロセスが攻撃者にとって逆行しやすくならないため、これは安全です。パスワード、ソルト、ハッシュがあれば、トリプルが正しいかどうかをすばやく確認できます。ただし、salt の知識を使用してパスワードを取得することはできません。
そもそもソルトが必要な理由は、同じパスワードが同じハッシュを生成しないようにするためであることを思い出してください。ソルトがなければ、攻撃者は「レインボー テーブル」をハッシュし、エンコードされた辞書に対してハッシュをチェックできます。
ソルティングは、侵害されたデータベースに対してオフライン攻撃を実行することを困難にします。十分なリソースを持つ攻撃者は最終的にすべてのパスワードをクラックしますが、ソルティングは次の 2 つの方法でそれを困難にします。
- 一般的なパスワードに基づいて事前に計算されたハッシュのリスト (レインボー テーブルと呼ばれる) は、ソルト化されたパスワードには適用できません (少なくとも、すべてのソルトを考慮に入れる必要はありません)。
- ソルト化された 1 つのパスワードを解読しても、他のパスワードに関する情報は得られません (2 つのパスワードが同一かどうかなど)。
難易度が上がると、侵害されたデータベースの影響を発見して軽減するための時間が増えます。
ハッシュとソルトを分離することで、セキュリティをわずかに向上させることができます。ただし、実際には、この分離を達成することは困難で面倒であり、攻撃者がそのレベルのアクセス権を持っている場合、パスワードと一緒にソルトを取得できる可能性が非常に高くなります。
ソルティングは、事前に作成されたテーブルでハッシュを検索することにより、ハッシュのクラッキングを防ぎます。攻撃者がソルトを知っている場合、パスワードを総当たり攻撃する必要があるため、この攻撃ベクトルでは役に立ちません。
ユーザーごとに異なるソルトを持つということは、すべてのリソースを消費して、1 人のユーザーだけに一致するハッシュをブルート フォースする必要があることを意味します。したがって、必ずしも「安全」というわけではありませんが、データベース全体をクラックすることは非常に困難 (不可能?) です。
レコードごとのソルトとグローバル ソルトを組み合わせて、データベースが危険にさらされたとしても、実行可能なブルート フォースにはまだ 1 要素足りないようにすることができます。
私は両方とも行くと思います - 結局、傷つけることはできません...