Skip to content

MS_OneTimePassword

Jump to bottom
nishi_74322014 edited this page Aug 4, 2026 · 1 revision

ワンタイム・パスワード

概要

  • ASP.NET Core Identityで、TOTP がサポートされていたので調査した。

  • ワンタイム・パスワードのコンテキストでトークンと言うと、
    ワンタイム・パスワードを生成する機器と言う意味になる。

補足: 同じ「トークン」でも、 クレームベース認証 の文脈では セキュリティ トークン（データ）、 ここでは ハードウェア トークン（物） を指す。 混同しやすいので注意すること。

詳細

S/Keyと時刻同期方式

S/Key

≒ チャレンジ＆レスポンス

シーケンス

  1. ユーザ ID を送信
  2. Seed ＋「初期値（最大値） or 保存しているカウンタ値 − 1」を返信
  3. S（= Seed ＋ Password）をカウンタ値回ハッシュ関数にかけ OTP として送信
  4. ハッシュ値の比較（妥当性検証）
    • 初回は初期値（最大値）回分のハッシュを自力で計算して比較
    • 初回以降は前回 OTP をハッシュ関数にかけて比較（サーバ負荷軽減）
  5. 比較して＝だった場合、認証 OK を返信

補足: S/Key の要点は「ハッシュの一方向性」である。 N 回目には「N 回ハッシュした値」を送るため、 盗聴した値から次（N−1 回）の値は求められない。 ただしカウンタを使い切ると再登録が必要であり、 後述の脆弱性もあって、現在は使われていない。

時刻同期方式

  • 特許対象で、詳細が一般に公開されていない

  • 難解さに基づくセキュリティに依拠している。

  • 専門家によって理論的に安全性が確認されていない。

  • 以下の様な方式で実装されているらしい。

    1. ユーザ名を送信
    2. パスコード要求を返信
    3. トークンの生成したパスコード（トークンコード＋個人識別番号（PIN））を送信
      ※ PIN が NW 上に流れないようトークンに PIN を入力して、
      パスコードを生成する方式もある。
    4. 認証サーバでも同様の方法でパスコードを生成して比較
    5. 比較して＝だった場合、認証 OK を返信

移行メモ（補足）: ここで念頭に置かれているのは RSA SecurID である。 「難解さに基づくセキュリティ」＝ security by obscurity への批判は妥当で、 実際 RSA は 2011 年に SecurID のシード値が流出する侵害を受け、 トークンの大規模交換に至っている。 アルゴリズムを公開して検証に晒す TOTP が 現在の主流になったのは、この教訓によるところが大きい。

なお、元ページの「個人情報番号（PIN）」は 個人識別番号（Personal Identification Number） の誤りである。

TOTPとHOTP

HOTP

  • カウンターベースの OTP（HOTP: HMAC-based One-Time Password、RFC 4226）
  • HMAC を使用したカウンタ値と秘密鍵から 6 桁 decimal の OTP を生成するアルゴリズム
  • カウンタ値に関する仕様は任意で明記されていない。

TOTP

  • 時間ベースの OTP（TOTP: Time-based One-Time Password、RFC 6238）
  • HOTP のカウンタ値を UNIX エポック間隔（30 秒など）で取得。

補足: 実装上の要点。

  • 時刻ずれの許容が必要である。 一般に前後 1 ステップ（±30 秒）を許容する。 サーバの時刻同期（NTP）がずれていると全員が認証できなくなる。
  • 再利用の防止が必要である。 同一ステップ内の OTP は 30 秒間有効なので、 一度使った値は記録して拒否しないと、 盗聴した値をその場で使い回される。
  • 共有シークレットは Base32 で表現し、 otpauth://totp/... 形式の URI を QR コードにして登録する。

.NET では Rfc6238AuthenticationService（ASP.NET Core Identity 内部） や OtpNet などのライブラリを使う。

脆弱性

ワンタイム・パスワード方式の脆弱性。

サーバ認証

サーバー自体の認証機能が無い。

補足: これが OTP 最大の弱点である。 ユーザは「本物そっくりの偽サイト」に OTP を入力してしまい、 攻撃者はそれを即座に本物のサイトへ中継できる （リアルタイム フィッシング / AiTM）。 OTP は多要素認証ではあるが、フィッシング耐性は無い。

フィッシング耐性を得るには、 接続先のオリジンに鍵を紐づける仕組み、すなわち FIDO2 / WebAuthn やパスキーが必要である。 現在、重要な系では OTP からの移行が進んでいる。

紛失・漏洩

  • トークンの紛失
  • パスフレーズの漏洩
  • 個人識別番号（PIN）の漏洩

カウンタ管理方式

（再生攻撃対策がない場合）

  • ログイン試行回数
    OTP で認証されない限り、カウンタが更新されないので
    ブルートフォース攻撃できる。

  • 時間式
    特定の時間内ならカウンタが同じなのでブルートフォース攻撃できるが、
    時間間隔が短いので、ログイン試行回数式よりセキュリティが強化される。

補足: 6 桁 = 100 万通りしかないため、 レート制限とロックアウトは必須である。 RFC 4226 でも試行回数の制限（throttling）が要求されている。

比較

以下の様に言わないと製品売れないしね（恐らく試験には出ません）。

TOTP/HOTP 時刻同期方式トークン
開始するコスト 安い 高い
耐タンパー性 低い 高い

※ 耐タンパー性: コンピュータシステムの内部構造の解析、見破られ難さ。

補足: この比較は「ソフトウェア トークン（スマホ アプリ）vs ハードウェア トークン」の比較として読むと解りやすい。 TOTP 自体はハードウェア トークンでも実装できるため、 耐タンパー性の差はアルゴリズムではなく実装形態に由来する。

LoA(Level of Assurance) の AAL では、 Lv.2 が「ソフトウェアベースで可」、 Lv.3 が「ハードウェアを用いたもの」と区分されており、 この差がそのまま要件になっている。

参考

Tags: IT国際標準, 認証基盤

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally