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

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

「二段階認証は入れてあるので大丈夫です」と説明した数か月後に、そのアカウントが乗っ取られる。情シス専任がいない小規模な組織で、こうした相談が後を絶ちません。担当者に話を聞くと、たしかにSMSでのコード送信やOTP(ワンタイムパスワード)アプリは導入済みです。それでも被害は起きています。

原因は、多要素認証(MFA)の考え方そのものを取り違えていることにある場合が少なくありません。MFAは「要素をいくつ足したか」で評価するものではなく、「一番弱い経路がどれか」で評価するものです。この記事では、その基準をNIST(米国国立標準技術研究所)のガイドラインに沿って整理します。

30秒で要点

• 米国NISTのガイドライン(SP 800-63B)は、パスワード・ルックアップシークレット・SMSなどの帯域外認証・OTP認証のすべてを「フィッシング耐性なし」に分類している
• フィッシング耐性があると分類されるのは、追加要件を満たす暗号認証(パスキーなど)のみ
• パスキーの中でも、複数端末で鍵を同期する「同期可能な認証器」には別途の追加要件が課されている
• 実務でつまずきやすいのは「弱い経路を残したまま要素を足す」「復旧経路を見ていない」「同期型と端末固定型を区別していない」の3点

MFAを「要素の数」で考えると見落とすもの

多要素認証という言葉は、「知識情報(パスワード)」「所持情報(スマホ)」「生体情報(指紋)」のうち2つ以上を組み合わせることを指すのが一般的な理解です。この理解自体は間違っていません。問題は、要素を足すこと自体が目的化してしまい、その要素それぞれの質を確認しないまま「MFAを導入した」で思考が止まってしまうことです。

パスワード(知識情報)とSMSでのコード受信(所持情報の一種として扱われることが多い)を組み合わせれば、要素数としては2つになります。しかし、攻撃者が本物そっくりの偽サイトを用意し、そこにパスワードとSMSコードの両方を入力させてしまえば、要素が2つあっても攻撃は成立します。これが「要素の数と、フィッシングへの耐性は別の軸である」という核心です。

NISTはどの方式を「フィッシング耐性なし」としているか

ここからは、実際に一次情報で確認できた内容です。米国NISTが定めるデジタルアイデンティティに関するガイドライン(SP 800-63B)は、認証方式ごとにフィッシング耐性の有無を明示しています。

確認できたのは次の分類です。

ガイドラインの本文には、"Passwords are not phishing-resistant."(パスワードはフィッシング耐性を持たない)、"OTP authentication is not phishing-resistant."(OTP認証はフィッシング耐性を持たない)といった記述が並びます。フィッシング耐性を持つとされるのは、"Cryptographic authentication is phishing-resistant if it meets the additional requirements"(暗号認証は、追加要件を満たす場合にフィッシング耐性を持つ)と条件付きで説明されている方式だけです。

確かなこと：NIST SP 800-63Bが、パスワード・ルックアップシークレット・帯域外認証・OTP認証をいずれも「フィッシング耐性なし」に分類していることは、ガイドライン本文で直接確認できました。

まだ確かではないこと：このページ自体には発行年月日や版数の確定的な表示が見当たりませんでした。ガイドラインは改定が続く文書のため、実務で参照する際は必ずNISTの公式ページで最新の記載を確認することをおすすめします。

「禁止」ではなく「分類」であることに注意する

ここで誤読しやすいのが、「NISTがSMS認証やOTPの使用を禁止した」という理解です。ガイドラインが示しているのは禁止ではなく分類です。SMSやOTPは、何も対策していない状態に比べれば明らかに安全性を高めます。ただし「フィッシング耐性がある」という水準では評価されていない、という位置づけです。何を守りたいか(フィッシングによるアカウント乗っ取りを防ぎたいのか、単純な総当たり攻撃を防ぎたいのか)によって、必要な水準は変わります。

フィッシング耐性を持つとされる方式：パスキー

フィッシング耐性があると位置づけられる代表例が、パスキーです。パスキーを推進する業界団体であるFIDO Allianceは、自社サイトで「パスキーはフィッシング耐性があり、設計上安全(phishing resistant and secure by design)」と説明しています。パスキーは、FIDO Allianceが開発したFIDO2という公開認証標準に基づく仕組みです。

ただし、ここで見落とされやすい論点があります。NISTのガイドラインは、鍵をクラウドなどの「sync fabric」を通じて複数端末に複製できる「同期可能な認証器(syncable authenticators)」について、追加の要件を課していることが確認できました。つまり、同じ「パスキー」という名前がついていても、1台の端末に固定された認証器と、複数端末で同期される認証器とでは、NISTの基準上の扱いが異なります。同期型の追加要件の具体的な中身までは今回の情報源からは確認できていないため、導入を検討する際は、利用予定のサービスがどちらの方式かを提供元に確認することをおすすめします。

前提知識について：認証と認可の基本的な違いから知りたい場合は、認証と認可入門を先に読むと理解しやすくなります。実装寄りの選択肢(NextAuth.jsやSupabase Authなど)を比較したい場合は、モダンWebアプリケーションにおける認証入門を参照してください。

なぜ「要素を足したのに防げなかった」が起きるのか

ここまでの内容を踏まえると、冒頭の相談で起きていたことが見えてきます。多くの場合、次の3つの取り違えのどれかが起きています。

1. 足しただけで、弱い経路を残している：パスワードにSMS認証を足しても、両方とも「フィッシング耐性なし」に分類される方式どうしの組み合わせです。要素は2つに増えていますが、フィッシング耐性という観点では強度が上がっていません。
2. 復旧経路を見ていない：ログイン画面そのものは強化していても、「パスワードを忘れた場合」の再設定経路がメール一本で完結していれば、攻撃者はそちらを狙います。ログインできる経路は1つではなく、通常のログインと復旧経路の両方があることを見落としがちです。
3. 同期型と端末固定型のパスキーを区別していない：「パスキーを導入した」という言葉だけでは、NISTの基準上どちらの強度なのかが分かりません。

これらはいずれも、「MFAを入れたか」という二値ではなく、「ログインできる経路をすべて洗い出したとき、最も弱い経路はどれか」という観点で評価することで防げる取り違えです。要素を1つ強化しても、別の経路が弱いままなら、攻撃者はその弱い経路を通過します。

自分でも試せる、最小の検証

今使っているサービス(社内システム、契約しているSaaSなど)を1つ選び、そのアカウントに「ログインできる経路」を思いつく限りすべて書き出してみてください。通常のログインだけでなく、パスワードを忘れた場合の再設定、管理者による代理ログイン、外部サービス連携用に発行しているアクセスキーなども含めます。書き出した経路それぞれについて、上記の表を使って「フィッシング耐性あり」「なし」を仮に当てはめてみると、どの経路が最弱かが見えてきます。この棚卸しに、専門的な診断ツールは必要ありません。

判断の土台として押さえておくこと

• MFAは要素の数ではなく、経路ごとのフィッシング耐性で評価する。NIST SP 800-63Bはパスワード・SMS等の帯域外認証・OTPをいずれも「フィッシング耐性なし」に分類している
• フィッシング耐性があるとされるのは、追加要件を満たす暗号認証(パスキー等)のみ。パスキーの中でも同期型には別の追加要件がある
• 実務での取り違えは「足しただけで弱い経路が残る」「復旧経路を見ていない」「同期型と端末固定型を区別しない」の3点に集約される
• 認証の基礎から整理したい場合は認証と認可入門、実装の選択肢を比較したい場合はモダンWebアプリケーションにおける認証入門を参照する

自社で使っているログイン経路の棚卸しから、何を優先して見直すべきか整理したい場合は、状況を整理するところから始めることができます。

より深く学ぶ

• 認証と認可入門：ログインの裏側にある仕組みの基本
• モダンWebアプリケーションにおける認証入門：実装の選択肢を比較する

参考資料・引用元

• NIST, "Digital Identity Guidelines: Authentication and Authenticator Management (SP 800-63B)", Authenticators. https://pages.nist.gov/800-63-4/sp800-63b/authenticators/
• FIDO Alliance, "Passkeys". https://fidoalliance.org/passkeys/