【情報セキュリティマネジメント】認証方式の仕組み、見分ける軸は「何を毎回変えるか」｜チャレンジレスポンス・OTP・SSO・EMV 3-Dセキュア

2026.08.27

認証方式は、名称だけでなく、何を確認し、どの攻撃を防ぎやすく、何を保証しないかで整理します。

例えば、次の方式は目的が異なります。

  • チャレンジレスポンス認証：過去の認証応答を再利用しにくくする
  • ワンタイムパスワード：認証ごとに変化するコードを使い、成功後は同じ値を再利用しない
  • 多段階認証：ログイン時と重要操作時など、複数の段階で認証する
  • リスクベース認証：端末・場所・時刻・行動などから対応を変える
  • シングルサインオン：一度の認証結果を複数サービスで利用する
  • CAPTCHA：人間と自動プログラムを区別しやすくする
  • EMV 3-Dセキュア：非対面カード決済でカード会員認証と不正利用抑止を支援する

全てを「同じものを二度使わせない方式」とまとめることはできません。

この記事では、毎回変える、使い捨てにする、段階を分ける、状況で対応を変える、認証結果を共有する、人間とボットを分ける、カード決済を認証するという七つの軸で見分けます。

読み終えるころには、事例に出てくる仕組みが七つのどれかを見分けたうえで、その方式が何を保証しないのかまで押さえて判断できるようになります。

先に結論：方式ごとに変えるもの・確認するものが違う

方式 中心となる仕組み 主な目的・効果 主な限界
チャレンジレスポンス認証 毎回異なるチャレンジへ応答する 秘密そのものの送信を避け、リプレイを防ぎやすくする チャレンジの使い回しや応答再利用を許すと防げない
ワンタイムパスワード（OTP） 認証ごとに変化する値を使い、成功後は再利用しない 固定値の繰返し悪用を抑える 偽サイトによるリアルタイム中継には弱い
多段階認証 複数の場面・段階で認証する 重要操作前の再確認など 異なる要素を使うとは限らない
リスクベース認証 状況・行動からリスクを評価する リスクに応じて許可・追加認証・制限などを変える 評価値だけで本人を完全に断定できない
シングルサインオン（SSO） 一つの認証結果を複数サービスで利用する 利便性・アカウント管理の集中化 認証基盤の侵害・停止の影響が広がり得る
CAPTCHA 人間と自動処理を区別する課題・判定を使う ボットによる大量操作を抑制する 本人認証ではなく、回避・アクセシビリティの課題もある
EMV 3-Dセキュア 決済・端末情報などをカード発行会社へ連携し、必要に応じて認証する 非対面カード決済の不正利用を抑える カード番号の暗号化や決済承認そのものではない

1．チャレンジレスポンス認証

チャレンジレスポンス認証は、検証者が提示する値であるチャレンジに対して、利用者側が秘密情報又は秘密鍵を用いてレスポンスを計算し、その結果を検証する方式です。

基本的な流れ

  1. サーバがチャレンジを生成する
  2. 利用者側の認証器が、チャレンジと秘密情報・秘密鍵からレスポンスを生成する
  3. 利用者側がレスポンスを送信する
  4. サーバがレスポンスを検証する
  5. 使用済み又は古い認証メッセージを拒否する

秘密情報そのものを毎回ネットワークへ送るのではなく、秘密情報を利用して計算した応答によって、その秘密を保持・制御していることを示します。

リプレイ攻撃を防ぐ条件

リプレイ攻撃は、攻撃者が過去に取得した正当な認証メッセージを再送し、本人になりすまそうとする攻撃です。

チャレンジレスポンス認証でリプレイ攻撃を防ぐには、次が必要です。

  • 認証ごとに再利用しないチャレンジを使用する
  • チャレンジに十分な長さと一意性を持たせる
  • チャレンジと認証セッションを適切に結び付ける
  • 使用済み・期限切れの応答を拒否する
  • 応答を別の接続・利用者・処理へ流用させない

チャレンジを使い回すと、過去に取得された正当な応答を再利用できる余地が生じます。

新しいチャレンジと、古い応答を受け付けない検証の両方が必要です。

「現在時刻を使う方式は全て誤り」ではない

試験問題では、現在時刻を単純なチャレンジとして使い、応答を長時間有効にしたり再利用を許したりする選択肢が誤りとして出ることがあります。

しかし、時刻を認証値の生成へ利用すること自体が、常に誤りというわけではありません。時刻同期型OTPのように、時刻を利用する標準方式もあります。

問題になるのは、次のような設計です。

  • チャレンジの新鮮性・一意性が不足している
  • 有効期間が必要以上に長い
  • 同じ応答を繰り返し受け入れる
  • 認証セッションとの結び付きが弱い

「時刻を使ったか」だけでなく、新鮮性と再利用拒否が確保されているかを確認します。

2．ワンタイムパスワード

ワンタイムパスワードは、認証ごとに変化し、成功した値を再び受け入れないことを基本とする認証情報です。時刻同期型では、これに加えて短い有効期間を設けます。

OTPはOne-Time Passwordの略です。

主な方式

方式 値が変化する基準
イベント同期型 認証回数・カウンタ
時刻同期型 現在時刻と時間区間
チャレンジ応答型 サーバが提示するチャレンジ

OTPを生成する機器・アプリは、内部の秘密情報と、カウンタ・時刻・チャレンジなどから認証値を生成します。チャレンジ応答型の実装例にはOCRAがあります。ただしOCRAという用語自体はSGシラバスVer.4.1の用語例には明示されていません。SGでは方式名の細部より、認証値の新鮮性と再利用拒否を押さえます。

リプレイ対策

短い有効期間だけ設定しても、同じ有効期間内に同じOTPを何度も受け入れれば、取得した値を再利用される可能性があります。

そのため、検証側は原則として、有効期間内であっても同じOTPを一度しか受け入れないようにします。

  • 使用済みOTPを拒否する
  • 時刻同期型では許容する時間幅を必要最小限にする
  • 認証失敗回数を制限する
  • 通信を保護する
  • OTP生成器・登録端末を適切に管理する

固定パスワードより再利用されにくい

固定パスワードは、同じ値を繰り返し送信・入力します。

OTPは値が変化するため、過去に取得された値を後の認証へそのまま使われるリスクを低減できます。

ただし、OTPによってパスワードへの全ての攻撃を防げるわけではありません。

3．OTPはフィッシング耐性を自動的には持たない

攻撃者が利用者を偽サイトへ誘導し、入力されたOTPを有効期間内に正規サイトへ即時中継すると、認証が成立する可能性があります。

典型的な流れ

  1. 利用者が偽サイトへID・パスワードを入力する
  2. 攻撃者が正規サイトへ同じ情報を入力する
  3. 正規サイトがOTPを要求する
  4. 攻撃者が偽サイトを通じて利用者へOTPを入力させる
  5. 攻撃者が有効なOTPを直ちに正規サイトへ中継する

この攻撃では、OTPを後日再利用するのではなく、有効な間にリアルタイムで使用します。

したがって、OTPは次の性質を持ちます。

  • 固定値の繰返し悪用に強い
  • 適切に一回限りで検証すればリプレイ耐性を持つ
  • 偽サイトへのリアルタイム中継を単独では防げない
  • 接続先の正当性を暗号学的に確認する方式とは別である

フィッシング耐性を高めるFIDO・パスキーは「パスワードレス時代の本人確認」の記事で扱います。

4．多要素認証と多段階認証の違い

多要素認証と多段階認証は、似た名称ですが、見ている軸が異なります。

方式 判断する軸
多要素認証 記憶・所有・生体の異なる種類を組み合わせる
多段階認証 ログイン時・重要操作時など、複数の段階で認証する

多段階だが多要素ではない例

  1. ログイン時にパスワードを入力する
  2. 送金前に同じパスワードを再入力する

認証は二段階で行っていますが、使用しているのは記憶要素だけです。

そのため、多段階認証ではありますが、多要素認証とは限りません。

多要素かつ多段階になる例

  1. ログイン時にパスワードとセキュリティキーを使用する
  2. 高額送金前に生体認証による再認証を求める

異なる要素を使用し、複数の段階でも認証しています。

この方式は、多要素認証と多段階認証の両方に該当する構成が可能です。

多要素と多段階は排他的ではなく、別の軸です。

認証の三要素と、多要素認証の成立条件は「利用者認証の3要素と生体認証」の記事で扱います。

5．再認証：重要操作前に本人を再確認する

複数の段階で認証する構成の例として、重要操作前の再認証があります。

再認証を検討する場面

  • 送金
  • パスワード変更
  • 認証器の追加・削除
  • 登録メールアドレス・電話番号の変更
  • 大量データのダウンロード
  • 管理者権限を伴う操作
  • 長時間継続したセッションでの重要処理

ログイン後のセッションが長時間続いている場合や、離席中に第三者が端末を操作した場合に、最初のログインだけへ依存すると危険です。

重要な処理の直前に、利用者の継続的な存在や認証状態を改めて確認します。

ただし、再認証で同じパスワードだけを再入力させる場合、それだけで多要素認証になるわけではありません。

6．リスクベース認証

リスクベース認証は、認証時の状況・行動などからリスクを評価し、評価結果に応じて認証要求やアクセス可否を変える方式です。

評価に利用される情報の例

  • 利用端末
  • OS・ブラウザ
  • 接続元IPアドレス
  • 国・地域
  • 利用時刻
  • 過去のログイン履歴
  • 移動速度・地理的な不自然さ
  • 操作・取引内容
  • 金額
  • 失敗回数
  • 既知の不正・侵害情報

これらの情報は、記憶・所有・生体の認証要素そのものとは限りません。リスクを評価するための状況情報です。

リスクに応じて対応を変える

評価 対応例
低リスク 通常どおり許可する
中程度 追加認証、本人通知、機能制限を行う
高リスク 取引保留、アクセス拒否、アカウント保護、本人確認を行う
重大・既知の攻撃 即時遮断、セッション失効、インシデント対応へ移行する

リスクベース認証は、「異常があれば必ず追加認証する方式」だけではありません。

評価結果に応じて、許可、追加認証、制限、保留、拒否などを段階的に選びます。

「通常と違う＝不正」とは限らない

海外出張、新しい端末、深夜作業など、正当な事情がある場合もあります。

通常と異なるという一つの情報だけで不正を断定せず、複数の情報と組織の基準に基づいて評価します。

一方、評価結果が十分に高リスクであれば、即時拒否・停止が適切な場合もあります。

重要なのは、必ず許可又は必ず停止することではなく、評価したリスクへ対応を比例させることです。

7．シングルサインオン

シングルサインオンはSingle Sign-Onの略で、SSOとも呼ばれます。

一度の認証結果を利用して、複数のアプリケーション・サービスへ継ぎ目なくアクセスできるようにする仕組みです。

代表的なフェデレーション型SSOでは、IDプロバイダなどが利用者を認証し、各サービスが認証結果を示すアサーションなどを検証します。SSOの実装方式はこれに限られません。

利点

  • 利用者が多数のパスワードを覚える負担を減らせる
  • サービスごとのパスワード使い回しを減らせる
  • 認証ポリシーを集中管理しやすい
  • 多要素認証を認証基盤へ集約できる
  • 入社・異動・退職時のアカウント管理を連携しやすい
  • 認証ログを集中して監視しやすい

リスク

  • 認証基盤が侵害されると複数サービスへ影響が広がる
  • 認証基盤が停止すると、複数サービスの新規ログインなどへ影響が広がる
  • SSOセッション・アサーションの不正利用が複数サービスへ影響する
  • 認証基盤のログイン画面がフィッシングの標的になる
  • 退職者・不要アカウントの停止漏れが広範囲へ影響する

主な対策

  • 認証基盤へ多要素認証を導入する
  • フィッシング耐性のある認証を検討する
  • セッション・アサーションを適切に検証する
  • 認証・管理操作を監視する
  • 冗長化・障害対応を行う
  • 入社・異動・退職のプロビジョニングを管理する
  • 各サービスのアクセス権を定期的に棚卸しする

SSOが一元化するのは主に認証です。

各サービスで何を許可するかという認可・アクセス権が、自動的に適正化されるわけではありません。

パスワード使い回しとの違い

複数サービスへ同じパスワードを設定しても、SSOではありません。

パスワード使い回しでは、各サービスが個別に認証し、一つのサービスから漏れたパスワードが他サービスへ悪用される危険があります。

フェデレーション型SSOでは、管理された認証基盤による認証結果を、信頼関係・プロトコルに基づいて複数サービスが利用します。

8．CAPTCHA

CAPTCHAは、利用者の操作が人間によるものか、自動プログラムによるものかを区別しやすくする仕組みです。

利用例

  • ゆがんだ文字の入力
  • 指定された対象を含む画像の選択
  • 簡単な質問・操作
  • 利用状況・動作に基づく自動判定
  • 不審な場合だけ追加課題を提示する方式

主な目的

  • ボットによる大量アカウント登録の抑制
  • 迷惑投稿・スパムの抑制
  • 自動化された総当たり・大量操作の緩和
  • 不正なフォーム送信の抑制

CAPTCHAは本人認証ではない

CAPTCHAが判断しようとするのは、人間による操作かどうかです。

登録済みの利用者本人であること、氏名・住所などの実在性、端末の所有を証明するものではありません。

  • 「人間か」：CAPTCHA
  • 「登録本人か」：利用者認証
  • 「現実の身元は誰か」：本人確認・身元確認
  • 「通信を読まれないか」：TLS（Transport Layer Security）などの暗号化

限界

  • 自動プログラム・AIによって突破される場合がある
  • 人手による代行へ弱い場合がある
  • 視覚・聴覚・認知上の障害がある利用者へ負担となる
  • 正規利用者の離脱・操作ミスを増やす場合がある
  • 単独で不正アクセスや大量操作を完全に防げない

CAPTCHAは補助的対策として使い、レート制限、行動分析、アカウント監視などと組み合わせます。

9．EMV 3-Dセキュア

EMV 3-Dセキュアは、インターネット通販などの非対面カード決済で、カード会員の認証と不正利用の抑止を支援する仕組みです。

EMV 3-D Secure、EMV 3DSとも表記されます。SGシラバスでは「EMV 3-Dセキュア（3Dセキュア2.0）」として示されています。

基本的な仕組み

加盟店側、カード発行会社側、両者をつなぐ相互運用領域の間で、次の情報などを交換します。

  • 取引内容
  • 支払方法
  • 利用端末
  • カード会員に関する情報など、リスク評価に用いる情報
  • 認証結果

カード発行会社は、受け取った情報や自ら保持する情報などを用いて取引リスクを評価します。

フリクションレスフロー

リスクが低いと判断された場合、カード会員へ追加操作を求めず、裏側の情報交換と評価によって認証処理を進める場合があります。

チャレンジフロー

リスクが高い場合やカード発行会社が確認を必要とする場合、次のような追加認証を求めることがあります。

  • ワンタイムコード
  • カード会社のアプリによる承認
  • 生体認証
  • 別経路の認証
  • その他、カード発行会社が採用する方式

したがって、EMV 3-Dセキュアは「全ての決済で必ずワンタイムパスワードを入力させる方式」ではありません。

リスクベース認証との関係

リスクベース認証は、状況情報から認証対応を変える一般的な考え方です。

EMV 3-Dセキュアは、非対面カード決済という特定の用途で、取引・端末などの情報を交換し、リスクに応じたフリクションレス処理又はチャレンジを行えるプロトコルです。

リスクベース認証 EMV 3-Dセキュア
幅広いサービスで使える一般的な認証方針 非対面カード決済向けの仕組み
端末・場所・時刻・行動などを評価 取引・支払方法・端末などの情報を連携
追加認証・制限・拒否などを選択 フリクションレス又はチャレンジなどを選択

EMV 3-Dセキュアが行わないこと

  • カード番号そのものを暗号化する仕組みではない
  • 決済通信全体を保護するTLSの代わりではない
  • CAPTCHAのように人間とボットを区別する仕組みではない
  • 加盟店の決済承認・売上処理そのものではない
  • 全てのカード不正利用を完全に防ぐものではない

10．七つの方式を事例から見分ける

事例 該当する方式
サーバが毎回異なる値を出し、秘密鍵で応答する チャレンジレスポンス認証
カウンタ・時刻などで毎回異なるコードを使う ワンタイムパスワード
ログイン後、高額送金前にもう一度認証する 多段階認証・再認証
新端末・海外・深夜のため追加確認を求める リスクベース認証
一度の認証結果で複数のクラウドサービスへ入る シングルサインオン
画像課題によってボットの大量登録を抑える CAPTCHA
ネット通販のカード決済で発行会社が取引リスクを評価する EMV 3-Dセキュア

11．科目Bでの使われ方

科目Bでは、導入された仕組みの内部処理ではなく、その方式が保証しない範囲まで期待していないかを判断する材料として使われます。

事例文に次の言葉が出てきたら、この記事の内容が判断材料になります。

事例文の合図 確認すること
ログイン後にもう一度パスワードを求めているので多要素認証だ 段階を増やしただけで、要素の種類は同じではないか
ワンタイムパスワードを導入したのでフィッシング対策は済んだ 偽サイトへのリアルタイム中継まで防げているか
普段と違う場所からのアクセスだったので直ちに遮断した 評価したリスクと対応が比例しているか
シングルサインオンを入れたので権限管理も一元化された 認可・アクセス権を別に棚卸ししているか
CAPTCHAを入れたので不正ログインは防げる 人間かどうかの判定であり、本人認証ではない

担当者としては、導入された仕組みが「何を確認するもので、何を保証しないもの」なのかを切り分けます。認証基盤を一元化した場合は、停止・侵害時の影響範囲と、退職者・不要アカウントの停止漏れをあわせて確認します。対応方針を変える判断が必要な場合は、独断で決めずに上位者や関係部署へ報告し、指示を仰ぎます。

12．方式を見分ける手順

  1. 過去の認証メッセージを再送できるか確認する

新しいチャレンジ・一回限りのOTP・再利用拒否があるかを見ます。

  1. 秘密情報そのものを送るのか、計算した応答を送るのか確認する

チャレンジへの応答ならチャレンジレスポンス認証です。

  1. 値が何を基準に変わるか確認する

カウンタ、時刻、チャレンジならOTP方式を考えます。

  1. 種類か、段階か確認する

異なる認証要素は多要素、複数の場面は多段階です。

  1. 状況評価によって対応を変えているか確認する

端末・場所・時刻・行動などから追加認証・制限を選ぶならリスクベース認証です。

  1. 一つの認証結果を複数サービスが利用しているか確認する

その場合はSSOです。

  1. 登録本人ではなく、人間と自動処理を区別しているか確認する

その場合はCAPTCHAです。

  1. 非対面カード決済の会員認証か確認する

発行会社が取引情報を評価し、必要に応じてチャレンジするならEMV 3-Dセキュアです。

  1. 方式が保証しないことまで断定していないか確認する

OTPはフィッシング耐性を自動的に持たず、CAPTCHAは本人認証ではなく、SSOは認可を自動化しません。

よくある取り違え

誤った理解 正しい整理
チャレンジレスポンス認証は毎回同じチャレンジを使う 新しいチャレンジと古い応答の拒否が必要
現在時刻を使う認証は全て安全でない 時刻同期型OTPもある。新鮮性・有効期間・再利用拒否を確認する
OTPは短時間有効なら同じ値を何度受け入れてもよい 有効期間内でも原則として同じOTPは一度だけ受け入れる
OTPならフィッシングを完全に防げる 有効な値のリアルタイム中継には弱い
二段階認証は必ず多要素認証である 同じ記憶要素を複数段階で使う場合もある
多要素認証と多段階認証は排他的である 一つの構成が両方に該当する場合がある
通常と異なるアクセスは必ず即時停止する 複数の情報で評価し、リスクに比例して対応する
リスクベース認証ではアクセスを拒否してはいけない 高リスクなら拒否・停止が適切な場合もある
場所・時刻は認証要素である 通常はリスク評価の材料であり、認証の三要素とは別
SSOは同じパスワードを複数サービスで使うこと 認証基盤の認証結果を複数サービスで利用する仕組み
SSOを使えば各サービスの権限確認は不要になる 認証と認可は別に管理する
SSOは常に安全性を下げる 集中リスクはあるが、認証・退職者管理を強化できる利点もある
CAPTCHAは登録本人であることを証明する 人間と自動プログラムの区別を支援する
CAPTCHAだけでボットを完全に防げる 回避・代行・アクセシビリティの課題があり、補助策として使う
EMV 3-Dセキュアは全取引でOTPを要求する 低リスクでは追加操作なし、高リスクではチャレンジとなる場合がある
EMV 3-Dセキュアはカード番号を暗号化する 非対面カード決済の認証・リスク評価を支援する
EMV 3-Dセキュアとリスクベース認証は同義である 3DSはカード決済向けの具体的なプロトコルで、リスクベース認証を利用できる

まとめ

  • 認証方式は、何を確認し、何を防ぎ、何を保証しないかで見分ける
  • チャレンジレスポンス認証は、毎回異なるチャレンジへの応答で秘密の保持・制御を確認する
  • リプレイ対策には、新しいチャレンジ、セッションとの結び付き、古い応答の拒否が必要
  • 時刻を使うこと自体が常に誤りではなく、新鮮性・有効期間・再利用拒否を確認する
  • OTPは、認証ごとに変化し、成功した値を再び受け入れないことを基本とする認証情報
  • OTPにはイベント同期型、時刻同期型、チャレンジ応答型などがある
  • 検証者は、有効期間内でも同じOTPを原則として一度だけ受け入れる
  • OTPは固定値の再利用に強いが、リアルタイム中継を単独では防げない
  • 多要素認証は異なる要素の種類、多段階認証は複数の認証場面を表す
  • 多段階であっても多要素とは限らず、一つの構成が両方に該当する場合もある
  • 重要操作前の再認証は、長時間セッションや離席中の操作への対策になる
  • リスクベース認証は、端末・場所・時刻・行動・取引などを評価する
  • 評価結果に応じて、許可、追加認証、制限、保留、拒否などを選ぶ
  • SSOは、一度の認証結果を複数サービスで利用できるようにする
  • SSOには利便性・集中管理の利点と、認証基盤への集中リスクがある
  • SSOを導入しても、各サービスのアクセス権が自動的に適正化されるわけではない
  • CAPTCHAは人間と自動プログラムを区別しやすくする補助策で、本人認証ではない
  • CAPTCHAには回避可能性とアクセシビリティ上の課題がある
  • EMV 3-Dセキュアは、非対面カード決済で取引・端末情報を交換し、カード会員認証を支援する
  • EMV 3-Dセキュアでは、低リスク取引のフリクションレスフローと、追加認証を行うチャレンジフローがある
  • 科目Bでは、変化する値、再利用拒否、段階と要素、リスクへの対応、認証結果の共有、対象が人間かカード会員かを確認する

関連記事

  • C1-T07：ソーシャルエンジニアリングとフィッシング
  • C1-T08：パスワードへの攻撃
  • C1-T09：ネットワーク・通信への攻撃
  • C2-T03：ハッシュ関数とメッセージ認証
  • C2-T05：PKIとデジタル証明書
  • C2-T06：利用者認証の3要素と生体認証
  • C2-T08：パスワードレス時代の本人確認
  • C5-T06：アクセス制御と権限管理
  • C5-T11：セキュアプロトコルと実装技術

本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。

参考資料

  • IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
  • NIST SP 800-63B-4「Digital Identity Guidelines: Authentication and Authenticator Management」
  • NIST SP 800-63C-4「Digital Identity Guidelines: Federation and Assertions」
  • RFC 4226「HOTP: An HMAC-Based One-Time Password Algorithm」
  • RFC 6238「TOTP: Time-Based One-Time Password Algorithm」
  • RFC 6287「OCRA: OATH Challenge-Response Algorithm」
  • EMVCo「EMV 3-D Secure」
  • W3C WAI「Inaccessibility of CAPTCHA」

関連する問題

コメント

タイトルとURLをコピーしました