メインコンテンツへスキップ
ブログ一覧に戻る
Web制作・運用

二段階認証があるのにフィッシングが防げない理由|NIST基準で見分ける

2026年9月17日
最終更新: 2026年10月8日
5分で読めます

この記事でわかること

NIST SP 800-63-4の認証器要件を基準に、二段階認証の数ではなくフィッシング耐性と復旧経路を点検します。パスワード・SMSなどの帯域外・OTP、追加要件付きの暗号認証、同期可能な認証器の扱いを分け、パスキー導入を安全性の保証へ短絡しない確認手順を示します。方式の強弱だけで結論を急がないための案内です。

2026年10月8日にNIST SP 800-63Bの現行本文を再確認した。認証強度は要素の数だけでなく、秘密の種類、フィッシング耐性、リプレイ耐性、認証器の拘束、回復手順で評価する。パスキー等の公開鍵認証を導入しても、登録・端末変更・紛失・回復、アカウント復旧、セッション失効、管理者権限の設計が残る。「二段階」表示やSMS採用だけでフィッシングが防げると表現しない。

30秒で要点

二段階認証の表示は、フィッシング耐性の強さをそのまま表しません。認証器の方式、暗号による結び付き、同期、アカウント復旧を別の経路として点検します。

  • NIST SP 800-63-4の認証器要件では、パスワード、ルックアップシークレット、帯域外認証、OTPはフィッシング耐性を持たない
  • フィッシング耐性には暗号認証が必要で、手入力のOTPや帯域外コードだけでは該当しない
  • 暗号認証でも、同期可能な認証器には追加要件がある
  • 通常のログインを強くしても、パスワード再設定や管理者解除が弱ければ攻撃者はそこを使える
認証方式をフィッシング耐性、暗号、同期、復旧の条件に分けて読む図解
要素の数ではなく、認証器と復旧経路の最弱点を別々に確認する。

1. 2026年10月7日に確認したNISTの基準

NIST SP 800-63-4の認証器要件は、認証器ごとにフィッシング耐性の有無と必要条件を説明しています。ここで重要なのは、二つの要素を組み合わせたかではなく、攻撃者が偽の検証者へ利用者を誘導したときに、その認証情報を使えてしまうかという観点です。

表が収まらない場合は、横にスクロールできます

認証器の例NISTの扱い点検する問い
パスワードフィッシング耐性なし偽サイトへ入力できるか
ルックアップシークレットフィッシング耐性なし秘密を再利用できるか
SMSなどの帯域外認証フィッシング耐性なしコードを手入力させるか
OTP認証フィッシング耐性なし偽サイトへコードを渡せるか
暗号認証追加要件を満たす場合に耐性検証者と鍵の結び付きを確認したか

「耐性なし」は、方式に価値がないという意味ではありません。別の脅威を下げることはありますが、フィッシング耐性という評価軸では、暗号認証と同じ欄へ置けないという分類です。

2. パスキーを名前ではなく認証器として見る

パスキーは、公開鍵暗号を用いる認証器として導入されることが多い方式です。しかし、利用者の端末間で鍵を同期する仕組みや、バックアップから復元する仕組みがあると、認証器の管理条件が増えます。NISTは同期可能な認証器に対して、同期ファブリック、鍵の保護、利用者による回復などの追加要件を置いています。

したがって、パスキー導入時に「フィッシング耐性あり」とだけ台帳へ書きません。どの端末で生成され、何が同期され、端末を失ったとき何を使って戻り、利用者が別の方法へ切り替えられるかを記録します。サービス提供者の実装がNISTの条件をどこまで満たすかは、製品仕様と実地テストで確認する範囲です。

3. 最弱の経路は復旧に隠れる

通常のログインをパスキーだけにしても、次の経路が残っていれば攻撃者はそこを狙います。

  • パスワード再設定メールを受け取るだけでログイン方式を変更できる。
  • サポート窓口へ名前と誕生日を伝えるだけで認証器を解除できる。
  • 管理者が本人確認なしで二段階認証を無効化できる。
  • 休眠端末や古いブラウザに残ったセッションを取り消せない。

これらはNISTの認証器分類だけから安全性を断定できない、組織固有の復旧設計です。通常ログインと同じ深さで、復旧・緊急解除・セッション失効を一覧にします。

4. 運用で確認する四つの境界

認証器を選ぶときは、次の表を導入前と変更後に埋めます。

表が収まらない場合は、横にスクロールできます

境界確認すること残す証拠
方式パスワード、OTP、暗号認証の分類NIST要件と製品仕様
鍵検証者へ結び付く鍵と端末の管理登録・失効・端末交換の記録
同期同期範囲、保護、復元の条件同期サービスの設定とテスト
復旧代替ログイン、サポート解除、セッション失効手順、承認者、演習結果

「MFA有効」という一つのダッシュボード表示で済ませず、弱い経路の発見と停止を別の作業にします。設定変更のたびに、攻撃者が選べる経路が増えていないかを確認します。

5. 最小の検証シナリオ

  1. 普段のログイン、パスワード再設定、端末紛失、管理者解除を経路図にする。
  2. 各経路で、偽サイトへ入力できる秘密やコードがあるかを分類する。
  3. 暗号認証の登録・失効・同期・端末交換を、テストアカウントで実行する。
  4. 復旧担当者が本人確認を省略できないか、監査ログで確認する。
  5. 方式、実装、復旧、利用者体験の問題を別々の担当へ返す。

NISTの分類は、採用する認証器のフィッシング耐性を読む土台です。安全性を保証するラベルに置き換えず、同期と復旧を含む全経路で、誰がどの証拠をもって変更を認めるかを決めます。

よくある質問(FAQ)