インターネット上のサービスを利用する際、パスワードの入力だけでは不正ログインを防ぎきれない被害が増加しています。漏洩したパスワードリストによる総当たり攻撃や、巧妙な偽サイトによる詐取が日常化しているためです。この課題に対応するため、多くのサービスで「二要素認証」や「2段階認証」の導入が進んでいます。

しかし、「2段階認証を設定していれば絶対に安全」「二要素認証と2段階認証は呼び名が違うだけで同じもの」といった誤解も少なくありません。両者の本質的な違いは「認証に用いる要素(情報の種類)の数」にあります。二要素認証は異なる性質の要素を組み合わせることで、万一パスワードが漏洩してもアカウントへの侵入を大幅に難しくする技術です。

本記事では、二要素認証の仕組みと2段階認証との違い、SMSや認証アプリ(TOTP)の動作原理、中継型フィッシングに対するWebAuthn(パスキー)の防御構造、端末紛失時の安全な復旧手順までを分かりやすく解説します。

---

二要素認証と2段階認証の違い:要素の種類と操作の段階

セキュリティ設定画面で頻繁に見かける「二要素認証(2FA)」と「2段階認証」は、似た文脈で使われますが、セキュリティ技術としては異なる概念を指しています。

認証の3大要素と二要素認証の定義

二要素認証(2FA: Two-Factor Authentication)や多要素認証(MFA: Multi-Factor Authentication)を理解する基礎となるのが、認証に用いる「要素(ファクタ)」の分類です。国際的なセキュリティ標準やガイドラインでは、認証要素は主に次の3つに分類されます。

INTERACTIVE

実際に動かして確かめる

条件や数値を変え、本文で説明した関係を確認できます。
表示値は仕組みを理解するための学習用モデルです。大きな画面で使う
  1. 知識情報(Something you know):本人のみが「知っている」情報。パスワード、PINコード、秘密の質問の答えなどが該当します。
  2. 所持情報(Something you have):本人のみが「持っている」物理的または論理的な物。スマートフォン、SMSを受信する携帯電話、ハードウェアセキュリティキー、認証アプリが生成するワンタイムパスワードなどが該当します。
  3. 生体情報(Something you are):本人の身体的・行動的特徴。「指紋」「顔」「虹彩」などの生体特徴が該当します。

二要素認証とは、これら3つのカテゴリーから「異なる2つの要素」を組み合わせて本人を確認する認証方式です。肝心なのは「異なるカテゴリーを跨いでいるか」という点です。例えば、第1のパスワードを入力した後に合言葉などの第2パスワードを入力させる仕組みは、2回確認していてもどちらも「知識情報」であるため、二要素認証ではなく「一要素認証」に留まります。

二要素認証(多要素認証)は、知識、所持、生体という異なる性質の認証要素を組み合わせることで、パスワード等の単一要素が漏洩・侵害された場合の不正ログインを難しくし、アカウントの防御力を高める仕組みです。攻撃者がパスワードを手に入れても、別の要素を同時に侵害できなければ不正ログインを成立させられません。

「段階(ステップ)」と「要素(ファクタ)」の混同を解く

一方、「2段階認証(Two-Step Verification)」は、認証の手続きが「2回の段階(ステップ)に分かれていること」を意味します。つまり、要素の種類ではなく「操作の回数」に着目した呼称です。

IDとパスワードの入力後にスマートフォンへ届いた確認コードを入力する手順が多いため、二要素認証と2段階認証は混同されがちですが、両者は単純な包含関係ではありません。

  • 2段階だが一要素認証の例:IDとパスワードを入力した後に、あらかじめ設定した「秘密の質問の答え」を入力させる方式。操作は2段階ですが、どちらも「知識情報」であるため一要素の2段階認証です。
  • 1段階だが二要素(多要素)認証の例:FIDOセキュリティキーなどのマルチファクタ認証器を用いた認証。端末に差し込んだ物理キー(所持)に指を置き、指紋照合(生体)やPIN入力(知識)を1回の操作で同時に完了させる場合、利用者の操作段階は1回(1ステップ)ですが、内部では複数要素が確認されているため二要素認証が成立します。

サービス画面に表示される「2段階認証」という言葉は、一般の利用者に操作の流れを直感的に伝えるための呼称にすぎない場合が多く見られます。画面の表示名だけで安全性を判断せず、実際に「何種類の異なる要素が組み合わされているか」を見極めることが重要です。

防御の目的と過信の排除

二要素認証の役割は、パスワード単体の漏洩時にアカウントを保護することです。しかし、「手元の機器を持っていれば絶対に侵入されない」「実物の端末がなければ攻撃者は侵入できない」といった絶対的な保証ではありません。

後述するように、通信をリアルタイムに中継する特殊なフィッシング攻撃、利用者の端末自体のマルウェア感染、ログイン成立後のセッション情報の奪取など、二要素認証単独では防ぎきれない攻撃経路も存在します。二要素認証は強固な防御壁ですが、あらゆる攻撃に対する完全な無敵化を保証するものではないという前提を理解しておく必要があります。

---

代表的な方式の仕組み:SMS認証とTOTP認証アプリ

現在普及している二要素認証の多くは、第1要素の「パスワード(知識)」に、第2要素の「手元の機器(所持)」を組み合わせる方式です。代表例である「SMS認証」と「TOTP認証アプリ」の仕組みを解説します。

1. SMS認証(帯域外認証)の仕組み

SMS認証は、ログイン要求時に携帯電話会社の通信網(電話回線網)を経由して登録電話番号宛てに一時コードを送信する方式です。Webの通信経路(インターネット)とは異なる経路を用いるため、技術的には「帯域外認証(Out-of-Band Authentication)」と呼ばれます。

IDとパスワードを入力すると、サーバーから電話番号へ数分間有効な確認コードが届き、それを利用者が画面に入力して一致を確認します。専用アプリが不要で電話番号さえあれば誰でも利用できる容易さが利点です。

ただし、セキュリティ上の前提条件には注意が必要です。SMS認証が客観的に検証しているのは「指定された電話番号宛てにメッセージが到達したこと(電話番号到達性)」であり、利用者が物理的なSIMカードや端末を手元に所持していること自体を暗号学的に証明しているわけではありません。窓口で虚偽申請を行い他人の電話番号のSIMを再発行させる「SIMスワップ(SIMハイジャック)」や電話網の脆弱性を突いた盗聴リスクが存在するため、米国の公的標準ガイドライン(NIST SP 800-63B-4)でも、より強固な代替手段がある場合は段階的な見直しが推奨されています。

2. 認証アプリ(TOTP生成器)の仕組み

Google AuthenticatorやMicrosoft Authenticatorなどの認証アプリは、インターネット標準仕様「RFC 6238」で定められた「TOTP(Time-based One-Time Password:時間基準ワンタイムパスワード)」アルゴリズムに基づき動作します。

  • 動作原理と初期設定:サーバーとアプリの間で事前に「共通秘密鍵(共有シークレット)」を共有します。初期設定で画面のQRコードをカメラで読み取る作業は、この共通秘密鍵を端末内に取り込む手段の一例です。
  • コード生成の計算式:認証アプリは端末内に保管された「共通秘密鍵」と、端末の時計が示す「現在の時刻(Unix時間)」の2つの情報を用います。時刻を一定幅(一般には30秒間)で区切り、その時間ステップと秘密鍵をハッシュ関数に入力して不可逆な計算を行い、一般に6桁の一時コードを生成します。
  • オフライン動作と検証窓:TOTPはコード生成時にインターネット通信を行いません(完全オフライン)。電波の届かない地下や機内でも自律的にコードを生成できます。サーバー側でも同じ秘密鍵と時計を用いて計算し、入力されたコードと照合します。端末とサーバー間の時計のわずかなズレ(クロックスキュー)を考慮し、サーバー側には現時刻の前後数ステップ(例: 前後30秒)のコードを受け入れる「検証窓(許容範囲)」が設けられています。

3. プッシュ通知と数値一致(ナンバーマッチング)

スマートフォンに「ログインを承認しますか?」と通知して「はい」をタップさせるプッシュ通知方式も普及しています。しかし、攻撃者が深夜などに大量の通知を連続送信し、被害者が煩わしさから反射的に「承認」を押してしまう「MFA疲労攻撃」が問題視されるようになりました。

その対策として導入されているのが「数値一致(Number Matching)」です。ログイン画面に表示された数字を認証アプリ側に入力(または選択)させることで、無意識の誤承認を大幅に減らす設計となっています。ただし、これは反射的な誤承認を防ぐ工夫であり、次節で解説する通信中継型の攻撃そのものを防ぐ技術ではありません。

---

なぜ従来の方式は「中継型フィッシング」を防げないのか

SMS認証やTOTP認証アプリはパスワード漏洩への有力な対策ですが、現代の巧妙なフィッシング攻撃に対しては構造的な弱点を抱えています。

リアルタイム中継型(リバースプロキシ型)攻撃の手口

従来のフィッシングは、固定の偽サイトでIDとパスワードを盗み取る手法が中心でした。しかし現在猛威を振るっているのは、攻撃者のサーバーが利用者と正規サーバーの間に入り込み、通信をリアルタイムに仲介する「中継型フィッシング(リバースプロキシ型フィッシング)」です。

  1. 攻撃者は、正規サービスに酷似した偽サイト(例: 正規の example.com に対する login-examp1e.com)を用意し、利用者を誘導します。
  2. 利用者が偽サイトでIDとパスワードを入力すると、攻撃者サーバーはその情報を即座に本物の正規サーバーへ転送します。
  3. 正規サーバーはパスワードの一致を確認し、「二要素認証コードの入力要求」を返します。
  4. 攻撃者サーバーはその要求を利用者の画面に中継し、利用者は手元のスマートフォン(SMSやTOTP)に届いた6桁のコードを偽サイトに入力します。
  5. 攻撃者サーバーは、コードの有効時間内(30秒〜数分以内)にそのコードを正規サーバーへ転送します。
  6. 正規サーバーは正しいコードであると判定してログインを許可し、セッション情報(Cookieなど)を発行します。攻撃者はそのセッション情報を奪い取り、アカウントへ侵入します。

利用者がコードを手入力するSMSなどの帯域外認証やTOTP生成器は、リアルタイム中継型フィッシングに対する耐性を持ちません。一方、ブラウザと認証器が接続先ドメイン(RP ID)を暗号学的に拘束して検証するWebAuthn等の方式はフィッシング耐性を持ちます。

コード手入力方式の本質的な限界とHTTPSの誤解

この攻撃が成立する根本原因は、利用者が数値を視認してブラウザ経由で手入力する仕組みにあります。手入力コードは単なる数字の列であり、接続先のドメイン情報と暗号学的に結びついていません。利用者が誤って偽サイトに入力したコードであっても、有効時間内に本物へ転送されれば正規サーバーは受理してしまいます。

ここで注意すべきなのが「HTTPSの鍵マーク」を巡る誤解です。HTTPS(TLS暗号化)が提供する保証は、「ブラウザと、アドレスバーに表示されている接続先ドメインとの通信が暗号化されていること」および「そのドメインの所有者に正規の証明書が発行されていること」です。

攻撃者が取得した偽ドメイン(login-examp1e.com)であっても、正規の暗号化証明書を無料で取得して鍵マークを表示させることは極めて容易です。鍵マークの存在は「偽サイトとの通信が暗号化されている」ことを意味するにすぎず、接続先が意図した本物のサービスである保証にはなりません。通信の暗号化と、相手が本物であるかの検証は別の問題です。

認証方式の客観的な技術比較

各方式の技術的特徴を整理すると以下の通りです。

認証方式検証の基盤通信依存性入力形態中継型フィッシングへの耐性
SMS認証電話番号到達性電話回線網が必須手入力なし(中継される)
TOTP認証アプリ共通秘密鍵 + 時刻コード生成時は完全オフライン手入力なし(中継される)
WebAuthn(パスキー)公開鍵暗号 + ドメイン拘束インターネット接続自動署名(手入力不要)あり(暗号学的に阻止)

従来の二要素認証が持つ「コードの手入力に起因する中継リスク」を根本から解決するために策定されたのが、WebAuthn規格です。

---

フィッシング耐性を持つ「WebAuthn(パスキー)」の仕組み

WebAuthn(Web Authentication)は、W3CとFIDOアライアンスが策定したオープン規格です(最新仕様は2026年5月26日付 W3C Candidate Recommendation Snapshot「WebAuthn Level 3」)。一般には「パスキー(Passkey)」の名称で普及しています。

WebAuthn Level 3仕様では、認証器が特定のRelying Party向けに作成した公開鍵クレデンシャルを用い、サーバー側でチャレンジ、オリジン、RP ID、認証器データ等を検証することで、秘密鍵を相手サーバーに渡さずに安全な認証を実現します。認証器には単一端末に固定されたものと、保護された同期機構を持つ同期型の双方が存在します。

1. 公開鍵暗号に基づく認証の基本原理

WebAuthnでは、サーバーと端末が同じ秘密を共有しません。

  • 登録時:端末の認証器がサービスごとに固有の「キーペア(秘密鍵と公開鍵)」を生成します。サーバーには「公開鍵」のみを登録し、「秘密鍵」は認証器内の安全なハードウェア領域(Secure EnclaveやTPM等)に保管され、外部へ出力されません。
  • 認証時:サーバーから使い捨て文字列「チャレンジ」を受け取ると、認証器は端末内の秘密鍵で電子署名を作成して返送します。サーバーは登録済みの公開鍵で署名を検証します。秘密鍵がサーバーへ送信されることはなく、サーバー側の公開鍵が漏洩しても秘密鍵は逆算できません。

2. フィッシング耐性の核:「ドメイン(RP ID)の暗号学的拘束」

WebAuthnが中継型フィッシングを防げる理由は、ブラウザが接続先ドメインを署名データへ強制的に結合する構造にあります。

利用者が操作するWebブラウザが、現在のアドレスバーに表示されているドメイン情報(RP ID: Relying Party Identifier)やオリジンを直接取得し、サーバーからのチャレンジとともにクライアントデータ(clientDataJSON)を作成して認証器へ渡します。認証器は秘密鍵を用いて、RP IDを含む認証器データ(authenticatorData)と一体化して電子署名を生成します。

もし利用者が偽サイト(login-examp1e.com)に誘導されてパスキー認証を行おうとしても、ブラウザは「現在の接続先は login-examp1e.com である」と認証器に伝えます。認証器はその偽ドメインに基づいて署名を作成するため、攻撃者がその署名を正規サーバー(example.com)へ転送しても、正規サーバー側でドメイン不一致が暗号学的に判明し、認証は確実に拒否されます。利用者の目視確認に頼らず、機械的な暗号処理によってフィッシングを無力化できる点が決定的な強みです。

3. 図で理解するTOTPとWebAuthnの構造的差異

二要素認証のプロトコル構造と境界の違いを以下の図に示します。

利用者・ブラウザ・認証器・サーバーの境界を、TOTPコードの手入力とWebAuthnのドメインに結びつく署名で対比した模式図。
解説図TOTPの手入力コードは偽サイトに中継され得る。パスキーは認証先ドメインを確認して署名し、秘密鍵と生体情報をサーバーへ送らない。

#### 本図の読み方と設計上の境界 上記図は、「利用者」「Webブラウザ」「認証器(Authenticator)」「ログイン先Webサーバー」の4者の境界と通信経路を明確に分離しています。

  • 左側(TOTP方式の構造):認証器が共通秘密と時刻から生成したワンタイムコードを利用者が画面で読み取り、ブラウザ経由で手動送信します。手入力が介在するため、中間に悪意あるリバースプロキシ(偽サイト)が存在する場合にコードが中継・詐取されるリスク領域が存在します。
  • 右側(WebAuthn / パスキー方式の構造):利用者が行う生体認証(指紋・顔)やPIN入力は、認証器内部で秘密鍵の使用を許可する「アクティベーション」に留まり、生体データや秘密鍵がサーバーへ送信される矢印はありません。ブラウザが提供する接続先ドメイン(RP ID/オリジン)とチャレンジに対し、認証器が署名を作成して検証メタデータ(authenticatorData 等)とともにサーバーへ送信します。パスキーをクラウド同期する場合も、ログイン先サーバーとの通信とは切り離された、同期プロバイダ等の保護された別経路(エンドツーエンド暗号化)として処理されます。

#### 本図が示すモデルの限界 本図は正規の認証プロトコルにおける境界とフィッシング防御の成立条件を整理したものです。したがって、以下の状況までを防げるわけではありません。

  • 利用者の端末自体がOSレベルのマルウェアに感染し、ブラウザの通信や認証器の入出力が乗っ取られている場合。
  • 認証完了後にサーバーからブラウザに発行された「ログインセッション情報(Cookie等)」が、端末内から直接盗まれた場合(セッションハイジャック)。

WebAuthnは認証時のなりすましを強力に防ぎますが、端末の健全性やログイン後のセッション保護までを一律に保証するものではない点に留意が必要です。

---

パスキーと生体認証を巡る誤解:端末固定型と同期型の違い

普及が進むパスキーですが、仕様への誤解から生じる不安も見られます。代表的な2つの誤解と、2つのクレデンシャル形態について整理します。

誤解1:「生体データがWebサービス側に送信・保管される?」

「指紋や顔のデータがWebサイトの運営元に送信され、流出するのではないか」という懸念は完全な誤解です。

パスキー等のWebAuthn実装における生体認証は、生体データそのものをログイン先サーバーへ送信して照合するのではなく、手元の機器内で照合を行い、保管された秘密鍵の使用を許可するアクティベーション要素として機能します。生体情報は統計的・確率的な判定に基づくものであり、パスワードのような秘密情報ではないため、中央サーバーに集約保管する設計は推奨されません。照合は端末内の専用プロセッサで完結し、サーバーへ送られるのは署名データのみです。

誤解2:「物理キーに触れさえすれば二要素認証になる?」

物理セキュリティキー(YubiKeyなど)の金属部分に触れる操作についても、2つの動作モードが厳密に区別されています。

  1. User Presence(UP:存在確認):キーのボタンに触れる操作です。ボットによる自動操作ではなく人間がその場に存在することを確認するものですが、生体を照合しているわけではないため、要素としては「物理キーを持っていること(所持)」の1要素のみを満たします。
  2. User Verification(UV:利用者検証):キーに内蔵された指紋センサーでの照合や、キーのPINコードを入力する操作です。これにより「所持」に加えて「生体」または「知識」が同時に確認され、真の二要素(多要素)認証が成立します。

単にタッチしただけでは要素構成が異なるため、高度な安全性が求められる環境ではサーバー側でUser Verificationを必須とするポリシーが設定されます。

端末固定型と同期型パスキーの違い

WebAuthnで扱われるクレデンシャルには「端末固定型」と「同期型」の2種類があります。

  • 端末固定型(デバイスバウンドクレデンシャル):ハードウェアセキュリティキーや特定端末のTPM内に秘密鍵を生成し、鍵の複製を一切許可しない方式です。耐改ざん性は極めて高いものの、端末やキーを紛失した場合は予備手段がないとログイン不能になります。主に企業の厳格な業務システム等で用いられます。
  • 同期型パスキー(マルチデバイスパスキー):Apple、Google、Microsoft等のアカウント基盤を通じて、利用者の複数デバイス間で秘密鍵を安全に同期する方式です。機種変更時にも自動で引き継がれるため、端末紛失による締め出しリスクを大幅に軽減できます。

同期型パスキーであっても、「認証時に秘密鍵をログイン先サーバーへ渡さない」というWebAuthnの基本原則は完全に維持されます。端末間の鍵の同期は、ログイン先サーバーとの通信とは切り離された、クラウド事業者による保護された別経路(エンドツーエンド暗号化通信)で行われます。

---

端末の紛失や故障にどう備えるか:安全なアカウント復旧

二要素認証の導入における現実的な懸念は、「認証端末を紛失・故障させた場合にアカウントから締め出されないか」という点です。適切な復旧知識と備えが不可欠です。

1. バックアップコードの正しい保管原則

二要素認証の設定時、多くのサービスで8〜10個程度の一時的な「バックアップコード(リカバリーコード)」が提示されます。これは端末が使用不能になった際に1回限り使用できる救済手段です。

最も重要な原則は、「バックアップコードを、認証アプリと同じスマートフォン内に保管しないこと」です。端末のメモ帳や写真フォルダに保存していると、端末の紛失・水没と同時にコードへもアクセスできなくなります。印刷して物理的に保管するか、別系統で保護されたパスワードマネージャーに格納するなど、紛失端末に依存せず独立して安全にアクセスできる場所で管理することが鉄則です。

2. アカウント復旧手続きと予備認証器の確保

バックアップコードがない状態で端末を紛失した場合、各サービスの「アカウント復旧手続き」を利用する必要があります。

復旧手順(登録メールへの再設定リンク送付、身分証提出、サポート審査など)はサービスごとに独立して設計されており、業界で一律のルールはありません。「メールリンクを1回踏めば即座に解除できる」とは限らず、不正乗っ取りを防ぐため数日間の待機期間や厳格な本人確認が課される場合も多く見られます。

突然の締め出しを防ぐ最も確実な対策は、「最初から2つ以上の認証器を登録しておくこと」です。

  • TOTPアプリ:タブレットや予備スマートフォンなど、2台以上の端末で同じ設定QRコードを読み取って並行運用する。
  • パスキー:同期型パスキーを有効化するか、物理セキュリティキーをメイン用と予備用の2本登録しておく。

---

よくある質問(FAQ)

Q1: 公共のパソコンや他人の端末からログインする際、パスキーは使えますか?

利用可能です。WebAuthnには「ハイブリッド認証(FIDO Cross-Device Authentication)」という規格が組み込まれています。

PC画面に表示されたQRコードを手持ちのスマートフォンで読み取ると、Bluetoothを用いた近接確認(端末同士が物理的に同じ空間にあることの確認)が行われます。その上でスマートフォンの秘密鍵を用いて署名処理が実行されます。PC側に秘密鍵が保存・転送されることは一切ないため、他人の端末からでも安全にログインできます。

Q2: NIST SP 800-63Bなどの公的ガイドラインは、民間企業にも法的な準拠義務がありますか?

法的な直接の強制力はありません。NIST(米国国立標準技術研究所)が発行する「NIST SP 800-63B-4」は、主として米国の連邦政府機関が情報システムを調達・運用する際の技術要件を定めた公的ガイドラインです。

ただし、その客観的かつ厳密な脅威分析とセキュリティ基準の信頼性の高さから、民間のWebサービスや世界各国の機関が認証システムを設計・評価する際の事実上の世界標準(デファクトスタンダード)として広く参照されています。

Q3: 二要素認証を設定していれば、パスワード自体は短く簡単なものでも安全ですか?

推奨されません。二要素認証はパスワード漏洩時のリスクを大幅に低減させますが、多層防御を維持するためにはパスワード自体の強度も重要です。

特にSMSやTOTPのような従来方式では、何らかの理由で二要素認証の迂回が発生した場合、脆弱なパスワードは短時間で突破されてしまいます。また、パスワードを使い回していると、二要素認証を設定していない付随サービスから侵入される連鎖被害を招きます。十分な長さとランダム性を持ったパスワードを設定した上で、二要素認証を組み合わせることが基本です。

---

まとめ

二要素認証は、従来のパスワードという知識情報だけに依存した認証の限界を補い、不正ログインのリスクを大幅に低減させる仕組みです。

「2段階認証」が操作回数に着目した呼称であるのに対し、「二要素認証」は知識・所持・生体という異なる性質の要素を組み合わせる点に本質的な違いがあります。手入力コードを用いるSMS認証やTOTP認証アプリはパスワード単体の漏洩には強いものの、通信をリアルタイムに仲介する中継型フィッシングに対しては脆弱性を抱えています。

これに対し、暗号学的にドメインを拘束して検証を行うWebAuthn(パスキー)は、利用者のミスによる情報流出を防ぎ、強固なフィッシング耐性を実現する現代の標準技術です。各方式の技術的境界を理解し、予備の認証器やバックアップコードを適切に管理して運用することが、アカウントを守る確実な防壁となります。

---

出典・参考資料

  • NIST SP 800-63B-4: Digital Identity Guidelines - Authentication and Lifecycle Management(米国国立標準技術研究所 公的ガイドライン 最終版:2025年7月31日公開)

https://pages.nist.gov/800-63-4/sp800-63b.html

  • RFC 6238: TOTP: Time-Based One-Time Password Algorithm(IETF 標準仕様)

https://www.rfc-editor.org/rfc/rfc6238

  • W3C: Web Authentication: An API for accessing Public Key Credentials Level 3(2026年5月26日付 W3C Candidate Recommendation Snapshot)

https://www.w3.org/TR/webauthn-3/

出典・参考資料(追補)