はじめに

#

ログインのたびに使う、Google Authenticator や Microsoft Authenticator の 6桁コード。あれは、なぜネット接続なしで端末から出せるのに、サーバ側と一致するんでしょうか。

仕組みを分解してみると、コア計算は Pythonで20行程度 に収まる驚くほど小さなアルゴリズムでした。本記事では、

• MFAという広い文脈の中で TOTP（Time-based One-Time Password） がどこに位置するか
• TOTPの中身（HMAC + 時間窓）の分解
• 20行で自作して Google Authenticator と数字が一致することの確認
• TOTPの強みと限界、Passkey（WebAuthn）への流れ
• Authenticatorアプリ選びでのセキュリティ観点

の順で整理します。

HMAC( 共有秘密 K , メッセージ m ) → タグ（HMAC-SHA256 なら 32バイト）

HMAC(K, m) = H( (K' XOR opad) || H( (K' XOR ipad) || m ) )
                    ↑                    ↑
               外側用の鍵            内側用の鍵

1. MFAの全体像 — TOTPの位置づけ

#

MFA（Multi-Factor Authentication）は、認証要素を 複数のカテゴリ から組み合わせる発想です。代表的な3要素：

パスワードだけだと「知識」一要素。流出・使い回し・フィッシングに弱い。これに 所持 要素を足すのがMFAの基本形です。

主な「所持」要素の比較

#

TOTPは 「ネット不要・サーバ側はライブラリ追加だけ」というデプロイの軽さ で広く使われています。一方、フィッシングサイトに人間が6桁を打ち込んでしまえば突破される（後述）。

2. TOTPの中身

#

TOTP は RFC 6238（HOTP = RFC 4226 の時刻拡張）。構成要素はわずか3つです。

• K … 共有秘密（QRコードで配布される）
• T … カウンタ。floor(unix_time / 30)（30秒窓）
• digest = HMAC-SHA1(K, T) を末尾4バイトから6桁に圧縮

flowchart LR
  K["共有秘密 K
(MFA登録時のQRで配布済み)"] --> H
  Time["現在時刻 → T = floor(t/30)"] --> H
  H["HMAC-SHA1(K, T)"] --> X["dynamic truncation
→ 31bit 整数"]
  X --> M["mod 10^6"]
  M --> Code["6桁コード"]

なぜサーバとクライアントで一致するのか

#

ここで言うQRコードは、サービスでMFAを有効化するときに画面に表示される MFA登録用のQRコード（「Authenticatorアプリでスキャンしてください」と促されるあれ）のことです。

MFA登録時のQRコードをスキャンした瞬間に、共有秘密 K をサーバとアプリの両者が持つ 状態になります。あとは

• 入力 = 共有秘密 + 現在時刻
• 出力 = 同じ関数（HMAC-SHA1 → truncation）

なので、時計がだいたい合っていれば一致します。サーバ側は前後1〜2窓を許容して照合するのが普通。

MFA登録用QRコードの中身

#

このQRコードに入っているのは otpauth:// で始まるURIです。

otpauth://totp/Example:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=Example&period=30&digits=6&algorithm=SHA1

• secret … 共有秘密（Base32）
• period … 時間窓（秒）
• digits … 桁数
• algorithm … ハッシュ関数

つまり MFA登録の初回だけ、この鍵をサーバからアプリに渡している だけ。以降の通信は不要で、6桁の照合はオフラインで成立します。

3. 自作してみる（20行）

#

Pythonで TOTP を実装し、Google Authenticator と数字が一致することを確認してみます。

import base64, hmac, hashlib, time

def totp(secret_b32: str, t: int | None = None, digits: int = 6, period: int = 30) -> str:
    key = base64.b32decode(secret_b32, casefold=True)
    counter = (t if t is not None else int(time.time())) // period
    msg = counter.to_bytes(8, "big")
    digest = hmac.new(key, msg, hashlib.sha1).digest()
    offset = digest[-1] & 0x0F
    code = int.from_bytes(digest[offset:offset+4], "big") & 0x7FFFFFFF
    return str(code % (10 ** digits)).zfill(digits)

# RFC 6238 のテストベクタ（K = "12345678901234567890"）で確認
SECRET = base64.b32encode(b"12345678901234567890").decode()
print(totp(SECRET, t=59))         # 94287082
print(totp(SECRET, t=1111111109)) # 07081804

key = base64.b32decode(secret_b32, casefold=True)

counter = (t if t is not None else int(time.time())) // period

msg = counter.to_bytes(8, "big")

digest = hmac.new(key, msg, hashlib.sha1).digest()

offset = digest[-1] & 0x0F
code = int.from_bytes(digest[offset:offset+4], "big") & 0x7FFFFFFF

return str(code % (10 ** digits)).zfill(digits)

print(totp(SECRET, t=59))         # 94287082

Google Authenticator と一致させる手順

#

「サービスがMFA登録時に表示するQRコード」を自分で再現してみる流れです。

1. 適当な共有秘密を Base32 で生成（普段はサービス側がランダムに作る部分）
2. otpauth://totp/...?secret=... のQRコードを作り、Google Authenticator で読み取って登録
3. 同じ共有秘密を渡した自作スクリプトの出力と、Authenticatorアプリの表示が一致することを確認

4. TOTPの強みと限界

#

強み

#

• 依存が少ない: HMAC-SHA1 と時計だけ。サーバはライブラリ追加だけで済む
• オフライン動作: 登録後は通信不要
• 既存パスワードフローへの追加が容易

限界

#

• 共有秘密の漏洩リスク: サーバDBが漏れると全ユーザーのコードが第三者でも生成可能
• フィッシング耐性が低い: 偽サイトに6桁を打ち込めば即座にリレー攻撃される
• デバイス紛失時のリカバリが面倒: バックアップコードや別端末でのセットアップが必要

TOTPからPasskey（WebAuthn）への流れ

#

• Passkey はドメイン単位の公開鍵暗号 → フィッシングサイトに署名は出ない
• 共有秘密が存在しないので、サーバDB漏洩で他サイトに被害が広がらない
• 対応サイト・対応OS/ブラウザがあれば、TOTPより 原理的に 強い

「MFA = TOTPで十分」ではなく、「TOTPは導入の軽さで使うが、Passkey対応が広がったら積極的に乗り換える」が今のスタンスです。

5. Authenticatorアプリの選び方 — 1stパーティ vs 3rdパーティ

#

TOTPはオープンな標準（RFC 6238）なので、正しく実装すればどのアプリでも動きます。ただし「動く」と「安心して使える」は別の話。Authenticatorアプリは 共有秘密 K をそのまま保管している存在 であり、K が漏れた瞬間に攻撃者は同じ6桁コードを永久に生成できます（ユーザーが秘密を再発行するまで）。

つまりアプリ選びでは、次の3点すべてを信頼することになります。

• アプリ本体 — コードのバグ・悪意のある実装が混じっていないか
• 保管先 — 端末ローカルだけか、クラウドに同期されるか、その暗号化は十分か
• 配布経路 — ストアの正規アプリか、依存ライブラリのサプライチェーンに穴はないか

1stパーティ（Google / Microsoft / Apple）の特徴

#

ベンダー信頼度とOS統合が長所。一方で 「そのベンダーのアカウント」が新たな単一故障点 になる点は要注意（Googleアカウントが乗っ取られると同期されたTOTPがまとめて流出する）。

3rdパーティで考えるべきリスク

#

最後に

#

Authenticatorアプリの6桁コードの正体は、共有秘密 + 現在時刻 + HMAC-SHA1 のたった3つの合成。仕組みを理解すると、TOTPでできること・できないことが見えてきます。

• ネット不要なのは「サーバが送る」のではなく「両者が同じ関数で計算する」から
• フィッシング耐性が低いのは「人間が6桁を打ち込む」前提だから
• Passkeyに置き換わっていく流れは、この限界を解消するため

TOTPの自作はMFA全体のしくみを腹落ちさせる近道した。

参考

#

• RFC 4226: HOTP
• RFC 6238: TOTP
• RFC 2104: HMAC
• Google Authenticator Key URI Format