Password Salting - Why Hashing Alone Falls Shortとは

About 2 min read

ソルト (Salt) とは、パスワードをハッシュ化する際に 付加するランダムなデータです。同じパスワードでもソルトが異なれば異なるハッシュ値が 生成されるため、レインボーテーブル攻撃や事前計算攻撃を無効化できます。 ソルトはユーザーごとに一意に生成され、ハッシュ値とともに保存されます。

ソルトの仕組みと数値例

パスワードのハッシュ化時に、暗号学的に安全な乱数生成器でソルトを生成し、 パスワードと結合してからハッシュ関数に入力します。たとえば、パスワード 「mypassword」に 16 バイト (128 ビット) のソルトを付加すると、 同じパスワードでもユーザーごとに完全に異なるハッシュ値が生成されます。 ソルトの推奨長は 16 バイト以上で、bcrypt では 128 ビット、Argon2 では 128 ビット以上が標準です。2025 年時点の OWASP ガイドラインでは、 Argon2id と 16 バイト以上のソルトの組み合わせが推奨されています。ソルトは秘密にする必要はなく、ハッシュ値と一緒に データベースに保存されます。重要なのは、ユーザーごとに異なるソルトを使用することです。password hashing books on Amazonで詳しく解説されています。

現場での使用例

「セキュリティ監査で、レガシーシステムのパスワード保存にソルトが使われていないことが発覚しました。 Argon2id + 16 バイトソルトへの移行を最優先タスクとして対応中です。」

なぜソルトが必要か

ソルトがなければ、同じパスワードを使うユーザーは全員同じハッシュ値になります。 攻撃者はレインボーテーブルを使って一度に大量のパスワードを解読できてしまいます。 具体的な数値で考えると、ソルトなしの場合、攻撃者は 1 つのレインボーテーブル (数百 GB 程度) で全ユーザーのパスワードを攻撃できます。しかし 16 バイトの ソルトを使用すると、理論上 2 の 128 乗通りのテーブルが必要になり、 事前計算攻撃は事実上不可能になります。

実務での落とし穴

よくある誤りは、全ユーザーに同じソルトを使用することです。これでは レインボーテーブルの無効化効果が大幅に低下します。また、ソルトの長さが 短すぎる (4 バイト以下など) 場合も、攻撃者が全ソルトパターンに対応した テーブルを作成できてしまいます。もう 1 つの落とし穴は、ソルトを「秘密」として 別の場所に保管しようとすることです。ソルトの目的は秘匿ではなく一意性の確保であり、 ハッシュ値と同じデータベースに保存して問題ありません。 パスつく.com で生成したランダムなパスワードはそもそも推測が困難ですが、 サービス側のソルト実装と組み合わせることで、より堅牢な保護が実現します。authentication technology books (Amazon)も参考になります。