原像攻撃とは？ 10分でわかりやすく解説

UnsplashのallPhoto Bangkokが撮影した写真      

ハッシュ関数は、パスワード保管、改ざん検知、デジタル署名など、情報セキュリティの土台として広く使われています。ところが、ハッシュの使い方やアルゴリズム選定を誤ると、ハッシュ値から元データを探し出す「原像攻撃（Preimage Attack）」の影響を受け、認証突破や情報漏洩、改ざんの見逃しにつながる恐れがあります。この記事では、原像攻撃の意味と誤解されやすいポイントを整理した上で、実務で実装しやすい防御策（アルゴリズム選定・運用・移行）までを具体的に解説します。

原像攻撃とは何か

原像攻撃（Preimage Attack）とは、あるハッシュ値 h が与えられたときに、それを生成する入力 m（原像）を見つけようとする攻撃です。ハッシュ関数は本来「一方向（戻せない）」であることが前提ですが、出力長が短すぎる、古い設計、実装上の弱点、運用上の不備などが重なると、攻撃者が現実的なコストで入力を突き止められる場面が生まれます。

なお、現場では「ハッシュが割れる＝原像攻撃」と一括りにされがちですが、厳密には状況が分かれます。たとえば、パスワードハッシュの“解読”は、攻撃者が辞書・総当たりで候補を試し、ハッシュが一致する入力を探す（結果として原像が見つかる）という意味で、原像攻撃と近い挙動になります。一方で、デジタル署名や改ざん検知で問題になるのは、原像攻撃だけでなく、別の性質（後述）であることも多い点に注意が必要です。

原像攻撃の定義

原像攻撃は、与えられたハッシュ値に対応する入力（元のメッセージ）を見つけ出すことを目的とした攻撃です。一般に、理想的なハッシュ関数で出力が n ビットなら、原像を見つけるには概ね 2ⁿ 回規模の試行が必要とされ、十分な n（例：256ビット）が確保されていれば現実的に破られにくい、と考えられています。

ただし、ここでいう「元のメッセージ」は“唯一の正解”とは限りません。ハッシュは多対一なので、同じハッシュ値を返す入力は理論上複数存在し得ます。攻撃の成功条件は、システム側が受け入れてしまう入力を1つでも見つけることです（例：パスワード照合で一致する入力、APIトークン照合で一致する入力など）。

原像攻撃の仕組み

原像攻撃の基本的な進み方は次の通りです。

1. 攻撃者が目標となるハッシュ値（またはハッシュ値の照合結果が得られる仕組み）を入手する。
2. 攻撃者が候補入力を大量に生成し、ハッシュ値を計算して一致を探索する（総当たり・辞書・ルールベース・GPU等での高速化）。
3. 一致する入力（原像）が見つかれば、それを使って認証突破や不正操作などを試みる。

ここで重要なのは、「ハッシュ関数の数学的な弱点」がなくても、運用の弱さで成立してしまう点です。たとえば、入力（パスワード）が短い・単純で候補空間が狭い、ソルトがない、ストレッチング（遅延化）がない、といった状況では、攻撃者は“ハッシュ自体を破った”というより、入力の弱さを突いて一致を見つけます。

ハッシュ関数の脆弱性と誤解されやすい点

原像攻撃が現実的になる要因は、大きく分けて「アルゴリズム」「出力長」「運用」の3つです。ここで、原稿に混ざりやすい誤解も合わせて整理します。

• 出力長が短い／切り詰めている：出力が短いほど探索空間が小さくなり、原像探索が現実的になります（例：ハッシュの一部だけで照合している等）。
• 古い・非推奨アルゴリズムの利用：MD5やSHA-1は用途によっては安全性不足が指摘されており、現代の脅威モデルでは避けるのが基本です。
• 実装・運用の弱さ：ソルトなしのパスワードハッシュ、速すぎるハッシュ（SHA-256をそのままパスワード保管に使う等）、レート制限なしの照合APIなどが典型です。

一方で、次のような説明は誤解を招きやすいため注意が必要です。

• 「衝突耐性の欠如＝原像攻撃がしやすい」：衝突（Collision）と原像（Preimage）は別の性質です。衝突が見つかっても、直ちに原像が現実的になるとは限りません。
• 「計算効率の低さが脆弱性」：一般にハッシュ関数は速いほど攻撃者にも有利になります。脆弱性として問題になるのは“速すぎること”や“入力が弱いこと”であり、「遅いから危険」という方向ではありません（例外は実装DoSなど別論点です）。

原像攻撃と混同されやすい関連用語

ハッシュ攻撃は似た言葉が多いため、ここで整理します。防御策の選び間違いを防ぐためにも、最低限の区別は押さえておくと安全です。

「データ改ざん」と結びつける場合、多くのケースで論点は“第二原像”や“衝突”の方が直接的です。原像攻撃だけで改ざんが成立するのは、「ハッシュ値だけが正で、元データが検証されない」「照合に使う入力側を攻撃者が自由に選べる」など、運用が不適切な場合に限られます。

原像攻撃が狙われやすいシーン

原像攻撃は「ハッシュが使われているなら何でも危険」という話ではなく、“ハッシュの使い方”によってリスクが大きく変わります。現場で遭遇しやすい代表例を押さえておくと、対策の優先順位が付けやすくなります。

パスワードのハッシュ保管

もっとも典型的なのが、漏洩したパスワードハッシュに対する探索（辞書・総当たり）です。特に、ソルトなし、または速い一般ハッシュ（SHA-256等）をそのまま使っている場合、攻撃者はGPU等で高速に候補を試せます。逆に、Argon2・bcrypt・scryptのようなパスワード専用の遅い関数を使い、各ユーザーに一意なソルトを付けていれば、攻撃コストは大きく上がります。

APIキーやトークンの“ハッシュ化保存”

APIキーやセッション・リカバリ用トークンを平文で保存せず、ハッシュ化して保存する設計は一般的です。ただし、トークンが短い、生成規則が推測可能、照合APIにレート制限がない、といった条件が揃うと、攻撃者が照合を繰り返して一致を探す余地が生まれます。ハッシュ化保存は有効ですが、トークン自体の強度（十分なランダム性と長さ）と照合のレート制御がセットです。

ハッシュ値だけで改ざん検知している仕組み

「ファイルのハッシュ値を公開しておき、同じなら正しい」という設計は、配布元が正しく保護されている前提では役立ちます。しかし、攻撃者がハッシュ値の配布経路を改ざんできるなら、検証は形骸化します。さらに、改ざん検知を本気で担保するなら、鍵付きの仕組み（HMAC）やデジタル署名が必要です。ここを“ただのハッシュ”で済ませると、攻撃モデルによっては守りになりません。

原像攻撃の危険性

原像攻撃が成功すると、認証突破や機密情報の推測、検証機構の形骸化といった形で被害が発生します。ただし、危険性の語り方は「原像攻撃そのものが何を可能にするか」と「関連する性質（衝突等）がどんな被害を生むか」を分けて説明すると、誤解が減ります。

なりすまし（認証突破）の可能性

パスワードハッシュが漏洩し、攻撃者が一致する原像（パスワード）を見つければ、正規ユーザーとしてログインできる可能性があります。特に、同じパスワードを他サービスで使い回している場合、被害は連鎖します。管理者権限が奪われると、設定改変、ログ消去、横展開など、影響は急拡大し得ます。

ここでの本質は、ハッシュ関数の数学的弱点だけではありません。入力（パスワード）の弱さ、保存方式（速いハッシュ）、追加防御（MFAやレート制限）の欠如が重なると、現実的に破られやすくなります。

機密情報の推測・再現

システムが「機密情報をハッシュ化して保存している」場合でも、その機密情報自体が短い・候補が少ない（例：社員番号のように範囲が狭い識別子）と、攻撃者は候補を総当たりして一致を探せます。ハッシュは暗号化ではないため、候補空間が小さいデータの秘匿には向きません。必要に応じて暗号化やアクセス制御と組み合わせる必要があります。

改ざん・署名の論点は「原像」だけではない

「ハッシュの衝突によってデジタル署名の信頼性が失われる」といった影響は、主に衝突攻撃（Collision）の領域です。原像攻撃と同一視すると、防御の選択を誤りやすくなります。

実務上は、次のように整理すると判断しやすくなります。

• 認証・照合（パスワード等）：原像探索（辞書・総当たり）を現実的にさせない設計が重要
• 改ざん検知（メッセージ認証）：単なるハッシュではなく鍵付き（HMAC）や署名が重要
• 署名・証明書：衝突耐性が弱いアルゴリズム（例：古いもの）を避け、推奨構成へ移行

原像攻撃に対する現状の脅威レベル

SHA-256やSHA-3のように、現代の推奨構成で十分な出力長を持つハッシュ関数に対して、純粋な原像攻撃を現実的なコストで成功させるのは一般に困難とされています。一方で、現場で問題になるのは、次のような“運用・設計の隙”です。

• MD5やSHA-1など、用途的に避けるべき古いハッシュが残っている
• パスワードを「SHA-256で1回だけ」など、速い方式で保存している
• ソルトなし・固定ソルト・短いトークンなど、候補空間が狭い
• 照合APIにレート制限や監視がなく、試行が続けられる

つまり、脅威レベルは「ハッシュ関数そのもの」だけでは決まらず、使い方と前提条件で大きく変わります。

原像攻撃の防御策

原像攻撃への対策は、アルゴリズム選定だけでなく、用途に応じた“正しい使い方”を採用し、移行と運用まで含めて整えることがポイントです。ここでは、実務で実装しやすい順に整理します。

強力なハッシュ関数の選択

改ざん検知や識別子生成など一般用途のハッシュでは、SHA-2（例：SHA-256）やSHA-3など、推奨される現代的なアルゴリズムを採用し、十分な出力長を確保します。MD5やSHA-1は、用途によっては安全性不足が指摘されており、原則として新規採用は避け、計画的に移行するのが安全です。

ただし、ここで注意が必要です。パスワード保管において「SHA-256だから安全」という判断は危険です。パスワードは入力の候補空間が小さくなりがちで、かつ攻撃者は高速計算できる環境を持てるため、一般ハッシュをそのまま使うと“速すぎて”破られやすくなります。

パスワードは「専用のハッシュ方式」を使う

パスワード保管では、Argon2（例：Argon2id）、bcrypt、scryptなど、パスワード向けに設計された方式を使います。これらは計算を意図的に重くし、攻撃者の総当たりを難しくします。加えて、次の条件を満たすと現実的な耐性が上がります。

• 各ユーザーごとに一意なソルトを付ける（同じパスワードでもハッシュが同じにならない）
• 可能なら、サーバ側の秘密値（ペッパー）を併用する（漏洩時の追加防御）
• ログイン試行にレート制限、多要素認証（MFA）、監視を組み合わせる

このセットにより、漏洩後のオフライン攻撃（ハッシュの総当たり）と、オンライン攻撃（ログイン試行）双方に強くなります。

ソルト付きハッシュの利用

ソルトは、ハッシュ化する前に入力に付加するランダムな値です。ソルトを使用することで、同じ入力でも異なるハッシュ値が生成されるため、辞書攻撃やレインボーテーブルが効きにくくなります。特にパスワードでは必須に近い対策です。

ここでの注意点は、ソルトは「秘密である必要はない」一方で、「固定してはいけない」点です。全ユーザー共通の固定ソルトは、攻撃者が一度表を作れば再利用できてしまうため、防御効果が大きく下がります。

鍵付きハッシュ（HMAC）と鍵管理

改ざん検知やメッセージの正当性確認を行いたい場合、単なるハッシュではなく、鍵付きハッシュ（HMAC）などの方式が適しています。HMACでは攻撃者が鍵を知らない限り正しい値を作れないため、“ハッシュを真似する”タイプの攻撃に強くなります。

この場合に重要なのが鍵管理です。鍵の漏洩が起きれば安全性が崩れるため、アクセス制御、保管場所の分離、監査、必要に応じた鍵更新（ローテーション）を運用として整備します。原稿内の「鍵の定期的な更新」は、原像攻撃の一般論というより、鍵付き方式（HMAC等）を採用した場合の運用論として位置づけると誤解が減ります。

移行計画と段階的な切り替え

古いハッシュから新方式へ移行する際は、「すべてを一度に置き換える」より、段階移行が現実的です。例えばパスワードなら、ログイン成功時に新方式へ再ハッシュして更新する、トークンなら新旧を一定期間併存させる、といった方法があります。

移行では次の点が落とし穴になりやすいです。

• データベースに「どの方式で生成したハッシュか」を示す情報がなく、判別できない
• 旧方式を残したまま例外運用が増え、いつまでも撤去できない
• 開発・運用・監査で責任範囲が曖昧で、移行が止まる

方式の棚卸し（どこで何が使われているか）を最初に行い、撤去期限と担当を明確にして進めるのが安全です。

セキュリティパッチの適用と実装リスクの低減

ハッシュ関数の理論だけでなく、実装上の問題（ライブラリの脆弱性、設定ミス、脆弱な乱数生成、ログへの機密値出力など）が事故の原因になることがあります。定期的に依存ライブラリを更新し、セキュリティ情報を監視し、必要なパッチを速やかに適用できる体制を整えます。

また、実装の安全性を上げるには「自作しない」ことも大切です。暗号・ハッシュは、枯れたライブラリと推奨設定を使い、レビューとテストで確認するのが現実的です。

まとめ

原像攻撃は、与えられたハッシュ値に一致する入力（原像）を見つけようとする攻撃で、認証突破や機密情報の推測などにつながります。ただし、現場でのリスクは「ハッシュ関数が弱いから」だけではなく、古い方式の放置、パスワード保管での設計ミス（速いハッシュの利用、ソルト不備）、照合APIの運用不備（レート制限なし）など、使い方の問題で顕在化しやすい点が重要です。用途に応じて、一般用途はSHA-2/SHA-3、パスワードはArgon2/bcrypt/scrypt、改ざん検知はHMACや署名、と使い分け、移行と運用まで含めて整えることが、原像攻撃を含むハッシュ関連リスクの現実的な低減につながります。

よくある質問（FAQ）