動的パスワード(OTP)の仕組みと実践ガイド:HOTP/TOTP・SMS・プッシュ認証・FIDO2で認証セキュリティを強化

動的パスワード(ワンタイムパスワード)とは何か

動的パスワードは、1回限り、または一定時間のみ有効な使い捨ての認証コードを指します。英語では「One-Time Password(OTP)」と呼ばれ、静的なパスワード(ユーザーが覚えて使い続けるもの)に比べて盗用・再利用のリスクが低いのが特徴です。オンラインバンキング、企業のVPNアクセス、クラウドサービスの二要素認証(2FA)などに広く用いられています。

主な技術と仕組み

  • HOTP(イベントベース)
    RFC4226で定義された方式で、サーバー・トークン双方がカウンター値(C)を共有し、共通鍵KでHMACを計算してから一連の手順で指定桁数の数字を切り出します。式としては概念的に「OTP = Truncate(HMAC-SHA-1(K, C)) mod 10^Digits」です。カウンターはトークン使用時にインクリメントされます。

  • TOTP(時間ベース)
    RFC6238で標準化された方式で、カウンターの代わりに時刻ベースの値(T = floor((UnixTime − T0) / X))を使います。一般に30秒刻み(X=30s)が広く使われ、トークンとサーバーは時刻のズレ(drift)を一定ウィンドウで許容します。

  • SMS/音声ワンタイムパスワード
    サーバーが生成したワンタイムコードをSMSや音声通話でユーザーの電話に送信します。実装は容易で普及してきましたが、SIMスワップや携帯ネットワークの脆弱性(SS7など)によるリスクが指摘されています。

  • プッシュ認証/プッシュ通知
    サーバーが認証要求をユーザーの登録済みアプリにプッシュし、ユーザーは許可・拒否や生体認証で応答します。即時性とユーザビリティに優れますが、端末の盗難やマルウェアによる不正承認リスクは考慮が必要です。

  • ハードウェアトークン
    物理デバイス(HOTP/TOTP対応の鍵トークン、表示器付きトークン)です。秘密鍵がデバイス内に保存されるため、端末盗難やコピーの難易度が高く、企業向けに信頼されます。

アルゴリズムとパラメータ(実装上の要点)

  • 共通鍵とハッシュ
    HOTP/TOTPは基本的にHMAC(通常はSHA-1が規格上のデフォルト)を用います。RFC6238はSHA-256/512の利用も許容していますが、利用するアルゴリズムに応じて鍵長を十分確保してください。

  • 桁数と有効期限
    OTPの桁数は6〜8桁が一般的です。桁数が増えるほど総当たり攻撃の難易度は上がりますが、ユーザービリティとの兼ね合いがあります。TOTPでは一般に30秒のタイムステップを用い、サーバー側で±1ステップ程度の許容ウィンドウを設けることが多いです。

  • 同期と誤差許容
    TOTPは端末とサーバーの時刻同期に依存します。NTPを用いた時刻補正や、サーバー側でのウィンドウ管理、同期再登録フローを用意してください。

  • シークレットの管理
    シークレット(ユーザーごとの鍵)は暗号的に安全に生成・保管する必要があります。平文で保存せず、鍵管理システム(HSMやKMS)の導入、暗号化・アクセス制御、監査ログを整備してください。

利点

  • 盗用リスクの低下:静的パスワードの流出だけでは認証できない。

  • 使い捨てであるためリプレイ攻撃に強い(適切に設計された場合)。

  • 導入コストが比較的低く、既存の認証フローに組み込みやすい(特にTOTP/SMS)。

主な脅威と限界(なぜ“万能”ではないか)

  • フィッシングとリアルタイム中継攻撃
    攻撃者がユーザーからOTPを取得して即座に正規サーバーに渡す「中継(man-in-the-middle)型フィッシング」が実際に行われています。TOTPやSMSもこれには無力です。MFAでも「フィッシング耐性(phishing-resistant)」が重要です。

  • SIMスワップとキャリア脆弱性
    SMSや音声によるOTPは、携帯番号の不正移管(SIMスワップ)や携帯網の脆弱性(SS7など)によって傍受されるリスクがあります。これらの理由で規格・ガイドラインはSMSのみの利用を推奨しない方向にあります。

  • 端末マルウェアとキー押下ログ
    トークンを動作させる端末がマルウェアに感染していれば、OTPの表示(スクリーンショット)やプッシュ承認の不正操作が起き得ます。

  • 再利用の防止、同期問題
    HOTPではカウンター同期がズレるとログインできなくなる可能性があり、TOTPは時刻ずれの問題があります。適切な同期メカニズムとユーザー向けの復旧手順が必要です。

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

  • NIST SP 800-63B等のガイドラインを参照し、SMSのみの利用は避け可能であればアプリ・ハードウェア系に移行する。

  • シークレットはHSMやクラウドKMSで保護し、アクセス制御・監査を厳格にする。

  • レート制限、失敗回数のロック、OTPの短期間有効化、および再利用禁止を実装する。

  • バックアップコードや代替認証手段(ハードウェアキー、サポートによる本人確認)を用意するが、これらの保護も忘れない。

  • QRコードによるプロビジョニングの際は盗聴を防ぐ(HTTPS、ワンタイム的なトークン化など)。

  • ユーザ向けにフィッシングの警告、プッシュ通知を無効化する際の手続き明示などを行う。

  • 監査とログ:OTP要求・承認のログを残し、不審なパターンを監視する。

より安全な代替/補完技術

  • FIDO2 / WebAuthn / U2F(公開鍵認証方式)
    公開鍵暗号を使った認証は、フィッシングや中継攻撃に強い「phishing-resistant」な手法です。ユーザーの秘密鍵はデバイス(セキュアエレメント/TPM)に保持され、サーバーは公開鍵のみを保持します。GoogleやYubicoの事例で高い安全性が実証されています。

  • 多要素の組み合わせ
    OTPを一要素として残しつつ、デバイス認証やリスクベース認証(ログイン時のリスクスコアリング)を組み合わせることで安全性を高められます。

導入時のチェックリスト(開発者・運用者向け)

  • どのOTP方式を使うか(HOTP/TOTP/SMS/プッシュ/ハードウェア)を明確にする。

  • シークレット生成方法と保存方法(暗号化、KMS/HSM)を決める。

  • 失敗時のロックやレート制限、アカウント復旧フローを設計する。

  • 同期(時刻/カウンター)運用と予期せぬズレへの対処を実装する。

  • ユーザー教育(フィッシング対策、セキュリティ意識)を行う。

  • 外部攻撃(SIMスワップ、SS7、フィッシング中継)に対する検出・防御策を整える。

まとめ

動的パスワード(OTP)は静的パスワードよりはるかに強力な認証手段であり、導入コストも比較的低いことから多くのシステムで標準になっています。しかし、全ての攻撃に耐えるわけではなく、特にフィッシングやキャリア側の脆弱性には注意が必要です。可能であれば、よりフィッシング耐性の高いFIDO2などの公開鍵ベースの方式の採用を検討し、OTPを使う場合でも鍵管理、レート制限、復旧手順、ユーザー教育などを組み合わせて総合的にセキュリティを高めることが重要です。

参考文献