2 段階認証アカウント
2 段階認証を有効にするためのシークレットとその QR コードを生成し、Google Authenticator、Microsoft Authenticator、Authy に表示されるはずの TOTP・HOTP コードを確認し、コードが有効かどうかを検証します。コードはブラウザ内で計算され、シークレットは共有リンクに含まれません。
コード

コードを表示するには有効なシークレットを入力してください。

アプリ用 QR コード
コードを検証

サーバーと同じ方法でコードを確認します。時刻のずれを許容するため、現在のコードに加えて前後 2 ステップまでのコードを受け付けます。

仕組み

TOTP (Time-based One-Time Password、RFC 6238) は、Google Authenticator、Microsoft Authenticator、Authy、1Password に表示される 6 桁のコードの背後にあるアルゴリズムです。サービスとスマートフォンはシークレットを共有しており、30 秒ごとに両者が現在時刻をステップに区切った値とシークレットから HMAC を計算し、6 桁に切り詰めて結果を比較します。コードは入力するまで誰にも送信されないため、スマートフォンがオフラインでも機能します。

HOTP (RFC 4226) は基本となるアルゴリズムで、時刻の代わりにコードを要求するたびに進むカウンターを使います。TOTP は、カウンターを 1970 年からの経過周期数に置き換えた HOTP です。シークレットは Base32 で表記され、2 段階認証を有効にするときに QR コードとして表示される otpauth:// URI に含まれます。

このツールは、ブラウザの暗号学的乱数生成器でシークレットを生成し、現在・前・次のコードを計算し、URI とその QR コードを作成し、既存の URI を読み取り、サーバーと同じ時刻ずれ許容範囲でコードを検証します。シークレットがブラウザの外に出ることはなく、共有リンクにも含まれません。

例

GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 59 s94287082RFC 6238 のテストベクター。シークレットは ASCII テキスト 12345678901234567890 を Base32 でエンコードしたものです。Unix エポックから 59 秒の時点でステップは 1 となり、8 桁のコードは正確にこの値になる必要があります。
GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 1111111109 s07081804RFC 6238 の別のベクター。実装が先頭のゼロを落としていないかを確認するのに便利です。コードは整数ではなく、固定桁数の数字列です。
HOTP · GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · contador 0755224RFC 4226 の 6 桁の最初のベクター。カウンターが 1 になるとコードは 287082 になります。
otpauth://totp/Ejemplo:ana%40example.com?secret=JBSWY3DPEHPK3PXP&issuer=EjemploTOTP · SHA1 · 6 · 30 sGoogle Authenticator が定義し、他のアプリも採用した Key URI 形式。algorithm、digits、period が省略された場合は SHA1、6、30 とみなされるため、ほとんどの QR コードにはシークレットと発行者しか含まれていません。

ユースケース

  • アプリケーションの 2FA 有効化をテストする：シークレットを生成し、スマートフォンで QR コードをスキャンして、アプリに表示されるのと同じコードをサーバーが受け付けるか確認します。
  • サーバーが有効なコードを拒否する原因をデバッグする：前後のステップのコードと一致すれば、時計のずれが判明します。
  • 独自の TOTP・HOTP 実装を RFC 6238 と 4226 のテストベクターで検証する。
  • 別のアプリからエクスポートした otpauth:// URI を読み込み、アカウントが使うアルゴリズム、桁数、周期を確認する。
  • Base32 のシークレットが手元にあるテスト用アカウントを、2 台目のアプリやパスワードマネージャーに登録する。

よくある質問

アプリで有効と表示されるコードをサーバーが拒否するのはなぜですか？

ほとんどの場合、原因は時計です。TOTP はスマートフォンとサーバーの時刻が一致していることが前提で、30 秒ずれるだけで異なるステップを計算してしまいます。そのためサーバーは前後に 1～2 ステップを許容しています。コードが前後のステップと一致する場合は、サーバーの時刻を NTP で同期し、スマートフォンの時刻自動設定を有効にしてください。

実際のアカウントのシークレットをここで生成しても安全ですか？

シークレットは crypto.getRandomValues で生成され、ブラウザの外に出ることはありません。ただし本番環境では、コードを検証するサーバー側で生成・保存する必要があります。このツールはテストとデバッグ用です。実際のシークレットはパスワードと同様に扱ってください。それを持つ人は誰でも、あなたのコードを永久に生成できます。

SHA-256、8 桁、60 秒を使うべきですか？

理論上はより強力ですが、Google Authenticator の一部のバージョンを含む複数のアプリがこれらのパラメーターを無視し、常に 30 秒ごとに 6 桁の SHA-1 で計算するため、ユーザーにはサーバーが拒否するコードが表示されてしまいます。HMAC としての SHA-1 は依然として安全です。互換性のため、ほとんどのサービスはデフォルト値を使用しています。

シークレットの長さはどのくらい必要ですか？

RFC 4226 は 128 ビット以上を必須とし、160 ビット (Base32 で 32 文字) を推奨しています。多くのサービスは 80 ビット (16 文字) を使用しており、アプリもそれを問題なく受け付けます。このツールは 160 ビットを生成します。

TOTP はフィッシングを防げますか？

完全には防げません。傍受や SIM スワップによる乗っ取りが可能な SMS よりはるかに優れていますが、偽サイトがコードを要求し、同じ 30 秒以内に本物のサイトで使用することができます。FIDO2 セキュリティキーやパスキーはドメインに紐付いているため、この攻撃に耐性があります。

スマートフォンを紛失したらどうなりますか？

シークレットがなければコードを計算する方法はありません。そのため、サービスは 2FA を有効にする際にリカバリーコードを発行します。スマートフォン以外の場所に保管してください。一部のアプリでは、アカウントを暗号化してクラウドにバックアップしたり、QR コードとしてエクスポートして別の端末に移行したりできます。

関連項目