OTP徹底解説：HOTPとTOTPの仕組みと安全な実装・運用ガイド
エバープレイ編集部OTPとは — 概要と用語の注意点
OTPは一般に「One-Time Password（ワンタイムパスワード）」の略で、認証において一度だけ使える使い捨てのパスワードを指します。ログインや取引確認などで使われ、同じパスワードが使い回されないため、パスワードの盗用やリプレイ攻撃に対する防御になります。
ただし「OTP」は文脈によっては別の意味で使われることがあり、暗号理論の分野では「One-Time Pad（ワンタイムパッド）」という完全に安全とされる暗号手法を指すこともあります。本稿では主にIT／認証で広く使われる「One-Time Password（ワンタイムパスワード）」について詳述しますが、両者の違いを最初に押さえておくと誤解を避けられます。
OTPの主要な方式：HOTPとTOTP
代表的なOTPアルゴリズムとしては、HOTP（HMAC-based One-Time Password）とTOTP（Time-based One-Time Password）があります。これらは業界標準として広く採用され、仕様はRFCで定義されています。
HOTP（RFC 4226） — 共有されたシークレットとカウンタ（インクリメントされる値）を基にHMACを計算し、そこから短い数字列を動的に生成します。カウンタ同期が必要で、ワンタイムトークンが消費されるたびにカウンタが増えます。
TOTP（RFC 6238） — HOTPのカウンタの代わりに現在時刻（通常はUnix時間を一定秒幅で区切った値、デフォルトは30秒）を用います。生成されるコードの有効期間が短いため、ユーザビリティと安全性のバランスが取りやすく、スマートフォンアプリ（Google Authenticator等）で広く採用されています。
OTPの配信・実装形態
OTPの配布・利用方法にはいくつかの形態があります。用途や脅威モデルに応じて適切な方式を選ぶことが重要です。
ソフトトークン（アプリ内生成） — ユーザーの端末（スマートフォン）にシークレットを保存し、端末上でTOTPを生成する方式。メリットはネットワークに依存せずオフラインで生成可能な点、デメリットは端末紛失時のリスク。
ハードトークン（物理トークン） — 専用デバイスがOTPを生成。企業向けに利用され、シークレットがデバイス内に保持されるため安全性が高い。
SMS・音声・メールで送るワンタイムコード — サーバ側がコードを生成して送信。利便性は高いがSIMスワップや盗聴、メールアカウント侵害などの脆弱性があるため高セキュリティ用途では推奨されない場合がある。
プッシュ通知認証 — サーバがプッシュ通知で認証リクエストを送り、ユーザーが端末で承認する方式。フィッシング耐性やユーザビリティの面で優れるが、実装とインフラが必要。
アルゴリズムの仕組み（簡潔に）
TOTPの内部は概念的にシンプルです。サーバとクライアントは共有シークレットを持ち、現在時刻を一定幅（たとえば30秒）ごとのタイムステップに変換します。タイムステップとシークレットをHMACにかけ、その結果から動的トランケーションで短い数字列を抽出します。RFC 6238ではデフォルトで30秒、6桁、HMAC-SHA-1が参照されていますが、SHA-256/512や桁数は拡張可能です。
セキュリティ上の問題点と攻撃手法
OTPは万能ではありません。実運用でよく問題になる攻撃や制約は以下の通りです。
- SIMスワップ／SMS盗聴 — SMSで送信するOTPは携帯番号の乗っ取り（SIMスワップ）やSS7の脆弱性などによって盗まれるリスクがあります。
- フィッシング／中間者攻撃（MITM） — 攻撃者がリアルタイムでユーザーからOTPを盗んで即座に悪用するケース。特にWebでログインページを偽装してOTP入力を誘導するフィッシングが知られています。
- シークレット管理の破綻 — サーバ側で共有シークレットを安全に保管していないと破られてしまいます。平文保存やバックアップの不備は致命的です。
- ブルートフォース — OTPが6桁程度だと総当たりで試せる可能性があるため、試行回数制限やレートリミットが必須です。
- 同期問題 — HOTPではカウンタ同期、TOTPではクライアントとサーバの時計ずれに注意が必要。一定の許容ウィンドウを設ける実装が一般的です。
実装時のベストプラクティス
安全で使いやすいOTP実装には次の点を考慮してください。
- 可能であればSMSではなくソフトトークン（TOTP）やプッシュ認証、フェデレーションやFIDO2/WebAuthnのようなフィッシング耐性の高い方式を検討する（NISTのガイドラインも参照）。
- シークレットの生成と保管は安全なランダム生成器とHSMやKMSを用いて行い、平文での長期保存を避ける。
- OTPコードは短い有効期間（TOTPなら30秒など）を採用し、再利用禁止、ワンタイム消費を確実にする。
- ブルートフォース対策として試行回数制限、レートリミット、アカウントロック／アラートを実装する。
- 端末盗難やアカウント回復のフローを安全に設計し、バックアップコードや復旧用の多要素検証を用意する。
- 時計同期にはNTPを利用し、許容するタイムウィンドウは運用に応じて慎重に設定する。
- ユーザー教育（フィッシング注意、シークレットの扱い）を行う。
OTPの代替・補完となる技術
近年はOTPに加えて、より強固な認証技術が普及しています。
- FIDO2 / WebAuthn — 公開鍵基盤を用い、フィッシング耐性が高い標準。ハードウェアセキュリティキーや生体認証を用いた認証が可能です。
- 認証アプリのプッシュ通知 — ユーザーが「承認/拒否」を操作することで、不正なサイトへの認証入力を防ぐ効果がある。
- リスクベース認証 — ログイン時のコンテキスト（IP、端末情報、行動）に応じて追加認証を求める方式。
まとめ
OTPは使い回しを防ぐことでパスワード単体より安全な認証を実現する有効な手段です。HOTPやTOTPという標準アルゴリズムが存在し、ソフトトークンやハードトークン、SMSなど様々な配信手段があります。しかしSMSの脆弱性やフィッシング、シークレット管理の問題といったリスクも抱えます。運用ではNIST等のガイドラインを踏まえ、可能ならフィッシング耐性の高いFIDO2やプッシュ認証などを併用することが望ましいでしょう。
参考文献
- RFC 4226 — HOTP: An HMAC-Based One-Time Password Algorithm
- RFC 6238 — TOTP: Time-Based One-Time Password Algorithm
- NIST Special Publication 800-63B — Digital Identity Guidelines: Authentication and Lifecycle
- OATH — Initiative for Open Authentication
- OWASP Multi-Factor Authentication Cheat Sheet
- Yubico — OTPおよびパスワードレス認証に関する資料
- Google Identity Platform／認証に関するドキュメント（Google Authenticator 等の実装情報）
