[解決済み】レインボーテーブル攻撃に対してパスワードソルトはどのように役立つのでしょうか？

質問

パスワードにソルトを付加する目的がよくわからず困っています。 主な用途は、レインボーテーブル攻撃を阻止することだと理解しています。 しかし、これを実装するために私が見た方法は、本当に問題を難しくしていないようです。

多くのチュートリアルで、ソルトを次のように使うことを提案しているのを見かけました。

$hash =  md5($salt.$password)

その理由は、ハッシュが元のパスワードではなく、パスワードとソルトの組み合わせにマッピングされるからです。 しかし、例えば $salt=foo と $password=bar と $hash=3858f62230ac3c915f300c664312c63f . さて、レインボーテーブルを持つ誰かがハッシュを逆引きして、"foobar"という入力を導き出すことができます。 そして、すべてのパスワードの組み合わせを試すことができます（f, fo, foo, ... oobar, obar, bar, ar, ar）。 パスワードを得るのにあと数ミリ秒かかるかもしれませんが、それほどのことではありません。

私が見た他の使い方は、私のLinuxシステムでのものです。 etc/shadowにハッシュ化されたパスワードが実際に保存されています。 で ソルトのことです。 例えば、ソルトを "foo" 、パスワードを "bar" とすると、以下のようにハッシュ化されます。 $1$foo$te5SBM.7C25fFDu6bIRbX1 . もしハッカーが何らかの方法でこのファイルを手に入れることができたとしたら、ソルトの逆ハッシュである te5SBM.7C25fFDu6bIRbX には "foo" が含まれていることが知られています。

どなたか教えてくださる方、ありがとうございます。

EDIT : お世話になります。 私が理解していることを要約すると、ソルトはハッシュ化されたパスワードをより複雑にするため、事前に計算されたレインボーテーブルに存在する可能性が非常に低くなるということです。 私が以前誤解していたのは、レインボーテーブルがすべてのハッシュに対して存在すると仮定していたことです。

解決方法は？

パブリックソルトは ない 一つのパスワードを解読する際に、辞書攻撃を難しくしています。ご指摘の通り、攻撃者はハッシュ化されたパスワードとソルトの両方にアクセスできるため、辞書攻撃を行う際、パスワードを解読しようとすれば、単に既知のソルトを使用することができます。

パブリックソルトを使うと、大量のパスワードのリストを解読するのに時間がかかるようになり、レインボーテーブルを使うことが不可能になるという2つの効果があります。

1つ目の例を説明すると、数百のユーザー名とパスワードが入った1つのパスワードファイルを想像してください。ソルトがなければ、私は "md5(attempt[0])" を計算し、そのハッシュがどこかに表示されるかどうか、ファイルを通してスキャンすることができます。ソルトがある場合、私は "md5(salt[a] . attempt[0])" を計算し、エントリ A と比較し、次に "md5(salt[b] . attempt[0])" 、エントリ B と比較するなどしなければならないのです。今、私は n 倍の作業が必要で、ここで n は、そのファイルに含まれるユーザー名とパスワードの数です。

2つ目を理解するためには、レインボーテーブルとは何かを理解する必要があります。レインボーテーブルとは、よく使われるパスワードの事前計算されたハッシュの大きなリストである。もう一度、ソルトのないパスワードファイルを想像してみてください。ファイルの各行を調べて、ハッシュ化されたパスワードを取り出し、レインボーテーブルで調べるだけでよいのです。ハッシュを一度も計算する必要はないのです。もしルックアップがハッシュ関数よりかなり高速なら（おそらくそうだろう）、ファイルのクラックはかなり高速になるはずだ。

しかし、パスワードファイルが塩漬けされている場合、レインボーテーブルには "salt .password" があらかじめハッシュ化されている必要があります。ソルトが十分にランダムであれば、これは非常に起こりにくいことです。おそらく、"hello" や "foobar" や "qwerty" のようなものを持つことになると思います。しかし、"jX95psDZhello" や "LPgB0sdgxfoobar" や "dZVUABJtqwerty" などは事前に計算されないようにするつもりです。そうすると、虹のテーブルが法外に大きくなってしまいます。

つまり、ソルトを使えば、攻撃者は1回の試行につき1回の計算で済むことになり、十分に長く、十分にランダムなパスワードと組み合わせれば、（一般的には）解読不可能になります。