TOTP（一次性密碼）生成器
通過 Base32 格式的 TOTP 金鑰，在瀏覽器本地生成與 Google Authenticator 等應用相同的 6 位一次性密碼（RFC 6238）。金鑰絕不會被發送到伺服器。
本工具絕不會將金鑰傳送至任何伺服器。Base32 解碼與 HMAC 計算均在您的瀏覽器內（Web Crypto API）完成，因此可以放心輸入身份驗證資訊。
關於 TOTP 演算法
TOTP（基於時間的一次性密碼）是 RFC 6238 中定義的、基於時間生成一次性密碼的演算法。它將共享金鑰與當前時間轉換為按固定間隔遞增的計數器，再使用與 HOTP（RFC 4226）相同的動態截斷演算法推匯出數字驗證碼。
| HMAC 演算法 | 可選擇 SHA-1（預設）、SHA-256 或 SHA-512 |
|---|---|
| 驗證碼位數 | 6 位（與 Google Authenticator 等主流雙重驗證應用相同的標準位數） |
| 更新週期 | 每 30 秒切換為新的驗證碼 |
使用提示
- 金鑰就是首次註冊雙重驗證（2FA）時，二維碼下方顯示的“設定金鑰”字串。如果您已在手機驗證器應用中註冊過，只需在此工具中輸入相同的金鑰即可核對驗證碼是否一致。
- 部分服務採用的雜湊演算法並非 SHA-1（而是 SHA-256 或 SHA-512）。如果生成的驗證碼與實際應用不一致，請嘗試切換演算法再試。
- 驗證碼每 30 秒自動更新一次，進度條可以直觀顯示剩餘時間。請注意，如果在即將切換前複製驗證碼，可能在送達驗證方之前就已失效。
- 關閉瀏覽器標籤頁後，金鑰會被徹底丟棄，不會儲存在任何地方。如果需要作為備份保留，請另行將金鑰本身儲存在密碼管理器等安全的地方。
常見問題
是的。Base32 解碼與 HMAC 計算全部在瀏覽器內通過 Web Crypto API 執行，絕不會發送至伺服器。您可以通過監控網路通訊來確認輸入的金鑰並未被發送出去。
這可能是雜湊演算法不一致（多數服務使用 SHA-1，但部分服務使用 SHA-256 或 SHA-512），或裝置時間存在偏差所致。請先嚐試切換演算法，如果仍然不一致，請檢查裝置的時間設定（自動時間同步）。
通常認為 TOTP 更安全。簡訊驗證碼存在因電話號碼被劫持（SIM 卡交換詐騙）而被第三方截獲的風險，而 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 改用任何人都能參照的統一基準——“當前時間”，大幅簡化了運維流程。