「2段階認証」で何が変わるのか
パスワードは漏れます。フィッシングで、データ侵害で、使い回しで、あらゆる経路で漏れます。仮に エントロピーの高いパスワード を使っていても、サービス側が ハッシュ保存をサボっていた瞬間にあなたのパスワードは攻撃者の手元に渡ります。
この前提に立つと、「パスワードだけで守る」モデルはもう破綻している。だから現代の認証は、パスワードに加えて別の要素で確認する MFA（Multi-Factor Authentication, 多要素認証）が標準になりつつあります。
3つの「要素」
MFA の「Multi-Factor」は性質の異なる要素を組み合わせるという意味です。同じ性質を2つ重ねても本当の意味では多要素になりません：
| 要素 | 意味 | 例 |
|---|---|---|
| 知識（Something you know） | 本人だけが知っているもの | パスワード、PIN、秘密の質問 |
| 所有（Something you have） | 本人だけが持っているもの | スマホ、ハードウェアトークン、IC カード |
| 生体（Something you are） | 本人の生体的特徴 | 指紋、顔、声紋、虹彩 |
「パスワード + 秘密の質問」は両方とも知識要素なので、MFA とは呼びません。「パスワード + スマホへの SMS」は知識 + 所有なので MFA。「パスワード + 指紋」は知識 + 生体で MFA。
方式1: SMS / 音声通話による OTP
最も普及しているが、セキュリティ的にはおすすめしない方式。日本の銀行・通販サイトで未だに主流ですが、米 NIST は 2016 年から非推奨化しています。
弱点：
- SIM スワップ詐欺: 通信キャリアに身分を偽って SIM を再発行させ、SMS を奪う。実際にイーロン・マスクや暗号資産取引所幹部などが被害に遭っています
- SS7 プロトコル攻撃: 携帯網のシグナリングプロトコルの脆弱性で、SMS が傍受される
- フィッシング耐性ゼロ: 偽サイトで6桁のコードを入力させれば即時に攻撃成立
とはいえ「パスワードだけ」より遥かに安全なので、選択肢が SMS しかないなら有効化すべき。SMS が選べる時は TOTP も選べる場合が多いので、その時は TOTP を選びましょう。
方式2: TOTP（Google Authenticator系）
スマホアプリ（Google Authenticator / Authy / 1Password）が30秒ごとに6桁の数字を生成する方式。RFC 6238 で標準化されており、各社互換。
仕組みはシンプル：
- 登録時にサーバが 共有秘密鍵（Base32 文字列） を発行し、QR コードでアプリに渡す
- アプリはその秘密鍵と現在時刻（30秒単位に丸めた値）を HMAC-SHA1 して6桁の数字を作る
- サーバ側も同じ計算をして照合
TOTP = HMAC-SHA1(secret, floor(unix_time / 30))[truncated to 6 digits]サーバ・アプリ間の通信は最初の登録時のみ。日常的な認証ではネットワーク不要。SMS と違って「時計が合っていれば動く」のが利点。
SMS 比の改善点：
- SIM スワップで奪われない（秘密鍵はスマホ内）
- 通信キャリアの脆弱性を経由しない
- サービス側の追加コストゼロ（SMS 送信費用がかからない）
弱点：
- フィッシング耐性は低い: 偽サイトで6桁を入力させれば突破される。SMS 同様に Real-time Phishing Proxy（攻撃者がリレー）に弱い
- スマホを失くすと終わる: バックアップコードをサービスごとに保管する必要あり
- 共有秘密鍵がサーバ侵害で漏洩する: サーバ側に平文または可逆暗号で保管されるため、DB 漏洩で TOTP 偽造可能になる
方式3: FIDO2 / WebAuthn / Passkey
2010年代後半に標準化された公開鍵暗号ベースの認証。「パスワードレス」「Passkey」と呼ばれているのはこの方式の一部です。用語が混乱しやすいので整理：
| 用語 | 意味 |
|---|---|
| FIDO2 | FIDO Alliance による認証規格群の総称 |
| WebAuthn | FIDO2 のうち、ブラウザから使う W3C 標準 API |
| CTAP2 | FIDO2 のうち、ブラウザ⇔認証器（YubiKey 等）の通信プロトコル |
| Passkey | 2022年 Apple/Google/MS が打ち出したマーケティング用語。中身は WebAuthn を一般ユーザーに分かりやすく見せたもの |
仕組みは公開鍵暗号：
- 登録時、ブラウザ/OS がそのサイト専用の鍵ペアを生成する
- 秘密鍵はスマホ/PC/YubiKey に保管、公開鍵はサーバに送信
- ログイン時、サーバが乱数チャレンジを送る
- 認証器が指紋認証 or PIN で本人確認した上で、秘密鍵でチャレンジに署名
- サーバは公開鍵で検証
TOTP / SMS との決定的な違い：
- フィッシング耐性がある: 鍵ペアが「ドメインに紐付く」ため、偽サイトでは認証器が反応しない（origin check）
- サーバ漏洩しても安全: サーバには公開鍵しかなく、漏れても攻撃に使えない
- パスワードレス化が可能: パスワードと組み合わせる必要がなく、認証器単独で認証完結できる
- 共有秘密鍵が存在しない: 各サイトごとに独立した鍵ペアなので、1サイトの漏洩が他に波及しない
Passkey が「Passkey」と呼ばれる理由
従来の WebAuthn では、秘密鍵は「特定のデバイスから出ない」のが原則でした（YubiKey が代表例）。これだと「スマホ買い替えで全サービスから締め出される」事故が起きるため、2022年から iCloud / Google Password Manager / 1Password 等で同期できる Passkey が登場しました。
現代の Passkey の挙動：
- iPhone で作った Passkey が iCloud Keychain 経由で Mac/iPad に同期
- Android で作った Passkey が Google アカウント経由で他 Android に同期
- 同期に対応していない YubiKey などの「Device-bound Passkey」も併存
ユーザー体験的には「指紋 or 顔認証だけでログイン完了」。パスワード入力もコード入力も不要。これが「パスワードレス」と呼ばれる所以です。
実用的な使い分けガイド
| シーン | 推奨 |
|---|---|
| 銀行・暗号資産・メインメール | Passkey + ハードウェアキー（Passkey は便利、ハードキーは復旧用） |
| SaaS / 開発ツール（GitHub 等） | Passkey or TOTP |
| SMS しか選べないサービス | SMS でも有効化（無いよりずっとマシ） |
| 会社の業務システム | SAML/OIDC + IdP 側で MFA 強制（Okta / Azure AD / Google Workspace） |
復旧手段（Recovery）の話
MFA を有効にする時、「アカウント復旧手段」が結局MFA の弱点になるのは知っておくべきです。
例えば：
- Passkey の復旧に SMS が使われる → SMS の弱さが復旧経由で漏れる
- 「秘密の質問でパスワードリセット」が残っている → MFA 全部回避される
- カスタマーサポートに電話で身分を偽って復旧 → ソーシャルエンジニアリング成立
理想は「復旧経路も同じレベルの強度を要求する」。具体的には：
- サービス登録時にバックアップコード（10〜20桁の使い捨てコード10個程度）を取得し、紙またはパスワードマネージャに保管
- 重要アカウントはハードウェアキー2本を登録（1本紛失しても困らない）
- 「秘密の質問」が残っているサービスはランダム文字列で潰す
おわりに
MFA は「とりあえず有効化すれば安全」ではなく、選んだ方式によって耐性レベルが大きく違います：
SMS < TOTP < Passkey/WebAuthnフィッシング攻撃が高度化している現代では Passkey / FIDO2 がベスト。とはいえ「TOTP しかない」「SMS しかない」サービスでも、有効化することで攻撃ハードルは大幅に上がります。本サイトの TOTP Generator ツールで、Authenticator アプリ内部で何が起きているのか実際に動かして確認できます。