SC科目B（午後）のMFA・TOTP・Push認証・FIDO2・WebAuthn・パスキー・アカウント回復
管理者アカウントへの不審なログインと端末紛失の申告を一つの事例に、MFA、TOTP、Push認証、FIDO2・WebAuthn、パスキー、アカウント回復をつなげます。科目Bでは『MFA成功』という集約ログだけで安全と判断せず、何を誰が承認し、どの認証器がどの取引へ結び付いたかを追います。
読み順は、①構成と認証要素、②TOTP、③Push、④WebAuthnとパスキー、⑤異常ログ、⑥回復と認証器の再登録、⑦再開判断、⑧記述演習です。accounts.example、IP、時刻、ID、ログは全て教材用の架空例です。時刻はUTC、内部利用者IDは整数です。
1. 事例の構成とMFAの判断単位
請求システムhttps://accounts.exampleには経理管理者A（内部利用者ID 41）がいます。AはパスワードとTOTPアプリ、Push認証アプリ、同期型パスキーを登録しています。攻撃者は漏れたパスワードを知っていますが、Aの端末とパスキーを持ちません。認証サーバは管理者ログインと振込先変更の前に、設定した方式の確認を要求します。
利用者A：通常の端末からログインし、認証アプリまたはパスキーを操作する。
ブラウザ：ログイン画面を表示し、WebAuthnでは認証器へchallengeとRP IDを渡す。
認証サーバ／Relying Party（RP）：パスワード・OTP・Push・WebAuthn応答を検証し、内部利用者ID 41へ対応付ける。
認証器：TOTPアプリ、Pushアプリ、端末内または外部のFIDO認証器。登録時の秘密や秘密鍵を保持する。
ヘルプデスク：端末紛失時に回復手順を扱う。通常のログイン成功を代行して記録する主体ではない。
MFAは異なる種類の要素を組み合わせて認証を強める考え方です。パスワードは知識、登録端末や鍵は所持、生体情報は本人の特徴に関係します。ただしスマートフォンのロック解除とその中のアプリが同じ侵害端末に依存する場合、要素の名前だけで独立性を保証できません。利用者、端末、認証器、サーバのどこが侵害され得るかを分けます。
二回入力しただけでは二要素とは限りません。例えばパスワードと別の秘密の質問は、どちらも知識要素です。逆にパスキーは、秘密鍵の利用と端末内のPIN・生体認証を組み合わせる構成があり、単に『パスワードがないので単要素』とは決められません。実際のUV要求と結果を見ます。
同じ管理者アカウントで使う方式の概略。各方式の設定・検証条件で結果は変わる。
WebAuthnの耐フィッシング性は、正しいRP IDとoriginの検証を前提にした方式の性質です。Pushの番号一致は誤承認を減らしますが、偽サイトで見せた番号を本人へ入力させる中継攻撃まで防ぐ保証ではありません。各方式の成功ログから確認できる範囲を分けます。
2. TOTPは何を計算し、何を検証するか
Time-based One-Time Password（TOTP）は、利用者の認証アプリとサーバが共有する秘密鍵K、および時刻から短いコードを作ります。RFC 6238はHOTPを時間カウンタに適用し、標準的な時間幅の例として30秒を示します。コードの桁数やHMACアルゴリズムは登録時に双方で一致させます。
T = floor((現在のUnix時刻 - T0) / X)
TOTP = HOTP(K, T)
教材例: X=30秒、T0=0
09:05:00～09:05:29 UTC は同じ時間ステップ
09:05:30 UTC から次の時間ステップHOTPは共有鍵KとカウンタTにHMACを適用し、結果を短い数字へ変換します。TOTPではカウンタを時刻から求めるため、同じKと時刻幅を持つアプリとサーバが同じコードを計算できます。桁数が短いことは入力しやすさのためであり、コードだけからKを推測しにくいことと、オンラインで総当たりされにくいことは別の対策です。
利用者ごとに異なるKを安全に登録し、サーバ側では必要な検証処理だけが使えるように保護します。QRコードや手入力用の登録文字列はKを配布するための秘密であり、画面撮影やログ記録で漏れれば同じコードを生成されます。6桁の表示コードそのものと、継続して新しいコードを作れるKの漏えいは影響が違います。
TOTPアプリの初期登録では、既に確認済みの利用者だけに登録用のKを示し、アプリで生成したコードの照合が通ってから認証器として有効化します。新しいKを登録する操作が盗まれたパスワードだけで実行できれば、攻撃者は自分のアプリを第二要素にできます。登録・再登録・失効の履歴を、通常ログインと別のイベントとして監査します。
サーバは受け取った時刻に対応するステップを計算します。端末の時計ずれや通信遅延に備えた許容範囲は明示し、広げ過ぎません。成功済みのコードは、同じ時間ステップ内で再送されても二回目を受理しません。短いコードへのオンライン推測には回数制限と監視が必要です。
09:05:10 auth password user_id=41 result=pass
09:05:15 totp user_id=41 step_ref=T-41
code_match=true used_before=false result=pass
09:05:17 totp user_id=41 step_ref=T-41
code_match=true used_before=true result=reject_reuse
09:05:31 totp user_id=41 step_ref=T-42
code_match=false result=reject_mismatchこの架空ログは値そのものを出していません。09:05:17のコードは数学的には同じ時間ステップで一致しますが、既に成功に使用されたため拒否します。09:05:31の不一致だけでは、誤入力、時刻ずれ、別の登録鍵、攻撃者の試行を区別できません。サーバ時刻、登録履歴、失敗回数と接続元を調べます。
TOTPコードは利用先のドメインやログイン取引へ暗号学的に結び付いていません。偽サイトに入力したコードを攻撃者が時間内に本物のサイトへ中継すると、パスワードと合わせてログインされ得ます。コードが短時間で変わることと、耐フィッシング性は別の性質です。
3. Push認証で取引と端末を結び付ける
Push認証では、パスワードなどの一次確認後に認証サーバが登録済み端末へ承認要求を送ります。サーバは要求ID、対象利用者、端末ID、有効期限、状態を記録し、届いた応答をその要求へ照合します。画面の『承認』だけを記録し、どの要求が発行されたか失うと、後から不正ログインを追いにくくなります。
通知の配信そのものは承認の証拠ではありません。認証アプリは、登録済み端末として認識できる保護された経路で要求を受け、応答を要求IDと端末の登録状態へ結び付けます。単に通知をタップしたというOSの表示だけをサーバが信じる設計では、別の端末や別の取引への取り違えを防げません。
番号一致では、ログイン画面に表示された番号を通知側で選択または入力させます。利用者が自分で開始したログインなら、端末に見えるアプリ名、場所、時刻、番号を照合して承認します。覚えのない要求は拒否して報告します。番号が一致しても、利用者が偽サイトの番号を信じて転記した可能性は残ります。
09:07:00 login_start id=L-71 user_id=41
src=198.51.100.24 password=pass
09:07:01 push_create req=P-71 device=D-41
match_number_ref=N-71 expires=09:08:01
09:07:08 push_create req=P-72 device=D-41
match_number_ref=N-72 expires=09:08:08
09:07:16 push_create req=P-73 device=D-41
match_number_ref=N-73 expires=09:08:16
09:07:20 push_response req=P-73 decision=deny
09:07:21 login id=L-71 session_created=false短時間の連続通知はPush疲労攻撃を疑う材料です。Aが拒否したならP-73の承認は成立していません。ただしP-71やP-72の状態がログにないため、全要求が拒否されたと断定せず、各要求の期限・応答・後続セッションを照合します。ログの接続元IPだけで攻撃者の個人は特定できません。
- 1. 一次確認：証跡 L-71のパスワード成功／防御・対処 漏えい対処と試行監視
- 2. 通知を連発：証跡 P-71～P-73の発行／防御・対処 要求の間隔・回数を制限
- 3. 利用者が判断：証跡 P-73の拒否と端末ID／防御・対処 番号・取引内容を確認
- 4. 結果を照合：証跡 全要求とセッションの状態／防御・対処 未承認の取引を失効
パスワードを知る攻撃者が承認通知を連続発行させた架空例。
対策は、要求ごとの番号一致、通知の頻度制限、明確な拒否・報告操作、不審な一次認証成功の監視を組み合わせます。承認後でもログインの接続元や端末がいつもと違う場合は調査します。管理者など高リスクの操作では、Pushより耐フィッシング性を持つ方式を求める設計が有効です。
サーバが`approved=true`だけ記録しても、本人が正しいサイトへのログインを意図したとは確定できません。攻撃者が偽サイトへ誘導し、番号や操作を中継した可能性、端末が侵害された可能性、利用者が通知を誤承認した可能性を分けて調べます。
4. FIDO2、WebAuthn、パスキーの関係
FIDO2はWebAuthnとCTAPを組み合わせた認証の仕組みです。WebAuthnはWebサイトとブラウザのAPI、CTAPはブラウザなどのクライアントと外部認証器の通信を扱います。パスキーはWebAuthnで使う公開鍵資格情報を利用者が使いやすく扱う形です。秘密鍵は認証器側、公開鍵とcredential IDはRP側に登録します。
登録は認証とは別の処理です。登録時にRPは新しいchallengeを出し、ブラウザがnavigator.credentials.create()を呼び、認証器が鍵を作ります。RPは応答のchallenge、origin、RP IDのハッシュ、利用者確認の方針などを検証し、credential IDと公開鍵を内部利用者ID 41へ結び付けます。検証せず任意の公開鍵を登録すれば、その後の署名検証が正しくても乗っ取りになります。
必要に応じてattestationで認証器の種類や来歴を確かめます。ただしattestationの有無は通常のログイン時の署名検証と同じ意味ではありません。認証器のモデルを限定する業務要件がなければ、attestationを必須にしない設計もあります。
4-1. 認証時のchallengeと署名を追う
ログイン時はRPが予測困難なchallengeを生成して短時間だけ保持します。ブラウザはnavigator.credentials.get()を使い、認証器はそのRP ID用の資格情報で応答します。署名対象にはauthenticatorDataとclientDataJSONのハッシュが含まれ、clientDataJSONにはchallengeやoriginが入ります。RPは保存した公開鍵で署名を検証します。
RPはchallengeを発行したログイン取引とサーバ側の有効期限に結び付け、応答時に一致・期限内・未使用を確認します。検証成功時は同時再送で二重に受理しないよう使用済みへ更新します。ブラウザへ渡すtimeoutだけを、サーバ側の期限や使用済み判定の代わりにはできません。
架空のaccounts.exampleで登録済みパスキーを使う。登録時の公開鍵をRPが保持している。
図の最後のセッションは、RPによる検証が全て成功したときだけ作ります。ブラウザが『生体認証成功』と表示しただけで、RP側のchallenge、origin、RP ID、署名が検証されたとは言えません。
09:10:00 webauthn_start tx=W-41 user_id=41
rp_id=accounts.example challenge_ref=C-41
uv_required=true allow_credential=CR-41
09:10:05 assertion tx=W-41 credential=CR-41
client_type=webauthn.get
origin=https://accounts.example
challenge_match=true challenge_unexpired=true
challenge_unused=true rp_id_hash_match=true
user_present=true user_verified=true
signature_valid=true account_credential_match=true
backup_eligible=true backup_state=true sign_count=0
09:10:06 auth_result tx=W-41 result=pass
challenge_state=consumed session_ref=SESS-41
09:10:07 assertion_replay tx=W-41 credential=CR-41
signature_valid=true result=reject_used_challenge
new_session_created=false
09:16:00 webauthn_start tx=W-47 challenge_ref=C-47
challenge_expires=09:17:00
09:17:03 assertion tx=W-47 challenge_match=true
signature_valid=true result=reject_expired_challenge
new_session_created=falseこのログでは、登録済みCR-41が利用者41の資格情報で、RPの要求したchallengeとoriginに一致し、署名が公開鍵で検証されています。UP（user present）は認証器の操作、UV（user verified）はPINや生体認証などの端末内での利用者確認を表すビットです。RPがUVを必須にした取引では、UVが立っていることを確認します。
09:10:07は通った応答の再送です。署名が有効でもC-41は使用済みなので、RPは新しいセッションを作りません。W-47は一致するchallengeでもサーバ側の期限を過ぎたため拒否します。別取引W-46には別のchallengeを発行します。
利用者名を先に入力する方式では、返されたcredential IDがそのアカウントへ登録済みかを確かめます。利用者名を先に入力しないパスキーログインでは、応答のuserHandleを使ってアカウントを特定し、credential IDとの対応も検証します。公開鍵が正しくても、別アカウントの資格情報を利用者41へ誤対応させてはなりません。
RP IDは通常ドメイン名で、authenticatorDataのrpIdHashはそのハッシュです。originはschemeとhostとportを含むブラウザのオリジンです。同じ文字列ではないので、`origin=accounts.example`をrpIdHashの代わりに比較しません。両方を信頼する期待値へ照合することが重要です。
悪意あるhttps://accounts.example-login.testでは、accounts.example向け資格情報を通常のWebAuthn手順で利用できません。さらにRPがoriginやrpIdHashを検証します。この結び付きがTOTPコードの転記やPush承認と違う耐フィッシング性の根拠です。ただし正規サイトでのXSS、端末侵害、ログイン後のセッション窃取、弱い回復手続までは自動的に防ぎません。
4-2. 同期型パスキーと端末固定型を区別する
同期型パスキーは資格情報が管理サービスなどを通じて複数端末で利用可能になる場合があります。端末固定型は特定の端末やセキュリティキーに留まります。秘密鍵をRPへ送る方式ではありませんが、同期型では同期サービスのアカウント保護と端末追加・回復の安全性も信頼の一部です。
WebAuthnのBEは資格情報がバックアップ可能か、BSは現在バックアップ済みかを示します。両者は同じ意味ではなく、BSは変化し得ます。AのログはBE=1・BS=1なのでバックアップ可能で現在バックアップ済みです。ただし同期方法、利用端末、同期サービスの侵害は、この二つのビットだけからは分かりません。
signCountは認証器が返す署名回数の手掛かりです。増えない、または0の資格情報もあります。保存済み値以下なら複製の兆候になり得ますが、単独で複製確定とは言えません。特に同期型の資格情報を`sign_count=0`というだけで一律拒否する設計は、仕様と運用を確認して判断します。
PINや生体情報は、通常は認証器の秘密鍵を使うためのローカルな解除手段です。RPが指紋画像を受け取るわけではありません。UV=1は認証器側の利用者確認が成功したという結果で、A本人が不正な操作を意図していないと保証するものではありません。
4-3. 重要操作での再認証とセッション
パスキーでログインした後も、RPのアプリ内セッションは別に管理されます。セッションCookieが盗まれたり、管理画面の操作端末が侵害されたりすれば、ログイン時のWebAuthn署名だけでは後続操作を守れません。この事例では振込先変更に5分以内の利用者確認を求め、必要なら新しいWebAuthn取引で再認証します。
09:20 api payee_change session=SESS-41
last_user_verification=09:10 result=step_up_required
09:21 webauthn_start tx=W-46 purpose=payee_change
user_verification=required challenge_ref=C-46
09:21 assertion tx=W-46 result=pass
challenge_match=true origin_match=true uv=true
09:22 api payee_change tx=W-46 result=allowC-46はログイン時のC-41とは別のchallengeです。新しい署名とUVが通ったことをサーバが確認し、どの操作のための再認証かを取引に結び付けます。WebAuthn自体が振込先の値を必ず署名するわけではないため、業務上の変更内容を別の確認画面と監査ログで扱います。
5. 異常ログで原因と成立範囲を切り分ける
次は同じ構成の架空の失敗例です。最初の取引が成功していない状態から別の試行を示しており、同じchallengeを複数取引へ使い回す例ではありません。識別子と検証条件を一つずつ比較します。
09:11:00 tx=W-42 credential=CR-41
challenge_match=false origin=https://accounts.example
signature_valid=true result=reject_challenge
09:12:00 tx=W-43 credential=CR-41
challenge_match=true origin=https://other.example
signature_valid=true result=reject_origin
09:13:00 tx=W-44 credential=CR-41
challenge_match=true origin=https://accounts.example
user_present=true user_verified=false
uv_required=true result=reject_uv
09:14:00 tx=W-45 credential=CR-99
account_credential_match=false result=reject_credentialW-42は署名が有効でも、今の取引のchallengeと結び付かないため拒否します。W-43は別originです。W-44は利用者確認が必要な方針に足りません。W-45はこの利用者の登録済みcredential IDではありません。いずれも単一の失敗ログだけで攻撃者や端末を特定できません。
実際のブラウザはRP IDやoriginの条件で不正な利用を先に止める場合があります。W-43は、検証条件を学ぶためにRPへ別originを示す模擬応答が届いた想定です。正規ブラウザで日常的にこのログが出るとは限りません。
調査では、登録時刻・方法、credential IDと利用者の対応、challengeの発行・失効、origin、UP・UV、署名結果、セッション作成、接続元、端末通知を時系列に並べます。raw challenge、TOTPコード、秘密鍵、回復コードを通常ログへ書きません。製品ごとにログ項目は異なり、未記録は検証失敗と同義ではありません。
6. アカウント回復は新しい認証器の登録につながる
Aがスマートフォンを紛失すると、TOTPアプリ、Pushアプリ、同期型パスキーへのアクセスが同時に失われる場合があります。既に登録した別の認証器でログインできるなら、その認証器で本人を確認して新端末を追加できます。必要な認証器が全て使えないときは、別のアカウント回復手続が要ります。
回復は単なるパスワード再設定ではありません。攻撃者が『端末を失くした』と申告し、弱い本人確認で自分の端末を新しい認証器として登録できれば、以後は正規のWebAuthn署名でログインできます。認証器の追加・削除権限そのものを保護する必要があります。
この架空組織では、Aが事前に保管した単回使用の回復コードに加え、ヘルプデスクでの対面確認を管理者の回復条件にします。担当者は人事台帳に登録済みの顔写真・氏名と来訪者を照合し、別の承認者が確認記録を審査します。申請者が新たに伝えた電話番号やメールは本人確認に使いません。
回復コードは登録時に十分な乱数で生成し、サーバ側ではハッシュなどで保護し、使用後に無効化します。メールアドレスを知ることや盗まれたパスワードだけでは新しいパスキーを登録しません。既存の連絡先への独立通知は不正回復の発見に役立ちますが、それだけで本人と証明したことにはなりません。
高い保証水準を要求する組織では、使える回復手段、本人確認、待機時間、承認者をリスクに合わせて設計します。NIST SP 800-63B-4は回復コード、連絡先、再度の本人確認などを区別し、回復後の通知を求めています。この教材の二経路確認は架空組織の方針であり、全サービスに同じ手順を一律要求する規格の引用ではありません。
09:30 recovery_open id=RC-41 account=41
requester_src=203.0.113.58 reason=lost_phone
09:31 password_check=pass
recovery_code_check=absent
second_channel_check=absent
09:31 recovery_decision=hold
new_credential_registered=false
09:36 notify_existing_contacts id=RC-41
channels=email_and_admin_contact
09:40 account_owner_reports_no_request=true
recovery_decision=deny password_reset_required=true09:31時点では、漏れたパスワードだけでは回復方針を満たしません。09:40にAが申請していないと報告したため、この事例は不正な回復試行として扱います。ただし申請元IPだけでA以外と決めたわけではありません。通知の到達、Aへの確認、認証器の追加履歴を併せて判断します。
- 1. 申請を保留：対応 既存セッションと申請元を確認／確認する証跡 RC-41と認証ログ
- 2. 別経路で確認：対応 コードと人事記録で対面照合／確認する証跡 コード照合・承認記録
- 3. 本人へ通知：対応 既存の連絡先へ独立通知／確認する証跡 送達・異議申立て
- 4. 認証器を登録：対応 承認時のみ新鍵を結び付ける／確認する証跡 登録元・credential ID
- 5. 再開を確認：対応 旧端末失効と利用範囲を確認／確認する証跡 失効・新端末ログイン
回復申請を保持し、本人確認・既存連絡先への通知・認証器の登録を分ける。
図の後半は、正当な回復申請で本人確認と承認が済んだ場合の手順です。RC-41はAが否認したため`bind`へ進みません。図を機械的な自動承認フローと読まず、判断点ごとの証拠を確認します。
6-1. 正当な回復が成立した場合の登録と通知
その後A本人が来訪し、別の申請RC-42を出した場合を考えます。RC-41の否認を取り消して承認するのではなく、新しい要求として回復コードと対面確認をやり直します。
11:00 recovery_open id=RC-42 account=41
reason=lost_phone claimant_present=true
11:02 recovery_code_check=pass code_ref=RCODE-41
used_before=false
11:10 in_person_check=pass hr_record_match=true
operator=HD-7 reviewer=SEC-3 review=pass
11:13 recovery_decision=approve code_state=used
11:15 webauthn_register tx=REG-42 credential=CR-42
origin_match=true rp_id_hash_match=true result=pass
11:16 notify_existing_contacts id=RC-42
channels=email_and_admin_contactRC-42では保管済みコードの照合と、登録済み人事記録を使った対面照合・別担当者の承認がそろって初めて、新しい資格情報CR-42を利用者41に登録します。使用したコードは再利用させず、代わりのコードを安全な経路で再発行します。通知は申請者が今回指定した連絡先ではなく、既存の連絡先へ別途送ります。
残っている強い認証器を使えるか確認する。全て使えないRC-42では、保管済み回復コードと対面での人事記録照合、別担当者の承認を要求IDに紐付けて記録する。
回復コードの再利用を拒否し、失効と再発行を記録する。新しい連絡先への変更を本人確認の代わりに使わない。
新しいWebAuthn資格情報の登録取引でchallenge、origin、rpIdHash、資格情報の利用者対応を検証する。
失われた端末に関連するPush・TOTPの登録とパスキー資格情報を調べ、必要ならRPで資格情報を失効する。既存セッションも別に調べて無効化する。
独立した既存の連絡先へ回復と認証器追加を通知し、本人が否認できる経路を示す。
同期型パスキーを使っていた場合、端末紛失だけで秘密鍵が直ちに流出したとは言えません。一方、同期アカウントを乗っ取られた疑いがあれば、同期先の端末や資格情報を含めて影響を評価します。失効対象を誤ると、正当な利用者だけが締め出されたり、攻撃者の認証器だけ残ったりします。
同じパスキー資格情報CR-41が複数端末で使われる場合、RPでCR-41を失効すると、その資格情報の全コピーはこのRPで認証できません。RPのcredential IDだけでは、同じ資格情報を使った特定の端末だけを選んで失効できません。安全な別端末でもCR-41が使えなくなるため、新しいCR-42の利用を先に確認します。
同期サービスでの紛失端末の解除・遠隔消去、RPでの資格情報失効、アプリの既存セッション失効は別の操作です。同期サービスから端末を外しても、既に複製された鍵が消えたとは断定できません。侵害範囲と利用可能な別の認証器を確認し、それぞれの失効と再登録を記録します。
登録済み認証器の一覧は、credential ID、登録時刻、登録取引、利用者ID、最終利用、必要に応じてBE・BSやattestation方針を追えるようにします。管理画面で付けた『Aのスマホ』という表示名だけを機器の証明として扱いません。
7. 封じ込めから再開までに確認する
この事例では、パスワード漏えいと不正な回復申請が疑われます。担当者は未承認のPush要求を失効させ、関連するログインを保留し、Aに別経路で連絡します。パスワードを変更し、セッションと新規認証器登録履歴を調べます。Aが否認したRC-41から新しい鍵が登録されていないことを確認します。
既に不審なセッションが作られた場合は、その作成方式、権限、操作履歴、追加された認証器、回復先変更を調べ、該当セッションと認証器を失効します。振込先などの業務データ変更があれば担当部門と是正します。MFAの設定を強くしても、既存の不正セッションが残れば問題は解消しません。
再開時は、Aの正当な認証器でのログイン、Push疲労の抑制、TOTP再利用拒否、WebAuthnのchallenge・origin・署名検証、回復申請の保留と通知を試します。管理者アカウントが再び弱い方式だけで入れる状態になっていないかも確認します。失敗ログが静かになっただけでは復旧完了と判断しません。
試験の記述では、攻撃成立の前提、認証サーバで検証した値、監査ログが示す事実、本人確認に足りない証拠、復旧後の再開条件を順に書きます。『MFAがあるので侵入不能』『署名成功なので本人の意思を確認済み』のような一段飛ばしの結論を避けます。
8. 科目B（午後）の記述演習
各問は条件、問い、解答、誤答の理由を分けています。時刻・取引ID・方式を対応させて答えてください。
演習1：TOTPの再利用
条件：09:05:15にT-41のコードが成功し、09:05:17に同じステップのコードが再送された。問い：二回目の処理と理由を答える。
解答：二回目は拒否します。同じ30秒幅では計算上同じコードになっても、成功済みコードを再利用できないよう記録します。接続元と取引IDを調べ、単なる再送か不正試行かを切り分けます。
誤答の理由：『30秒以内なので再度受理する』は、TOTPの時間幅と一回限りの利用条件を混同しています。
演習2：Pushの連続通知
条件：L-71ではパスワードが通り、P-71～P-73が短時間に発行され、P-73だけdenyが記録された。問い：確定できることと追加調査を答える。
解答：P-73は拒否され、L-71のセッションは作られていません。他の要求の状態、関連ログイン、利用端末、Aへの連絡結果を調べます。頻度制限と未承認要求の失効を行います。
誤答の理由：『一件denyだから全要求は拒否された』はP-71・P-72の結果を見ていません。
演習3：番号一致の限界
条件：Push要求の番号一致が成功したが、利用者は偽のログイン画面で番号を見て入力していた。問い：耐フィッシング性と調査対象を答える。
解答：番号一致は誤承認を減らしますが、偽サイトから本物の取引へ番号を中継され得ます。要求ID、実際のログイン元、端末、承認内容、後続セッションを照合します。
誤答の理由：『番号が合ったので正規サイトを確認済み』は、番号が表示されたサイトの真正性を確認していません。
演習4：WebAuthnの別origin
条件：W-43はchallengeと署名が有効だが、originがhttps://other.exampleだった。問い：受理可否と検証値を答える。
解答：受理しません。RPは期待したorigin、rpIdHash、登録済みcredential ID、challenge、署名、必要なUVを検証します。この別originの応答は模擬例で、実際のブラウザでは到達前に止まる場合もあります。
誤答の理由：『署名が有効なら受理』は認証応答がどのサイトの取引へ結び付いたかを見落とします。
演習5：UPとUV
条件：W-44はUP=1、UV=0で、RPはuserVerification=requiredとした。問い：処理と理由を答える。
解答：拒否します。UPは操作があったことを示しますが、方針で要求したUVの成立は示しません。認証器設定と要求・応答を確認します。
誤答の理由：『鍵に触れたので本人確認済み』はUPとUVの違いを無視しています。
演習6：同期型パスキーのsignCount
条件：CR-41はBE=1、BS=1、signCount=0で、署名と他の条件は正常だった。問い：複製・拒否について何が言えるか。
解答：0だけで複製や侵害は断定できません。同期型資格情報ではカウンタが増えない場合もあります。RPの方針、過去値、端末追加、同期アカウントの状況を確認します。
誤答の理由：『0なので偽の鍵』は、認証器のカウンタ実装と同期型の特性を見ていません。
演習7：不正な回復申請
条件：RC-41はパスワードだけ成功し、回復コード・別経路確認がないまま新しいパスキー登録を要求した。問い：対応と調査を答える。
解答：登録を保留し、既存の連絡先へ通知してAを確認します。回復要求、既存セッション、新しい認証器登録履歴を調べ、否認があれば申請を拒否してパスワード漏えいへ対処します。
誤答の理由：『パスワードを知っているので本人』は、漏えいした一次要素だけで新しい認証器を登録させます。
演習8：再開条件
条件：漏えいパスワードを変更し、Push通知は止まったが、攻撃者が登録した可能性のある認証器と既存セッションを調べていない。問い：再開前に必要な確認を答える。
解答：全登録済み認証器、回復先、セッション、権限操作を調べ、不正なものを失効します。Aの正当な方法でのログインと不正要求の拒否を試し、通知と監視が機能することを確認します。
誤答の理由：『通知が止まれば復旧』では、不正に登録された鍵や既存セッションを残す可能性があります。
9. 仕様と実装ガイド
この記事についてAIに深掘り質問する
ChatGPT、Claude、Perplexityにこの記事を参照させ、要点の確認や疑問点を自由に質問できます。
次におすすめの学習
編集・検証について
編集・検証：IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る