「ソルト化ハッシュ」は、各人のパスワードなどにランダムな文字列を付与してから、ハッシュ値へと変換したものです。
この「それぞれの元データに付与したランダムな文字列」が「ソルト（salt：塩）」です。
1. 通常のハッシュ化とレインボーテーブル攻撃
パスワードなど機密データは、通常 ハッシュ値に変換して記録されます。
| ユーザー | 元データ | MD5 ハッシュ値 |
|---|---|---|
| A | password01 | af88a0ae641589b908fa8b31f0fcf6e1 |
| B | password02 | 51d25b4ae8ce20ad29b25cf4f2e23203 |
| C | password01 | af88a0ae641589b908fa8b31f0fcf6e1 |
ハッシュ変換の計算方法（アルゴリズム）は数多く考案されています。
元の文字列データをいろいろ変換して別の文字列に変える点は共通しています。
元データが違うのに変換後に同じ値になってしまうことがないように工夫されています。
入力されたパスワードからハッシュ値を計算して照合ことは簡単ですが、元データを計算することは困難です。暗号化と違ってサーバ管理者も復号するキーは持っていないことは、最重要のパスワードを管理する仕組みとして好都合です。
ハッシュ変換は、一方通行なのです。
しかし、単にパスワードをハッシュ変換するだけでは、同じパスワードのユーザーのハッシュは同じ値になってしまいます。
データベースの中で多く見られるハッシュ値から規則性が見えてしまいます。
さらに、同じハッシュ化アルゴリズムを使えば、大量の元データとハッシュ値の対応表をあらかじめ用意することができます。
その表に同じハッシュ値を見つけることができれば、力技で元データを割り出すことができてしまいます。
これを「レインボーテーブル攻撃」といいます。
レインボーテーブルは「あるハッシュ値に対して総当たり攻撃を行った際の計算結果を、別のハッシュ値を攻撃する際に使用する」というアイデアに端を発する。
レインボーテーブル – Wikipedia
つまり、ハッシュ化アルゴリズムが特定され、大きなデータベースがあると、暗号化して記録したはずのパスワードも解読されてしまうのです。
例えば、ハッシュ化されたパスワードが盗まれた事件で、約61万件のうち「単純なパスワード」が使用されていた約29万件がすぐに解読されてしまったことがあります。
投稿者は窃取したデータの件数は80万1915件で、メールアドレスが約60万9千件、MD5でハッシュ化されたパスワード約60万7千件、電話番号が約65万件、配送先住所や電話番号、氏名が約20万件、銀行口座情報約1千件、およびTwitterIDやTokenが含まれると主張。
2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた。
パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。
不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた – piyolog
ここでの「単純なパスワード」というのは、攻撃者の持つレインボーテーブルに含まれていた、ということになります。
複雑なパスワードにしておいた方がよいのは、このためなんだね。
2. ソルトによってハッシュ値を複雑化する
ユーザー側がパスワードを複雑にするという自衛措置だけでなく、サーバ管理者側でもハッシュ値を複雑化する工夫があります。
それが「ソルト」です。
サーバ側が一人ひとりにランダムな文字列を用意して、それをパスワードにつないでからハッシュ値を記録します。
このランダムな文字列を「ソルト」と言います。
| ユーザー | 元データ | ソルト | ソルト化ハッシュ |
|---|---|---|---|
| A | password01 | E1F5 | 912d043e6eb95c452418239068fc2bd8 |
| C | password01 | 3A12 | 74ab0f9fbbfe8f91a857b62fca55ffd2 |
ユーザーがパスワードを入力したら、ソルトとソルト化ハッシュを使えば正しい入力か照合することができます。
そこで、認証のためには各ユーザーに対応したソルトもデータベースで管理しておく必要があります1。
ソルトを付け足すことでハッシュ変換前の元データは、かなり複雑になります。
ソルトの文字数は必要に応じて十分に長く取ることができます。
また、同じパスワードでも、それぞれソルトが異なるので違うハッシュ値が記録されます。
ソルト化ハッシュだと、たとえデータベースのハッシュ値が流出したとしても、レインボーテーブル攻撃でもとのパスワードを推定することが困難です。
元データとソルトを足した文字数の組み合わせに対応するレインボーテーブルを用意するには、天文学的に膨大なデータサイズが必要になるからです。
2-1. ソルト自体は知られても危険が少ない
ちなみに、ソルトのリストも攻撃者に知られたとしても そこまで問題ありません。
パスワード解読には、まず、ソルト化ハッシュから「元データ+ソルト」を求める必要があります。
結局、ソルトだけがわかっていても、ソルト化ハッシュから元データを割り出すには巨大なレインボーテーブルや総当たり攻撃が必要なことは変わらないからです。
3. ハッシュ変換のアルゴリズム
さらに、ハッシュ変換のアルゴリズムの選択もパスワードの解析時間に影響します。
「暗号的ハッシュ関数」は、たくさん考案されています。
それぞれで複雑さや処理速度が異なるからです。
実はパスワード用のハッシュ変換では、むしろ低速のアルゴリズムの方が好都合です2。
（補足）
- 主要なライブラリやフレームワークでMCF形式が使われており、アプリケーションはパスワード情報をMCF形式のままデータベースに保存する方式が一般的です。 – ソルト付きハッシュのソルトはどこに保存するのが一般的か – Qiita
- パスワードの保存には、MD5やSHA-2のような一般的で高速なハッシュ関数ではなく、bcrypt、scrypt、Argon2などパスワード保護用に開発された「低速の」アルゴリズムが望ましいとされます。 – ソルト付きハッシュのソルトはどこに保存するのが一般的か – Qiita
