二つの手順が二つの要素とは限りません。パスワードとPINはいずれも知識要素です。生体認証は認証器を有効化できますが、それだけで匿名性やフィッシング耐性を保証しません。
画面数ではなく仕組みを比較する
NISTは知識、所持、生体的特徴を区別します。手入力のワンタイムコードは偽サイト経由で中継され得るため、SMSやTOTPはフィッシング耐性のある認証と同じではありません。適切なパスキー実装は応答をサービスに結び付けます。保証はローカルでの検証やバックアップ、同期の条件にも左右されます。
生体認証の位置付けを理解する
WebAuthnでは認証器内で生体認識を行うことができ、生体データは受信するウェブサービスに渡されません。ローカルの検証にはPINも使えます。ユーザーの存在確認（UP）とユーザー検証（UV）は異なります。サーバーはプロトコルに従って応答を検証する必要があり、顔認識画面だけでは不十分です。
ライフサイクルを保護する
登録、認証方法の追加、端末紛失、失効、アカウント復旧を計画します。アクセシビリティと代替手段も評価してください。代替経路は主経路を弱めることがあります。認証はデータや操作への権限確認を代替しません。
出典
編集確認日：2026年11月1日。
第二要素認証とフィッシング対策を分離する。
NISTは、手動で入力されたワンタイムコードが偽ページによって転送される可能性があるため、ワンタイムコードが存在するだけではサインインがフィッシング対策になるとは限らないと指摘している。適切に統合されたWebAuthnは、応答を正規のサービスに紐付ける。アカウント復旧はセキュリティを確保するための手段である。
- SMS、コード、またはバイパス可能な承認を受け付けているアプリケーションをリストアップし、特権アカウントを優先する。
- 実際のユーザー体験を通して、登録、デバイス紛失、および登録取り消しをテストする。
- 耐性因子のカバレッジを測定し、例外の日付を所有者に記録します。
一次資料：NIST SP 800-63B-4. 関連する方法：実践ガイドを読む.
パスキー：ドメインとRP IDの変更を準備する
アカウント、ウェブのオリジン、RP IDを分け、認証情報を黙って付け替えない移行を計画します。
- 旧・新のオリジン、RP ID、対応するアカウントを記録します。同じアカウント名でもパスキーが別のRP IDに有効になるわけではありません。WebAuthnの許される組合せと移行中のログイン経路を確認します。
- 許可されたテスト環境で適切なライブラリを使い、チャレンジ、オリジン、RP ID、アカウントの関連付けを確認します。想定外のオリジンとチャレンジの再利用を試します。RP IDが変わる場合は認証済みの新規登録を準備し、行のコピーを鍵の移行と扱いません。
- 旧認証情報だけを持つ利用者、復旧、既存セッションを試します。確認した戻し方とともに経路の開設・廃止順を決めます。新ドメインでの登録成功は全旧セッションの失効を証明しません。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}期待される判断
架空例：アカウントは同じでもold.exampleから別のRP IDのnew.exampleへ移ります。旧認証情報を黙って付け替えず、新規登録は計画した認証済み経路で行います。
データベースの編集でパスキーのRP IDを変更できますか？
できません。RP IDは認証情報の検証される範囲の一部です。新しい範囲の有効な登録と認証済みのアカウント対応付けを準備します。
一次資料：W3C — Web Authentication Level 2. 関連する方法：実践ガイドを読む.
postMessage：送信元、ウィンドウ、要求を検証する
iframeやポップアップの通信契約で想定外の送信者とデータを拒否します。
- 許可する正確なorigin、期待するウィンドウ参照、必要な型を記録します。機密データには明確なtargetOriginを使います。originは方式、ホスト、ポートを含み、ドメインの部分文字列では相手を確認できません。
- event.originと、この連携ではevent.sourceを期待するウィンドウと比較します。構造、許可値、処理状態を確認し、evalやHTML挿入をせずデータとして扱います。許可originもサーバー側の権限確認を代替しません。
- 類似ドメイン、別ポート、同じoriginの別ウィンドウ、不正な項目、終了後のメッセージを試します。不要なリスナーを削除し、終了した通信を無効化します。移動後も返信先は事前承認したoriginに限定します。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"allowed_origin": "https://widget.example",
"observed_origin": "https://widget.example",
"expected_window": "active_iframe",
"observed_window": "another_window",
"payload_schema_valid": true,
"expected": "reject_without_effect"
}期待される判断
架空例：https://widget.exampleは許可済みですがevent.sourceは別ウィンドウです。契約は有効なiframeを要求します。命令を出さず拒否します。
一次資料：MDN — Window.postMessage. 関連する方法：実践ガイドを読む.
ID：認証要素、セッション、復旧
二要素認証：画面だけでなくプロトコルを確認
入力コード、プッシュ承認、WebAuthn応答ではサービスへの結び付きが異なります。生体認証は認証器を有効化できますが、応答の暗号学的検証を代替しません。
- ローカルで有効化 — 認証器に応じたPINまたは生体認証。
- 応答に署名 — サービスの鍵と受信したチャレンジ。
- サーバーで検証 — チャレンジ、オリジン、署名、フラグ。
- 操作を認可 — 対象と操作に対する権限。
- UPとUVを別々に確認する。
- 必要な同期条件と鍵のエクスポート制限を確認する。
- 既存セッションからの紛失対応と認証方法追加を試す。
出典確認日 · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3
拡張機能：権限とアクセス
この言語版の詳しい参照メモは英語で提供しています。
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent