ワンタイムパスワード(OTP)とは?TOTP・HOTPの仕組みとSMSリスクを踏まえた導入・運用のベストプラクティス

ワンタイムパスワード(OTP)とは

ワンタイムパスワード(One-Time Password、略してOTP)は、一度だけ使える使い捨ての認証コードです。通常の固定パスワード(静的パスワード)と異なり、毎回異なる値が生成されるため、リプレイ攻撃やパスワード漏洩のリスクを低減できます。多くの場合「第二要素認証(2FA)」の一部として用いられ、「知識(パスワード)」+「所持(OTPトークンやスマホ)」の構成でセキュリティを強化します。

主な種類と仕組み

  • HOTP(HMAC-based One-Time Password)
    RFC 4226で定義されたイベントベースのOTPです。サーバ側とトークン側が共有するシークレットと、増分するカウンタ値(イベントカウンタ)をHMAC(通常はHMAC-SHA-1)に入力し、指定桁数の数字を生成します。受け取り側はカウンタ同期を行いながら検証します。

  • TOTP(Time-based One-Time Password)
    RFC 6238で定義された時間ベースのOTPで、HOTPのカウンタを時刻に置き換えたものです。現在時刻を一定の時間間隔(タイムステップ、通常30秒)で割った値をカウンタとして利用します。タイムウィンドウ(許容される前後のステップ数)を設けることで時刻ずれに対応します。

  • ワンタイムパスワードの配送系
    ハードウェアトークン(専用端末)、ソフトトークン(スマートフォンの認証アプリ)、SMSやメールで送るコード、プッシュ通知承認など実装方法は多様です。どの方式を用いるかでセキュリティ性・利便性が変わります。

技術的詳細(概略)

HOTPは基本的に次の操作で生成されます:HMAC = HMAC-SHA-1(シークレット, カウンタ)。その結果から動的トランケーションを行い、10^Digits(例:6桁なら10^6)で剰余を取って数字を生成します。TOTPはカウンタに「floor((現在時刻 - T0) / X)」を用いる点が異なり、Xはタイムステップ(通常30秒)、T0は基準時刻(通常 Unix epoch)です。RFC 4226 / 6238 が標準仕様として参照されます。

利用形態とメリット・デメリット

  • ハードウェアトークン
    専用機器(例:RSA SecurIDやYubikeyの一部機能)で高い耐タンパ性を持ちますが、配布コストや紛失対応の運用負荷が発生します。

  • ソフトトークン(認証アプリ)
    Google Authenticator、Microsoft Authenticator、Authy 等が代表例。オフラインで動作し、SMSに比べて耐攻撃性は高いですが、端末の紛失・移行(バックアップ)対策が必要です。

  • SMS / 電子メール
    ユーザーにとって利便性は高いものの、SIMスワップ、携帯キャリア網(SS7等)経由の傍受、マルウェアによるSMS読み取りなどにより安全性は相対的に低いです。そのため高リスク用途では推奨されません。

  • プッシュ承認
    サーバが端末へ承認要求を送信し、ユーザーが「承認/拒否」操作を行います。ユーザー体験が良く、不正なログインの目視確認ができるため実運用で人気ですが、設計により中間者攻撃や通知詐取のリスクが残る場合があります。

セキュリティ上の課題・攻撃手法

  • フィッシング
    ユーザーを騙して認証コードを入力させることでアカウントを乗っ取る攻撃。TOTPでも十分に防げない場合があります(リプレイではなく、攻撃者が即時利用)。

  • 中間者攻撃(MITM)
    攻撃者が利用者とサービス間の通信を仲介し、入力されたOTPをリアルタイムで使用してログインを完了させる手法。プッシュ通知の偽装やフィッシングページでの誘導が該当します。

  • SIMスワップ・SMS傍受
    携帯電話の乗っ取りやキャリア手続きの不正利用によりSMSを受け取れなくさせ、OTPを抜き取る攻撃。SMSベースのOTPの最大の弱点です。

  • サーバ側のシークレット流出
    OTPの共有シークレットが漏れると、攻撃者は正規のOTPを生成できるため、シークレット管理は厳重に行う必要があります。

  • 総当たり・ブルートフォース
    OTPは桁数が限定されているため総当たり攻撃が現実的です。試行回数制限やロックアウトが必須です。

推奨される対策・ベストプラクティス

  • 高リスク用途ではSMSを単独で使わない
    NISTなどのガイダンスやセキュリティ業界の勧告では、SMSは補助的な手段とみなすべきで、可能なら認証アプリやハードウェアキー(FIDO/WebAuthn)を推奨します。

  • プロビジョニング時の安全確保
    認証アプリにシークレットを登録する際は、QRコード表示画面へTLSを使う、画面キャプチャやログに残らないようにする等の対策が必要です。シークレットをメール等で平文送信しないでください。

  • シークレットの保護と鍵管理
    サーバ側のシークレットは暗号化して保管し、アクセス制御を厳格にします。ログにシークレットや生成コードを残さない運用も重要です。

  • 試行制限とレートリミット
    OTP検証回数の上限やレート制限、アカウントロック、異常検知(地理的な飛びなど)を組み合わせて不正利用を防ぎます。

  • 失敗時のバックアップ方法の設計
    端末紛失への対処として、バックアップコードや複数の認証手段、サポート窓口での厳格な本人確認手順を用意します。ただしバックアップコードの扱いは慎重にし、1回限りで復旧後に無効化するなどの運用を徹底してください。

  • フィッシング対策(フィッシング耐性)
    フィッシング耐性が高い認証方式(FIDO2/WebAuthnなどの公開鍵証明方式)を重要サービスでは採用することが望ましいです。OTPのみだとフィッシングに脆弱である点を理解しておく必要があります。

  • 有効期限・桁数の設定
    TOTPのタイムステップは通常30秒、許容ウィンドウは±1程度が一般的です。桁数は6桁が多いですが、セキュリティ要件に応じて7〜8桁の採用を検討してください。ただし桁数増はユーザビリティの低下を招く可能性があります。

運用面・UX上の考慮点

  • ユーザー教育
    OTPコードを他人に教えない、フィッシングメールに注意する、バックアップコードは安全に保管する等の周知が重要です。

  • 端末移行の支援
    認証アプリを別端末に移す際の手順や、紛失時のリカバリ手順を分かりやすく提示しておくとサポート負荷が下がります。

  • ログと監査
    OTP利用や失敗のログを記録し、異常な試行を検出したらアラートを上げ、必要なら追加の認証を要求する仕組みを作ると良いでしょう。

将来の方向性と代替技術

近年はOTPに替わる、あるいは補完する形でフィッシング耐性の高い認証方式(FIDO2 / WebAuthn)が普及しています。公開鍵暗号を使うこれらの方式は、認証器(セキュリティキーやプラットフォームバイオメトリ)で秘密鍵が端末外へ出ない構造で、フィッシングや中間者攻撃に対して強いのが特徴です。高いセキュリティを要するサービスでは、OTPに加えこれらの導入を検討すべきです。

まとめ

ワンタイムパスワードは導入コストと利便性のバランスが良く、多くのサービスで有効な二要素目として使えます。しかし「OTPだから安全」と過信せず、配信方式の選択、シークレット管理、試行制限、プロビジョニング時の保護、フィッシング対策などを総合的に設計することが重要です。特に高リスクな用途ではSMS単独は避け、認証アプリやハードウェアキー、あるいはFIDOなどのより堅牢な手法を組み合わせて採用することを推奨します。

参考文献