「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本紛失しても困らない）
- 「秘密の質問」が残っているサービスはランダム文字列で潰す
実体験：TOTP Generator を作って理解が変わったこと
TOTP Generator を作る前は、「認証アプリに表示される6桁の数字が30秒ごとに変わる」という程度の理解でした。実際に仕組みを調べてみると、単純にランダムな数字を生成しているわけではなく、サーバーと認証アプリが共有している秘密鍵と現在時刻を使って同じコードを計算しているだけだと分かりました。サーバー側と認証アプリ側で同じ秘密情報を持っている必要があることや、多少の時刻のズレを考慮する必要があることも、ここで初めて理解できました。「30秒ごとに変わる6桁の数字」という見た目だけだったものが、裏側の仕組みまでイメージできるようになったのは大きな収穫でした。
普段使っている MFA は Google Authenticator と Passkey です。認証アプリは一度設定してしまえばかなり便利ですが、スマホを持っていないとログインできないという面倒さがあります。一方で Passkey は、対応しているサービスなら指紋認証や端末認証だけでログインできるので、コード入力の手間がなく楽だと感じます。ただしサービスによって対応状況が違うことや、端末を変えたときに「この Passkey はどこに保存されているんだっけ」となることもあり、仕組みを理解していないと戸惑う部分もあると実感しています。
端末を変えたときのこの戸惑いは、後述する「復旧手段（Recovery）の話」とそのままつながっています。Passkey は便利な反面、同期の仕組みを理解していないと「復旧できるのか、できないのか」が分かりにくく、結局 SMS などの弱い経路に頼ってしまうと元も子もありません。自分が実際に戸惑った経験からも、便利な認証方式ほど復旧経路まで含めて確認しておくことの大切さを感じています。
おわりに
MFA は「とりあえず有効化すれば安全」ではなく、選んだ方式によって耐性レベルが大きく違います：
SMS < TOTP < Passkey/WebAuthnフィッシング攻撃が高度化している現代では Passkey / FIDO2 がベスト。とはいえ「TOTP しかない」「SMS しかない」サービスでも、有効化することで攻撃ハードルは大幅に上がります。本サイトの TOTP Generator ツールで、Authenticator アプリ内部で何が起きているのか実際に動かして確認できます。