レインボーテーブル攻撃とは？ 10分でわかりやすく解説

UnsplashのSincerely Mediaが撮影した写真      

レインボーテーブル攻撃は、ハッシュ化されたパスワードを逆算・推定するために、あらかじめ作られた「対応表（レインボーテーブル）」を利用する手口です。ハッシュ化しているから安全、という思い込みがあると危険で、設定次第では短時間で解読される可能性があります。この記事では、仕組み、成立条件、実務的な対策を整理します。

レインボーテーブル攻撃とは

レインボーテーブル攻撃は、パスワードそのものではなくパスワードのハッシュ値が漏えいした場合に、そのハッシュ値から元の文字列を推定する手法の一つです。ハッシュ関数は「一方向」であるため理論上は逆算できませんが、攻撃者は大量の候補を事前計算し、照合を高速化します。

ハッシュ化しても危険なケース

• ソルト（salt）が使われていない、または弱い
• 高速すぎるハッシュ（用途に不向き）をパスワード保存に使っている
• 短く単純なパスワードが多い（推測候補が当たりやすい）

レインボーテーブル攻撃への対策

ソルト付きハッシュを徹底する

ソルトを各ユーザーごとに付与してハッシュ化することで、レインボーテーブルの「使い回し」を困難にします。ソルトがないと、同じパスワードは同じハッシュ値になり、攻撃が成立しやすくなります。

パスワード保存に適した方式を使う

パスワード保存では、総当たりへの耐性を上げるために「計算コストを上げる」設計が求められます。高速に計算できる方式をそのまま使うと、試行回数が稼がれやすくなります。

長く強いパスワードと、使い回し防止

• 長さを優先し、推測されやすい単語・規則性を避ける
• 使い回しをしない（漏えい時の連鎖被害を防ぐ）
• パスワードマネージャーの活用を検討する

多要素認証（MFA）を併用する

万一パスワードが推定されても、MFAがあると不正ログインを成立させにくくできます。パスワードだけに依存しない設計が重要です。

レインボーテーブル攻撃の事例と影響

漏えいした「ハッシュ」からの二次被害

パスワードがハッシュで保存されていたとしても、方式や運用が不十分だと推定され、他サービスへの使い回しで被害が拡大します。被害は「当該サービスだけ」で終わらない点が重要です。

組織の信用・対応コスト

漏えい対応では、パスワードリセット、問い合わせ対応、原因調査、再発防止策の実装など、業務負荷が大きくなります。保存方式の設計は、インシデント対応コストを左右します。

まとめ

レインボーテーブル攻撃は、ハッシュ値から元のパスワードを推定するために、事前計算された対応表を利用する手口です。対策の要点は、ソルト付きハッシュの徹底、パスワード保存に適した方式の採用、長いパスワード・使い回し防止、MFAの併用です。「ハッシュ化しているから安全」とは限らないため、設計と運用をセットで見直すことが重要です。

よくある質問（FAQ）

Q. レインボーテーブル攻撃は何を狙う攻撃ですか？

漏えいしたハッシュ値から、元のパスワードを推定することを狙います。

Q. ハッシュ化していれば安全ではないのですか？

方式や設定次第です。ソルトがない、弱い方式だと推定される可能性があります。

Q. ソルト（salt）とは何ですか？

各ユーザーごとに付与するランダム値で、同じパスワードでもハッシュ値が同一にならないようにします。

Q. ソルトがあるとレインボーテーブルは無力化しますか？

使い回しが効きにくくなり、攻撃コストを大きく上げられます。

Q. なぜ「高速なハッシュ」は危険になり得ますか？

試行回数を稼がれやすく、総当たりの速度が上がるためです。

Q. パスワードの長さはどれくらいがよいですか？

短いほど推定されやすいので、長さを優先し、推測されやすい単語は避けます。

Q. 使い回しが危険なのはなぜ？

一つが推定・漏えいすると、他サービスにも連鎖して不正ログインが起こり得るためです。

Q. MFAはレインボーテーブル攻撃に有効ですか？

有効です。パスワードが推定されても、追加要素がないとログインを成立させにくくできます。

Q. ハッシュが漏えいした場合、まず何をすべきですか？

速やかなパスワードリセットと、使い回しの注意喚起、必要に応じたMFA強制が重要です。

Q. 対策の優先順位は？

保存方式（ソルト＋適切な方式）の是正、MFA、強いパスワード運用の順で整備すると効果が出ます。