ソルトとは

この記事は約 2 分で読めます

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

ソルトの仕組みと数値例

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

現場での使用例

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

なぜソルトが必要か

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

実務での落とし穴

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