パスワードはなぜソルトを足すのか

パスワードをそのまま(平文で)保存するのは論外です。ではハッシュ化して保存すれば安全か――というと、それだけでは足りません。攻撃者は「よくあるパスワード」を片っ端からハッシュ化した早見表(レインボーテーブル)を持っていて、漏れたハッシュを逆引きできるからです。

そこで効くのがソルト。ユーザーごとに違うランダムな文字列をパスワードに混ぜてからハッシュします。下の図1で、ソルトをON/OFFして、レインボーテーブルでの逆引きが成功するか失敗するかを確かめてください（ハッシュはあなたのブラウザが計算する本物のSHA-256です）。

ソルトは「早見表」を無力化する

無塩(ソルトなし)のハッシュには、2つの弱点があります。1つ目は同じパスワードが必ず同じハッシュになること。だから1つ逆引きできれば、同じパスワードを使う全員が芋づる式にバレます。2つ目は事前計算が効くこと。攻撃者はよく使われるパスワードを前もってハッシュ化した巨大な表を用意でき、漏れたハッシュを照合するだけで一致を見つけられます。図1で「ソルトなし」のまま password123 を入れると、表の中に同じハッシュが見つかって逆引きが成功してしまいます。

ソルトを足すと、保存されるのは SHA-256(salt + password) になります。ソルトはユーザーごとに違うので、たとえ2人が同じ password123 を使っても、保存されるハッシュはまったくの別物。攻撃者の早見表は「無塩のハッシュ」しか載っていないので一切一致しません。図1の「別ユーザー」ボタンでソルトを変えると、同じパスワードなのにハッシュが丸ごと変わるのが見えます。ソルトは秘密にする必要はなく、ハッシュと一緒に保存して構いません――目的は事前計算と使い回しの検出を防ぐことだからです。

もう一段の守りがストレッチングです。ハッシュを何万回も繰り返しかけて、1回の計算をわざと重くします。正規ログインは1回だけなので体感ゼロですが、総当たり攻撃は1個試すたびに同じコストがかかり、現実的な時間で破れなくなります。bcrypt や Argon2 は、このソルトとストレッチングを最初から組み込んだ、パスワード保管の定番です。

まとめ

パスワードは平文で持たず、ハッシュで保存する。ただしハッシュだけでは早見表で逆引きされるので、ユーザーごとのソルトで同一性と事前計算を断ち切り、ストレッチングで総当たりを遅くする――この3点セットが基本です。実装では自前のSHAをこねるのではなく、bcrypt や Argon2 を使えば、これらがまとめて手に入ります。図1でソルトをON/OFFして、逆引きの成否がひっくり返る瞬間を確かめてください。