OTP認証とは？仕組み・種類・実装とセキュリティ対策の完全ガイド

2025年12月14日 最終更新日時 : 2025年12月14日 エバープレイ編集部

OTP認証とは何か — 基本概念と役割

OTP（One-Time Password：ワンタイムパスワード）は、一度だけ有効な使い捨てパスワードを用いて認証を行う方式です。通常の静的パスワードと比べてリプレイ攻撃や盗聴に対する耐性が高く、二要素認証（2FA）や多要素認証（MFA）の一部として広く採用されています。OTPは、サーバーと利用者側（トークンやアプリ、携帯電話など）が共有する秘密鍵と、時間やカウンタなどの同期情報に基づいて生成されます。

主要な方式と標準

  • HOTP（HMAC-based One-Time Password） — RFC 4226。カウンタ値を使ってHMACを計算し、固定桁の数字列を生成します。再送防止や状態管理が必要です。
  • TOTP（Time-based One-Time Password） — RFC 6238。時刻（通常30秒単位）をインプットに使い、短時間だけ有効なコードを生成します。多くの認証アプリ（Google Authenticator、Authyなど）がこの方式に準拠しています。
  • SMS/音声OTP — サーバーが生成したOTPを携帯電話のSMSや音声通話で送信します。実装が簡単で普及している一方で、SIMスワップやSS7、盗聴のリスクがあります。
  • メールOTP — OTPを電子メールで送る方式。配信遅延やメールアカウントの侵害が懸念されます。
  • Push通知（ワンタイム承認） — アプリが受信したプッシュ通知でユーザーが承認をする方式。OTPコードの入力を不要にし、フィッシング耐性を向上させられます（ただしプッシュ自体の詐取リスクあり）。
  • ハードウェアトークン — 物理デバイスがOTPを表示する方式。FIDO/U2FやWebAuthnのように公開鍵暗号を用いる規格と組み合わせると、フィッシング耐性がさらに高まります。

仕組み（TOTP/HOTP の技術的概要）

HOTPは共有秘密鍵 K とカウンタ C を HMAC-SHA1 等で計算し、特定のビットを切り出して指定桁数の数字を導出します。TOTPは C を時刻ベースのステップ数（例えば floor(currentUnixTime / 30)）で置き換えたものです。設計上は次の点が重要です。

  • 秘密鍵の長さと乱数性（通常は160ビット以上／Base32表記での管理）
  • 桁数（6桁・8桁が一般的）と有効期間（例：30秒）
  • 時刻同期の許容範囲（許容ウィンドウ、例：±1ステップ）
  • 再利用防止（同じOTPの再受理拒否）とレート制限

実装時の注意点

  • 秘密鍵の安全な保管：サーバー側秘密鍵は暗号的に保護し、平文ログには絶対残さないこと。ハードウェアセキュリティモジュール（HSM）やKMSの利用を検討する。
  • プロビジョニングの安全性：初期シードをQRコードや安全チャネルで配布する。メールやURLでシードを送ると盗難リスクが増す。
  • 時間同期：TOTPを使う場合はNTPでの正確な時刻管理と、そのズレを補正する仕組みが必要（許容ウィンドウ）。
  • ユーザー体験（UX）：バックアップコードや代替認証方法（ハードウェアトークン、プッシュ認証）の用意、デバイス移行手順を簡潔にする。
  • ログと監査：失敗/成功の認証試行を記録し、異常な試行（大量の失敗、異常な地理的ログイン）を検出する。
  • OTPをURLやGETパラメータに含めない：ログやリファラに残るため、盗聴の原因になる。

主な脅威とその対策

  • SIMスワップ／SMS盗聴：SMS OTPはモバイルキャリアの口座乗っ取り（SIMスワップ）やSS7脆弱性で盗まれる危険があります。重要な取引や高リスク認証ではSMSを唯一の手段にしないこと。
  • フィッシング・リアルタイムMITM：攻撃者が偽サイトを用意し、ユーザーの入力したOTPをリアルタイムで窃取して利用することがあります。これを防ぐには、ワンステップのOTPだけでなくチャネルバインディングやトランザクション署名、あるいはFIDO2のようなフィッシング耐性のある認証方式を検討する。
  • リプレイ攻撃：OTPは一度のみ有効にし、短時間で期限切れにすることで防御する。
  • サーバー側の秘密漏洩：鍵管理の不備が致命的。複数サービスで同一鍵を使い回さない、定期的な鍵ローテーションを検討する。

運用上のベストプラクティス

  • リスクに応じた認証ポリシー：高リスク操作（送金、設定変更）には追加確認やより強いMFAを要求する。
  • フォールバックと復旧手順：ユーザーがデバイスを失った際の本人確認フローを用意し、サポートによる不正復旧リスクを最小化する。
  • 教育と通知：SMSやメールでのOTPを用いる場合、ユーザーにフィッシング注意喚起を行い、認証試行の通知（ログインアラート）を有効にする。
  • 採用技術の見直し：NIST SP 800-63B など最新ガイドラインに従い、SMSを高保証の認証手段として単独採用しない等の判断を行う。

代替と今後のトレンド

近年は従来のOTPに加え、フィッシング耐性の高い公開鍵方式（FIDO U2F / WebAuthn / FIDO2）や、パスワードレス認証、デバイスバインディングを組み合わせた方式が注目されています。これらはOTPよりも強固にユーザーとサーバーを紐付け、MITMやリプレイへの耐性を高めます。

設計チェックリスト（開発者向け）

  • 使用するOTP規格（HOTP/TOTP）とパラメータ（桁数、時間ステップ）をドキュメント化する。
  • 秘密鍵は安全に生成し、転送・保存・ログに残さない。
  • レート制限、ロックアウト、CAPTCHA等でブルートフォースを抑止する。
  • プロビジョニング時のQRコードは一度きりの表示とし、再表示時には再認証を要求する。
  • 失敗ログを監視し、不審な試行にはアラートを上げる。
  • ユーザーの回復手順は多要素で設計し、サポート経由での乗っ取りを防ぐ。

まとめ

OTP認証は手軽に導入でき、静的パスワードよりも高いセキュリティを提供しますが、方式によっては脆弱性（SMSのSIMスワップやフィッシング）を抱えます。実装と運用においては鍵管理、プロビジョニング、時刻同期、リスクベースポリシーの採用、監査・通知の整備が不可欠です。さらに高いセキュリティが必要な場合は、FIDO2などフィッシング耐性のある認証技術の併用を検討してください。

参考文献

カテゴリー
IT
前の記事
OSSとは何か：技術・法務・ビジネスから読み解くオープンソースの全体像New!!
2025年12月14日
次の記事
ロンドン国際映画祭（BFIロンドン映画祭）完全ガイド：歴史・構成・参加のポイントNew!!
2025年12月14日