TOTP（一次性密碼）生成器
通過 Base32 格式的 TOTP 金鑰，在瀏覽器本地生成與 Google Authenticator 等應用相同的 6 位一次性密碼（RFC 6238）。金鑰絕不會被發送到伺服器。
關於 TOTP 演算法
TOTP（基於時間的一次性密碼）是 RFC 6238 中定義的、基於時間生成一次性密碼的演算法。它將共享金鑰與當前時間轉換為按固定間隔遞增的計數器，再使用與 HOTP（RFC 4226）相同的動態截斷演算法推匯出數字驗證碼。
| HMAC 演算法 | 可選擇 SHA-1（預設）、SHA-256 或 SHA-512 |
|---|---|
| 驗證碼位數 | 6 位（與 Google Authenticator 等主流雙重驗證應用相同的標準位數） |
| 更新週期 | 每 30 秒切換為新的驗證碼 |
什麼是 TOTP（一次性密碼）
TOTP（Time-based One-Time Password）是在帳號密碼之外再要求一道確認的雙因素驗證（2FA）中使用的、每30秒切換一次的6位一次性代碼。它由事先登錄的名為「密鑰（secret）」的共有金鑰與目前時刻組合計算而得，因此伺服器與手中的驗證應用程式無須通訊也能同時得出相同的代碼。Google Authenticator、Microsoft Authenticator、Authy 等主要驗證應用程式均遵循 RFC 6238 這一共通規格。
本工具只需輸入 2FA 登錄時顯示在 QR 碼下方的「設定金鑰」（Base32 形式的 secret），即可在瀏覽器內重現與驗證應用程式相同的6位代碼。金鑰的 Base32 解碼與 HMAC 計算全部由 Web Crypto API 完成，絕不會傳送至伺服器。可用於驗證應用程式的重新設定、代碼的核驗，以及多裝置上的運作確認等。
TOTP 代碼的產生方式
- 輸入密鑰 把 2FA 登錄時發放的 Base32 形式設定金鑰（例：JBSWY3DPEHPK3PXP）貼到「密鑰」欄。
- 確認雜湊演算法 多數服務使用 SHA-1；若不一致，請切換為 SHA-256 或 SHA-512 試試。
- 確認顯示的6位代碼 輸入的同時會自動計算與目前時刻對應的代碼，並連同剩餘秒數的進度條一起顯示。
- 視需要複製 可用「複製」按鈕把代碼複製到剪貼簿。請避開臨近切換的時刻使用。
用好本工具的小技巧
- 金鑰就是首次註冊雙重驗證（2FA）時，二維碼下方顯示的“設定金鑰”字串。如果您已在手機驗證器應用中註冊過，只需在此工具中輸入相同的金鑰即可核對驗證碼是否一致。
- 部分服務採用的雜湊演算法並非 SHA-1（而是 SHA-256 或 SHA-512）。如果生成的驗證碼與實際應用不一致，請嘗試切換演算法再試。
- 驗證碼每 30 秒自動更新一次，進度條可以直觀顯示剩餘時間。請注意，如果在即將切換前複製驗證碼，可能在送達驗證方之前就已失效。
- 關閉瀏覽器標籤頁後，金鑰會被徹底丟棄，不會儲存在任何地方。如果需要作為備份保留，請另行將金鑰本身儲存在密碼管理器等安全的地方。
TOTP 產生器派上用場的情境
2FA 應用程式的運作確認與移轉
在因換機而更換驗證應用程式之前，可先用本工具核驗留存的密鑰是否正確，而不必到新裝置上才發現問題。
開發、測試環境的登入確認
為自家服務實作 2FA 時，可隨時由測試帳號的密鑰產生代碼，用於驗證邏輯的運作確認。
備份用密鑰的驗證
可在不開啟手機驗證應用程式的情況下，快速確認保存在密碼管理器等處的密鑰是否仍能正常運作。
與雜湊值的確認一併使用
若與 TOTP 一樣對 HMAC 或雜湊函數的原理感興趣，歡迎用SHA-256 雜湊計算嘗試作為基礎的雜湊計算。
TOTP 相關用語集
- TOTP（Time-based One-Time Password）
- 使用由目前時刻算出的計數器產生一次性密碼的方式（RFC 6238）。每隔一定週期（通常30秒）代碼會自動切換。
- HOTP（HMAC-based One-Time Password）
- TOTP 的前身規格（RFC 4226）。以「每次使用便前進一格的計數器」而非時刻來產生代碼。
- 密鑰（共有金鑰）
- 服務方與使用者驗證應用程式雙方共同持有的祕密金鑰。在 2FA 登錄時以 Base32 形式的字串發放，由它與時刻計算出代碼。
- 雙因素驗證（2FA）
- 在密碼（知識要素）之外，再結合智慧型手機驗證應用程式等（持有要素）確認的登入方式。即便一方外洩，也較易防止非法登入。
- 時間步長（更新週期）
- TOTP 代碼切換為新值的間隔。RFC 6238 的預設值為30秒，多數服務與驗證應用程式直接沿用該值。
- Base32
- 僅用英文大寫字母（A～Z）與數字（2～7）共32種字元來表示位元組序列的編碼方式。TOTP 的密鑰以這種可讀性高的形式發放。
- 動態截斷（Dynamic Truncation）
- 從 HMAC 計算結果（較長的位元組序列）中依規則取出4個位元組並轉換為6位數值的處理。是 RFC 4226 定義的 HOTP・TOTP 共通演算法。
常見問題
閒話 ― 雙重驗證為何最終定格為“6 位數”
制定 TOTP 規範（RFC 6238）的 OATH（開放身份驗證倡議組織）直接沿用了 HOTP（RFC 4226）的動態截斷演算法，並將驗證碼的位數交由各實現自行決定。之所以 6 位成為事實上的行業標準，主要是因為 Google Authenticator 在 2010 年的初始實現中採用了這一位數，此後眾多服務和庫都紛紛效仿。
6 位數字也恰好是一個絕妙的平衡點。一百萬種組合（10 的 6 次方）再加上短短 30 秒的有效期，使得暴力破解在現實中幾乎不可能實現；而位數再多則會讓使用者難以記憶和手動輸入。多數簡訊驗證碼同樣採用 6 位並非巧合，而是整個“短時效、一次性數字驗證碼”這一品類共同收斂出的經驗法則。
TOTP 的前身 HOTP（RFC 4226，2005 年）採用“計數器”方式，每使用一次驗證碼就必須將計數器遞增一次。然而由於使用者經常忘記操作，或者裝置與伺服器的計數器發生偏差，運維問題頻發。因此 2011 年制定的 TOTP 改用任何人都能參照的統一基準——“當前時間”，大幅簡化了運維流程。