フィッシング耐性のある多要素認証とは：定義と、SMS やワンタイムパスワードとの違い

フィッシング耐性のある多要素認証とは、利用者が偽サイトにだまされても、認証の秘密や有効な認証の結果が攻撃者に渡らない多要素認証です。NIST SP 800-63B-4 は、認証の出力を正しい検証者の名前 (ドメイン) に結び付ける方式などをこれにあたるとし、WebAuthn をその例に挙げています。利用者が画面に打ち込む SMS やアプリのワンタイムパスワードは、偽サイトにそのまま入力できるため、フィッシング耐性があるとはみなされません。日本でも、日本証券業協会が 2025 年 10 月に、ログインなどの重要な操作でフィッシング耐性のある多要素認証を必須とするガイドラインの改正を施行しています。

定義

NIST SP 800-63B-4 は、フィッシング耐性を「認証プロトコルが、認証の秘密や有効な認証器の出力を、検証者になりすました相手に渡さない能力」と定義しています。実現の方法として挙げているのは 2 つです。

• チャネルへの結び付け (channel binding): 認証器の出力を、通信のチャネルの識別子に暗号的に結び付ける
• 検証者の名前への結び付け (verifier name binding): 認証器の出力を、プロトコルの中で認証された検証者の識別子 (ドメイン名など) に暗号的に結び付ける

後者について NIST は、FIDO2 の認証器が使う WebAuthn を、検証者の認証されたドメイン名にもとづいて認証の秘密を選ぶことでフィッシング耐性を実現する標準の例として挙げています。

反対に、同じ文書は、ワンタイムパスワードや別経路のコードのように利用者が認証の出力を手で入力する方式は、フィッシング耐性があるとみなしてはならない、としています。手で入力すると、その出力が認証中のセッションに結び付かないためです。

ワンタイムパスワードはなぜ破られるのか

偽サイトを使った典型的な流れは次のとおりです。

1. 利用者が偽のログイン画面を開き、ID とパスワードを入れる
2. 攻撃者がそれを本物のサイトに転送する
3. 本物のサイトが SMS やアプリでワンタイムパスワードを求める
4. 偽サイトも同じ入力欄を出し、利用者がコードを入れる
5. 攻撃者がそのコードを本物のサイトに入れ、ログインが成立する

コードは数十秒から数分しか有効でなくても、攻撃者が自動で中継すれば間に合います。CISA の文書も、偽のログイン画面で利用者名とパスワード、認証アプリの 6 桁のコードを入力させる手口を例に挙げています。

パスキーでは、この 4 の段階が成立しません。ブラウザは偽サイトのドメインを確かめ、認証器は偽サイトの RP ID 向けの鍵を持っていないため、本物のサイト向けの署名は作られません。利用者が転記できる文字列も最初からありません。

方式ごとの位置付け

CISA は 2022 年 10 月のファクトシートで、多要素認証を強いものから順に次のように並べています。

CISA は、フィッシング耐性のある多要素認証を「多要素認証の最高水準 (gold standard)」と呼び、広く使えるフィッシング耐性のある認証は FIDO / WebAuthn だけだとしています (2022 年の時点)。そのうえで、すぐに移れない中小規模の組織には、アプリやトークンのワンタイムパスワード、番号の一致を伴うプッシュ通知が最善の選択肢だとしています。また、どの多要素認証も無いよりは良いとしています。

パスキーは「多要素」なのか

パスキーは 1 回の操作で終わるので、多要素に見えないかもしれません。FIDO Alliance は、パスキーは利用者の端末に置かれ (持っているもの)、RP が利用者の確認 (User Verification) を求めた場合は、生体認証か PIN (本人の特徴か、知っていること) でしか使えない、と説明しています。つまり、サーバーが利用者の確認を求め、その結果を確かめていれば、1 回の操作で 2 つの要素を満たします。

サーバー側で確かめられるのは、認証器のデータにある UV (User Verified) のフラグです。WebAuthn の userVerification を required にすれば、利用者の確認が無い認証を受け付けません。preferred の場合は、確認ができない認証器でも通るので、多要素として扱いたい操作では UV のフラグを見て判断します。

ガイドラインでの扱い

NIST SP 800-63B-4 (米国)

2025 年 8 月に改訂版が出た NIST SP 800-63B-4 は、最も高い認証保証レベル (AAL3) でフィッシング耐性のある認証器を求めています。AAL2 でも、サービスの提供者 (CSP) は少なくとも 1 つのフィッシング耐性のある認証器を利用者に提供しなければならない、としています。

CISA (米国)

CISA は、すべての組織にフィッシング耐性のある多要素認証の導入を強く勧め、行政管理予算局 (OMB) が連邦政府の機関にその採用を求めていることにも触れています。

日本証券業協会 (日本)

日本証券業協会は 2025 年 10 月 15 日に「インターネット取引における不正アクセス等防止に向けたガイドライン」の改正を施行しました。ログイン時・出金時・出金先銀行口座の変更時などの重要な操作で、フィッシングに耐性のある多要素認証 (例: パスキーによる認証、PKI をベースとした認証) を実装し、必須化 (既定の設定) するとしています。必要な機器を持たないなどの理由で設定を解除する顧客には代替の多要素認証を提供し、解除の割合を追って下げていくことも求めています。

入れた後に残る穴

フィッシング耐性のある方式を足しても、ほかの入口が弱ければ、攻撃者はそちらを使います。

• 代替手段: パスキーのほかに SMS のコードでもログインできるなら、攻撃者は SMS の画面に誘導します。重要な操作ほど、代替手段を絞ります。
• 登録の入口: 盗んだパスワードで入った攻撃者が自分のパスキーを登録できれば、以後は正規の利用者と区別がつきません。登録の前に既存の多要素認証や再認証を求めます。
• 復旧の入口: メールのリンクだけでパスキーを登録し直せるなら、メールの乗っ取りで突破されます。
• ログイン後のセッション: フィッシング耐性は認証の時点の性質です。ログインの後に発行したセッションの Cookie を盗まれた場合は守れません。重要な操作の前の再認証や、セッションの管理と組み合わせます。

導入の進め方

1. パスキーを、既存の多要素認証に加わる選択肢として提供する
2. ログイン・出金・連絡先の変更など、重要な操作の前の再認証をパスキーで行えるようにする
3. パスキーを登録した利用者には、弱い代替手段を既定で出さない
4. パスキーを使えない利用者の割合を追い、代替手段を減らしていく

SealGate で実装する場合

SealGate は、既存のログインにパスキー (FIDO2 / WebAuthn) を足す API です。フィッシング耐性に関わる設定と値は次のとおりです。

• 環境の設定で、パスキーの RP ID と、登録とログインを受け付けるオリジンを決めます。許可していないオリジンからの応答は検証で断られ、403 (origin_not_allowed) になります。
• user_verification を required にすると、生体認証や PIN で利用者の確認をしていない登録とログインを verification_failed で拒否します (既定は preferred)。API キーからは PATCH /v1/apps/{app_id} で変えられます。
• POST /v1/login/verify の応答には user_verified が入るので、preferred のまま運用する場合も、重要な操作の前ではこの値で判断できます。
• 既にパスキーを持つ利用者への追加の登録には、signed_in: true か recovery_token が要ります。復旧トークンは、開発者側で本人確認をした後に発行します。

詳しくは ドキュメント をご覧ください。

よくある質問

SMS 認証は使わない方がよいのですか？

CISA も、どの多要素認証も無いよりは良いとしています。ただしフィッシング耐性は無いので、パスキーを使える利用者にはパスキーを既定にし、SMS は代替として残すかどうかを用途で決めます。

パスキーは 1 つの要素ではないのですか？

FIDO Alliance は、パスキーは端末 (持っているもの) に置かれ、利用者の確認を求めた場合は生体認証か PIN でしか使えないと説明しています。サーバーが利用者の確認を求めて結果を確かめれば、多要素として扱えます。

証券会社以外もガイドラインの対象ですか？

日本証券業協会のガイドラインは協会員の証券会社のインターネット取引が対象です。他の業種の義務ではありませんが、どの方式をフィッシング耐性があるとみなすかの例として参考になります。

出典

• NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management（NIST, 2025-08）
• Implementing Phishing-Resistant MFA（CISA, 2022-10）
• 「インターネット取引における不正アクセス等防止に向けたガイドライン」の改正について（日本証券業協会, 2025-10-15）
• Passkeys（FIDO Alliance）
• Web Authentication: An API for accessing Public Key Credentials Level 3（W3C Recommendation, 2026-08-25）