TOTP ジェネレーター — 2FA コード生成と otpauth QR コード作成

Base32 のシークレットからカウントダウン付きで 2FA コードをリアルタイムに生成し、認証アプリ用の otpauth:// QR コードの作成や、既存の URI の読み取りができます。

シークレットキー（Base32）

スペースや小文字が入っていても問題ありません。160 ビットの鍵です。

アルゴリズム

桁数

更新間隔

現在のコード

— — —

前のコード — · 次のコード —

コードはデバイスの時計に依存します。コードが拒否される場合は、時計が自動設定になっているか確認してください。多くのサーバーは前後のコードも受け付けます。

otpauth:// URI と QR コード

発行者

アカウント名

otpauth://totp/Example%20Inc:jane%40example.com?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example%20Inc&algorithm=SHA1&digits=6&period=30

Google Authenticator、Microsoft Authenticator、1Password、Authy などの TOTP アプリで読み取れます。多くのアプリは SHA-256/512 や 8 桁を無視するため、両側を管理している場合を除き、デフォルトのままにしてください。

otpauth:// URI を読み込む

URI を貼り付け（QR コードリーダーで読み取ったものなど）

シークレットとコードはブラウザ内にとどまり、送信や保存はされません。TOTP のシークレットはパスワードと同じように扱ってください。持っている人は誰でもあなたのコードを生成できます。すべての無料ツールを見る.

不具合や改善できそうな点を見つけましたか？いただいたメッセージはすべて読み、すぐに対応します。

この TOTP ジェネレーターは、Google Authenticator、Microsoft Authenticator、1Password などの認証アプリと同じ、時間ベースのワンタイムコードを生成します。Base32 のシークレットを入力すると、現在の 6 桁または 8 桁のコードがカウントダウンとともに、前後のコードと並んで表示されます。アプリケーションに二要素認証を追加する開発者向けに作られており、シークレットを生成し、ユーザーが読み取る otpauth:// URI と QR コードを作成し、サーバーが受け付けるべきコードを受け付けるかを確認できます。

コードは、RFC 6238（TOTP）と RFC 4226（HOTP）に従い、WebCrypto の HMAC 関数を使ってブラウザ内で計算され、実装は両 RFC の公式テストベクターでテストしています。何もどこにも送信されません。それでも、TOTP のシークレットはパスワードと同じくらい機密性が高く、持っている人なら誰でも有効なコードを生成できます。テスト用アカウントや連携作業に使い、実際のアカウントの認証アプリの代わりにはしないでください。

使い方

Base32 のシークレットを貼り付けるか、「新しいランダムなシークレット」を押します。スペースや小文字が含まれていても問題ありません。
サーバーが別の設定を使っていない限り、アルゴリズム、桁数、周期は SHA-1、6 桁、30 秒のままにします。
現在のコードを確認します。リングは、あと何秒有効かを示しています。ボタンでコピーできます。
発行者とアカウント名を入力して otpauth:// URI を作成し、認証アプリで QR コードを読み取って、両方に同じコードが表示されるか確認します。
既存の設定を確認するには、その otpauth:// URI を読み取り欄に貼り付けて「読み込む」を押します。

よくある質問

TOTP コードはどのような仕組みですか？

サーバーと認証アプリは秘密鍵を共有しています。30 秒ごとに、両者は鍵と 1970 年 1 月 1 日からの 30 秒単位のステップ数から HMAC-SHA1 を計算し、その結果を 6 桁に縮めます。両者は同じシークレットと同じ時計を使うので、通信しなくても同じコードになります。これが RFC 6238 で、その土台となるカウンターベースのアルゴリズムが HOTP（RFC 4226）です。

TOTP コードが通らないのはなぜですか？

群を抜いて多い原因は、時計のずれです。約 30 秒を超えてずれると、端末が別のタイムステップに入ってしまいます。端末とサーバーの両方で時刻を自動で同期するように設定してください。他の原因としては、シークレットの入力ミス（Base32 は A〜Z と 2〜7 だけを使うので、O、I、0、1、8 は決して現れません）や、サーバーが 8 桁、SHA-256、60 秒の周期など別の設定を想定していることがあります。

TOTP の SHA-1 は安全ではないのですか？

安全です。SHA-1 の既知の弱点は衝突攻撃で、同じハッシュを持つ 2 つの入力を作れるというものです。TOTP は秘密鍵とともに HMAC の内部で SHA-1 を使っており、この構成は衝突耐性に依存しないため、安全なままです。SHA-1 が今も標準なのは、ほぼすべての認証アプリが対応しているからです。

otpauth:// URI とは何ですか？

2FA 設定用の QR コードの中にあるテキストで、もともと Google Authenticator が定義した Key Uri Format に従っています。otpauth://totp/Issuer:account?secret=BASE32SECRET&issuer=Issuer の形で、必要に応じて algorithm、digits、period のパラメーターが付きます。QR コードを読み取ると、この文字列がアプリに渡されるだけです。QR コードや URI を見た人は誰でもシークレットを手に入れられるので、設定画面は機密情報として扱ってください。

TOTP のシークレットはどれくらいの長さにすべきですか？

RFC 4226 は少なくとも 128 ビットを必須とし、160 ビット（Base32 で 32 文字）を推奨しています。「新しいランダムなシークレット」ボタンは crypto.getRandomValues で 160 ビットを生成します。古いサービスの多くは 80 ビット（16 文字）のシークレットを発行しており、それでも動作し、このツールは警告を表示しますが、新しいシステムでは少なくとも 160 ビットを使うべきです。

すべての認証アプリが 8 桁や SHA-256 に対応していますか？

いいえ。otpauth 形式では SHA256、SHA512、8 桁、他の周期を指定できますが、それらのパラメーターを無視して常に SHA-1、6 桁、30 秒のコードを生成するアプリもあり、その場合コードは一致しません。サーバーを管理しているなら、標準の設定が安全な選択です。標準以外の設定を採用する前に、ユーザーが使いそうなアプリでこのページの QR コードを読み取り、コードを比べてください。

自分のアプリケーションに TOTP を追加する

• サーバー側でユーザーごとに少なくとも 160 ビットのランダムなシークレットを生成し、ハッシュではなく暗号化して保存します。サーバーはコードの計算に元の値を必要とするからです。

• otpauth:// URI を QR コードとして表示し、読み取れないユーザーのために Base32 のシークレットもテキストで表示します。

• 2FA を有効にする前に有効なコードを 1 回入力させ、読み取りの失敗でユーザーが締め出されないようにします。

• 検証時は、現在のコードと、通常は前後 1 ステップ（ここに表示される前後のコード）を受け付けて時刻のずれを吸収し、その範囲内ですでに使われたコードはリプレイを防ぐために拒否します。

• 試行回数を制限します。6 桁のコードは 100 万通りしかないので、無制限に推測できれば突破されます。

• 登録時に使い捨てのリカバリーコードを発行し、パスワードと同様にハッシュ化して保存します。

TOTP と SMS コード、プッシュ通知、パスキーの比較

TOTP は、SIM スワップ攻撃や SS7 の脆弱性で傍受されうる SMS コードよりはるかに強力で、電話番号なしでオフラインでも使えます。弱点はフィッシングです。本物そっくりの偽のログインページがコードを求め、30 秒の有効期間内に本物のサイトへ中継できてしまいます。

プッシュ通知での承認は便利ですが、攻撃者がユーザーが承認をタップするまで通知を送り続ける「MFA 疲労」攻撃を招きます。パスキーとハードウェアのセキュリティキー（FIDO2/WebAuthn）は、ブラウザが認証情報を本物のサイトのドメインに結び付けるため、設計上フィッシングに耐性を持つ唯一の一般的な方法です。パスキーを最初に提供し、幅広く使える代替手段として TOTP を残しておくのが賢明なやり方です。