TOTP & HOTP

TOTP（時間ベースのワンタイムパスワード、RFC 6238）とHOTP（HMACベースのワンタイムパスワード、RFC 4226）は、2FAの登録QRが実装する2つのRFCです。エンコードされた otpauth:// URIスキームはGoogle Authenticatorのデファクトスタンダードであり、すべての主要な認証アプリで互換性があります。

概要

2FAの登録QRは、共有シークレットと識別メタデータを持つ otpauth:// スキームのURLです。フォーマット:

otpauth://TYPE/LABEL?secret=SECRET&issuer=ISSUER&algorithm=ALG&digits=N&period=SEC

• TYPE, totp（時間ベース）または hotp（カウンターベース）。
• LABEL, Issuer:Account、URLエンコード済み。例: GitHub:alice@example.com。
• secret, 共有キー、Base32エンコード（RFC 4648 §6のアルファベット: A-Z、2-7）。
• issuer, 認証アプリに表示されるサービス名。ラベルを解析しないアプリのUXを改善するためにラベルと冗長になります。
• algorithm, SHA1（デフォルト）、SHA256、または SHA512。すべての認証アプリがSHA1をサポート。SHA256/SHA512は少数のみ。
• digits, 6（デフォルト）または 8。ほとんどのコンシューマーアプリは6を期待します。
• period, TOTPのみ。30（デフォルト）または 60秒。HOTPには代わりに counter パラメーターがあります。

標準テストベクター

ライブBase32シークレットバリデーター

認証アプリはBase32アルファベット（A-Z、2-7）以外の文字を含むシークレットを拒否します。以下はTOTPジェネレーターがインラインで実行するバリデーターと同じものです。ブラウザで実行されます。

よくある落とし穴

• Base32はBase64ではありません。 Base64はA-Z、a-z、0-9、+、/を使います。小文字や0、1、8、9がシークレットに含まれる場合は、Base64文字列が渡されており、すべての認証アプリで拒否されます。
• シークレット長。 RFC 4226 §4はHOTPには少なくとも128ビット（26 Base32文字）、TOTPには160ビット（32文字）を推奨します。80ビット（16文字）未満のシークレットは技術的には合法ですが、弱いとフラグが立てられます。
• アルゴリズムのサポートは異なります。 Google Authenticatorは algorithm パラメーターを無視して常にSHA1を使います。SHA256/SHA512が実際に有効になるには、ユーザーが1Password、Authy、Bitwarden、またはMicrosoft Authenticatorを使用している必要があります。
• 桁数のサポートは異なります。 ほとんどの認証アプリは digits=8 を無視して6に切り詰めます。8桁のOTPが重要な場合は、導入前にターゲットの認証アプリでテストしてください。
• ラベルをURLエンコードしてください。 issuerやアカウント内の特殊文字（:、@、スペース）はラベルでパーセントエンコードする必要があります。そうしないと古い認証アプリはラベルを完全に削除します。Abunderaはこれを自動的に処理します。
• シークレットを再利用しないでください。 すべてのアカウントに新しい暗号論的にランダムなシークレットが必要です。サービス間でシークレットを再利用すると、1つの漏洩ですべてのサービスが危険にさらされます。
• ストレージはQRよりも重要です。 QRは一回限りのブートストラップです。認証アプリは最初のスキャン後にシークレットを保存します。そのシークレットが後にプレーンテキストでエクスポートされると（一部の認証アプリはこれを行います）、ディスク漏洩でもすべての2FAが危険にさらされます。

認証アプリの互換性

関連ページ

• /totp-2fa-qr-code/, Base32バリデーターが内蔵されたTOTPジェネレーター。
• /hotp-qr-code/, HOTPカウンターベース版。
• /standards/, 規格インデックスに戻る。

仕様リファレンス確認済み 2026-04-18。RFC 6238（2011年）、RFC 4226（2005年）、Google Key URI Format。