この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。TOTPの公式規格とNISTの認証指針に基づき、6桁の認証コードを仕組みから解説します。
検証ステータス：📘 公式仕様確認済み／実サービスへの登録・ログイン操作は未実施
スマートフォンの認証アプリには6桁の数字が表示され、しばらくすると別の数字に切り替わります。電話もメールも届いていないのに、Webサイトは入力された数字が正しいと分かります。なぜでしょうか。答えは、アプリとサービスが、同じ秘密情報と時刻を使って計算しているからです。数字の裏側を知ると、QRコードの扱い、機種変更、偽サイトの危険も説明できるようになります。
| 項目 | 説明 |
|---|---|
| 対象 | 時刻で変わる6桁の確認コード。すべてのMFA方式ではない |
| 読者 | 認証アプリを使う初心者、企業の担当者 |
| 技術 | TOTP、共有秘密、HMAC、時刻の区切り |
| 試す前に | 本物のコードやQR、秘密情報は教材に貼り付けない |
| 実機検証 | 製品の登録・ログイン操作は未実施。RFCとNISTを確認 |
図は秘密・時計・照合の関係を単純化したオリジナルの概念図です。GoogleやMicrosoftの実際の設定画面を再現したものではありません。
コードを受信しているわけではない
Google Authenticatorに表示される6桁の数字は、SMSのように毎回サーバーから届くものとは限りません。一般的なTOTPでは、初期登録時にアプリとサービスが同じ秘密情報を共有し、両方がその秘密情報と現在時刻を使って独立に数字を計算します。このため認証アプリはオフラインの状態でも数字を表示できます。ただし、ログイン画面へ番号を送信して認証を完了するには通信が必要です。
「数字を表示できた」という事実と、「正しいアカウントへサインインできた」という事実は別です。アプリに表示される数字は計算結果であり、サービスに保管されたパスワードそのものではありません。登録時の秘密情報が漏れれば、攻撃者の端末でも同じ時刻の数字を計算できる可能性があるため、数字が短時間で変わることだけを安全性の根拠にしてはいけません。
QRコードには将来の数字の材料がある
TOTPを登録するとき、Webサイトが表示するQRコードは、アプリを起動するための単なる案内ではありません。一般的にはアカウントのラベル、秘密情報、計算方法に関する条件など、認証器の設定に使う情報を含められます。QRを読み取ると、アプリはそのアカウント用の数字を計算できるようになります。
ここに大きな落とし穴があります。「登録後にはQRは使わないから、スクリーンショットを保存しても大丈夫」という考え方です。実際には将来の認証に使う秘密情報が含まれる場合があり、画像が第三者に渡ると、登録済みの端末を盗まなくても数字を再現される恐れがあります。QRをチャットや問い合わせチケットへ貼る運用は避け、漏えいが疑われたらサービスの正式な再登録手順を確認します。
同じ時刻でもアカウントによって数字が違う
TOTPの計算には時刻と秘密鍵の双方が必要です。同じ30秒間に複数のアカウントを眺めても、秘密が異なれば数字は通常異なります。RFC 6238では、時刻を一定幅の区間に変換し、秘密を使った計算へ渡す方法を規定しています。30秒はよく使われる設定ですが、あらゆるサービスが同じ桁数や時間幅とは限りません。
この計算で使うHMACは、秘密鍵を使って検証用の値を作る仕組みです。公開鍵暗号とは別の方式です。TOTPではアプリとサーバーの両側が同じ秘密を保持しており、パスキーのようにサービスが公開鍵だけを持つわけではありません。技術の違いを知ると、認証アプリの画面が似ていても安全性を同一視してはいけない理由が分かります。
6桁しかないのに安全なのか
6桁の数字は見た目には短く、100万通りしかありません。そのため「数字が変わるから、いくらでも試されても大丈夫」という設計は危険です。サービスは試行回数を制限し、使われたコードの再利用を防ぎ、適切な有効時間を定める必要があります。認証器がどれだけ正しく計算しても、検証側が無制限に推測を受け入れれば弱点になってしまいます。
また、時刻が切り替わる前後の通信遅延や時計のずれを吸収するため、近隣の時刻区間を許容する実装があります。しかし、許容範囲が広がるほど受け入れる候補も増えるため、安全性と使いやすさを考えた設定が必要です。この判断は一般利用者ではなく、認証サービスの実装・管理側の責任です。
正しい数字なのにログインできない原因
まず確認するのは、ログインページが本物のサービスなのかという点です。次に、アプリ内で正しいアカウント名を選択しているか、時計が自動設定されているか、入力途中で数字が切り替わったかを見ます。認証アプリを複数のサービスに登録していると、似た名前の項目を選んで別のサービスの数字を入力することがあります。
同じ番号を何度も試しても解決しない場合、サービス側の試行制限に達した可能性もあります。登録を削除したりアカウントをリセットしたりする前に、予備の認証方法やバックアップコードがあるかを確認しましょう。企業アカウントなら勝手にMFAを無効化せず、正式な本人確認と再登録の流れに従います。
2台の端末に同じ数字が出たら
同じ秘密情報を2台の端末が保持していれば、同じ時刻の数字が一致する場合があります。これはTOTPの計算の性質から説明できます。ただし、使える端末が増えるほど秘密の管理範囲も増えます。使わなくなった端末が保護されず放置されていれば、盗難や情報漏えい時に新しい危険が生じます。
同期機能を使う場合も、同期先アカウントをどのように保護しているかが重要です。「同期しておけば絶対に復旧できる」とは限らず、同期先のアカウントへ入れない場合やサービス側の登録条件によって失敗することがあります。端末を返却・廃棄する前に、登録したアカウントと復旧方法を確認し、必要な登録解除を行います。
機種変更は旧端末の初期化より先に
スマートフォンが壊れた後で認証方法を移そうとすると、必要なログイン自体ができなくなる場合があります。機種変更を予定しているなら、先にサービスの提供する移行手順を確認し、新端末で必要なアカウントへログインできる状態を確認してから旧端末を手放すのが安全です。
バックアップコードや予備の認証方法は、運用上の保険になります。しかしそれらも本人確認に使える秘密情報なので、実コードをオンライン記事や共有チャットに貼り付けてはいけません。会社では私物端末の利用可否、緊急時の代理申請、管理者によるリセット手順が決められていることもあり、個人向けの解説どおりに操作できるとは限りません。
TOTPが偽ログイン画面に弱い理由
パスワードが漏れていてもTOTPが追加で必要なら、不正なログインを難しくできます。しかし、利用者が偽サイトにパスワードと現在の6桁を両方入力してしまうと、攻撃者が短時間で本物のサービスへその番号を中継する場合があります。TOTPの計算式そのものが壊れたのではなく、手入力した数字が正しいWebサイトの名前やログインセッションへ結び付いていないのです。
NISTは手入力するOTPを、フィッシング耐性を備えた認証方式とは区別しています。だからといってTOTPが無意味なのではありません。パスワードだけより安全性を高める重要な手段ですが、偽サイトへ誘導される攻撃には別の備えが必要です。重要な管理アカウントなどでは、FIDO2やパスキーといった方法の導入を検討します。
認証アプリとパスキーを区別する
Microsoft Authenticatorでは、数字の手入力だけでなくプッシュ通知で承認する方式や、対応する環境でのパスキー認証も提供されます。同じ製品名が画面に表示されたからといって、そのすべてがTOTPではありません。通知の番号照合と、共有秘密を使って生成する数字は、利用者の操作も内部のやり取りも異なります。
パスキーではサービス側が公開鍵を保持し、端末の秘密鍵で作った署名を検証します。TOTPは両側で共有する秘密情報と時刻から数字を計算します。どちらも認証に使えますが、秘密の保管場所とフィッシング耐性が違います。この区別を押さえると、「GoogleとMicrosoftのアプリは公開鍵方式なのか」という疑問に、製品名ではなく機能ごとに答えられます。
会社の導入では復旧と代替手段が必要
企業では、MFAの登録率だけを導入の成功指標にしないことが重要です。会社支給スマートフォンを使える人と、端末持込が禁止された施設で働く人では利用条件が異なります。緊急時にしか使わない管理者アカウントや、出張中の担当者が認証できない場合も想定します。
安全な導入には、対象者の確認、事前案内、登録の試行、紛失時の本人確認手順、予備の認証方法まで含めた設計が必要です。認証アプリの実コードをサポート担当に送らせるのではなく、公式の登録状況確認や本人確認によって問題を解決します。強い認証方式であっても、運用が不明確なら正規の利用者が締め出され、逆に安易な例外が危険につながります。
サーバーとアプリが同じ計算をする流れ
次のMermaid図では、登録時の秘密情報と、ログイン時に送る数字を分けています。「何を保護し、何を入力するのか」を確認してください。
sequenceDiagram
participant U as 利用者
participant S as ログインサービス
participant A as 認証アプリ
S-->>U: 登録QRを表示
U->>A: 秘密情報を登録
Note over A,S: 両者は同じ秘密と時刻条件で計算
A-->>U: 今の6桁を表示
U->>S: 6桁を入力
S->>S: コードを再計算して照合
S-->>U: 一致すれば追加認証成功
この図はTOTPの典型的な流れを示したもので、特定のサービスの通信を測定した記録ではありません。利用者はログインするたびにQRコードを読み取るのではなく、登録後には現在の番号を確認します。サーバー側が秘密そのものを毎回スマートフォンから受け取るわけでもありません。
身近な6つの場面で判断を変える
圏外でも6桁が表示される
数字の生成は端末内で完結できる方式なので、通信状態の問題と数字の表示を分けて考える。 この場面で確かめたいのは、数字の生成、端末の登録、サービス側の検証という三つのうち、どこに問題があるかです。混同すると、必要のないパスワード変更や登録削除で自分の復旧を難しくする場合があります。
30秒の終わりに数字を入力した
通信と入力に時間がかかると別の時間帯になる。更新直後の数字で試し、時刻設定を確かめる。 この場面で確かめたいのは、数字の生成、端末の登録、サービス側の検証という三つのうち、どこに問題があるかです。混同すると、必要のないパスワード変更や登録削除で自分の復旧を難しくする場合があります。
登録QRを写真で共有してしまった
現在の数字ではなく秘密が漏れた可能性がある。サービスの正規手順で登録状況を見直す。 この場面で確かめたいのは、数字の生成、端末の登録、サービス側の検証という三つのうち、どこに問題があるかです。混同すると、必要のないパスワード変更や登録削除で自分の復旧を難しくする場合があります。
パスワードを変更しても数字が変わらない
パスワードとTOTPの共有秘密は別の情報。片方を変更してももう片方が自動更新されるとは限らない。 この場面で確かめたいのは、数字の生成、端末の登録、サービス側の検証という三つのうち、どこに問題があるかです。混同すると、必要のないパスワード変更や登録削除で自分の復旧を難しくする場合があります。
二つの端末で同じコードが出る
同じ秘密情報を持つ場合の動作として説明できるが、秘密の複製範囲の管理が必要。 この場面で確かめたいのは、数字の生成、端末の登録、サービス側の検証という三つのうち、どこに問題があるかです。混同すると、必要のないパスワード変更や登録削除で自分の復旧を難しくする場合があります。
ログインしていないのに認証要求が来た
自分で始めていない操作を承認しない。別方式の通知承認とTOTPのコード入力を混同しない。 この場面で確かめたいのは、数字の生成、端末の登録、サービス側の検証という三つのうち、どこに問題があるかです。混同すると、必要のないパスワード変更や登録削除で自分の復旧を難しくする場合があります。
トラブル時に何を確かめるか
flowchart TD
A["6桁が通らない"] --> B{"本物のサイトか"}
B -->|"不明"| C["公式URLから開き直す"]
B -->|"はい"| D{"アカウント選択は正しいか"}
D -->|"いいえ"| E["正しい登録先を選ぶ"]
D -->|"はい"| F["時刻・更新タイミングを確認"]
F --> G{"解決したか"}
G -->|"はい"| H["ログインを続ける"]
G -->|"いいえ"| I["公式の復旧・管理者手続き"]
どこで失敗するかによって、次に調べることが違います。パスワード段階の失敗なのか、TOTPの照合で失敗するのか、認証には成功したのに業務アプリの権限で拒否されたのかを分けます。いずれも「認証エラー」という表示だけでは確定できません。実際のコードや秘密をサポート窓口へ送る必要はありません。
公式リンクを読む理由
RFC 6238（TOTP）：時刻と共有秘密を使った計算方式の規格。アプリごとに異なる画面ではなく、共通原理を確かめるために読む。
NIST SP 800-63B（認証器）：OTPの強度やフィッシング耐性を区別する指針。『MFAだから絶対安全』という誤解を避けるために読む。
Google Authenticator公式ヘルプ：同期や機種変更など製品固有の操作を行う直前に、公式の最新情報を確かめる入口。
これらは同じ内容を重ねた参考リンクではありません。RFCは計算の仕組みを、NISTは方式の安全性と限界を、製品ヘルプは実際の運用・移行を説明します。規格上できることと、利用するサービスが許可している操作は異なるため、リンクを読む目的を分けることが重要です。
まとめ
TOTPの6桁は端末に毎回送られる番号ではなく、登録された共有秘密と時刻から作る短い計算結果です。登録QRの保護、時計の同期、紛失時の復旧、偽サイトへ番号を入力しないことまで含めて使いこなせます。パスキーや通知承認は別の仕組みなので、認証アプリの製品名ではなく、何を使って本人を確認しているかで考えましょう。
