摘要：隨着互聯網密碼泄露事件頻發，越來越多的產品開始支持多因子認證（MFA），TOTP則是MFA領域里最普遍的一種實現方式，本文介紹TOTP的原理和華為雲的實踐經驗。
原理
TOTP（Time-Based One-Time Password）算法是基於時間的一次性密碼算法，根據預共享的密鑰與當前時間計算一次性密碼。它已被互聯網工程任務組接納為RFC 6238標准，成為主動開放認證的基石，並被用於眾多多因子認證系統當中。
TOTP其實並不是一種全新的算法，可以看成是HOTP（HMAC-Based One-Tme Password）算法的一個具體化的場景。HOTP的算法可以在RFC 4226看到詳細描述，所以相比HOTP算法，TOTP的RFC文檔看起來非常簡潔。
上面是HOTP算法的公式，參數K表示共享密鑰，參數C表示計數器counter。
TOTP算法實際上是以時間變量作為參數C的HOTP算法，所以TOTP算法的公式應該是
參數K仍然表示共享密鑰，而參數T表示時間變量。
時間變量T
TOTP的核心和實踐方案也是圍繞時間變量T，但T不是簡單的時間戳，
X表示步長，默認是30秒，T0表示UTC時間的起始時間戳，即1970年一月一日，Floor函數向下取整。T必須是一個大於32bit的整型，才能支持到2038年以后。例如當X=30時，59對應的T為1，60對應的T為2。
TOTP在MFA上的應用
MFA（Multi-Factor Authentication），多因子認證，是計算機系統中一種進行身份認證的方法，用戶需要通過兩種或兩種以上的認證手段的校驗才能進入系統，訪問資源。
開通MFA一般都需要先在登錄認證系統中將用戶的身份和用戶的物理設備進行綁定關聯，在登錄過程中，除了輸入密碼（用戶知道的），還需要輸入用戶的物理設備（用戶持有的）上顯示的訪問碼（passcode）來完成整個身份驗證。說明：不是所有的MFA驗證過程都需要用戶主動輸入訪問碼。
上圖示意的過程即MFA的通用流程，例如我們使用網銀進行轉賬就需要拿出在銀行窗口開戶時銀行提供的一個U盾，按下按鈕，U盾上即顯示一串數字，輸入這次數字到網銀軟件上才能完成轉賬。
但上圖的MFA流程存在一個工程難題，即第4步中認證系統后端還需要向MFA設備（或MFA設備的后台系統）進行一次驗證，這個驗證過程限制了MFA的應用場景，運行在企業數據中心的認證服務器一般不被允許訪問公網，即使訪問公網也會因為網絡時延導致登錄體驗變差，TOTP算法的應用很好的解決了這個難題。
使用TOTP算法，只要客戶端（證明方）和服務端（校驗方）保持時鍾一致，且雙方預先設置好一個共享密鑰的前提下，在同一個時間片段內算出來的值是一樣的。正是基於這樣的原理，在認證系統中先將用戶身份和該共享密鑰綁定，再將共享密鑰置入物理設備，在認證過程中，物理設備和認證系統各自通過TOTP算法根據共享密鑰和時間戳計算出訪問碼，只要訪問碼對比一致就能證明用戶持有該物理設備，整個認證過程中物理設備和認證系統不需要有交互，非常靈活。
基於TOTP算法的設備，可以分為虛擬（軟件）MFA和硬件MFA。
虛擬MFA
虛擬MFA即通過軟件來模擬硬件MFA設備，在手機上安裝一個支持TOTP協議的APP，例如Google Authenticator, Microsoft Authenticator，華為雲APP也同樣支持標准的TOTP協議。虛擬MFA通過掃碼二維碼圖片或者手工輸入的方式置入校驗方生成的共享密鑰，並且可以同時關聯多個校驗方，非常方便實用。
硬件MFA
下圖中是一種信用卡形狀的硬件MFA，可以放到錢包里，在需要時按下卡片上的按鈕即可顯示六位數字，非常便攜。
安全考慮
1.哈希算法
TOTP算法的強度取決於背后的HOTP算法，但HOTP的哈希函數是HMAC-SHA1，並不是我司推薦的安全算法。TOTP算法在具體實現中也可以使用HMAC-SHA256或HMAC-SHA512，但使用HMAC-SHA1仍然是最通用，兼容性最好的實現，Google Authenticator就是使用HMAC-SHA1。
2.密鑰隨機性
對TOTP算法最可能的攻擊手段就是暴力破解，因此共享密鑰必須是密碼學安全的密鑰，足夠隨機。密鑰長度應該和哈希算法的長度盡量匹配。
另外，校驗方必須將密鑰存放在安全的區域，使用加密方式保存，防止泄露，只有在需要驗證OTP的時候才解密。同時還需要限制最小權限，只有校驗方自身才能拿到密鑰。
3.通信安全
證明方和校驗方應該使用安全的通道通信，例如SSL/TLS。
4.防暴力破解
一般TOTP用於MFA時，校驗方只會要求輸入6位數字，很容易被暴力破解，在工程實踐中可以當第二因子的嘗試失敗達到一定次數后鎖定客戶端。
5.保持一次性
TOTP算法在同一個時間片段（例如，30s）內的輸出都是一樣的，如果同一個TOTP驗證已經成功驗證過一次，該驗證碼的第二次嘗試應該被拒絕，這樣才能保證OTP“一次性”的基本性質。
6.時間片段
時間片段越長，被破解的風險就越高，但考慮到證明方需要人工輸入驗證碼，應該留下足夠的操作時間。推薦使用30秒作為默認時間片段，在安全和易用性之間達到一個平衡。
可用性考慮
1.“后向兼容”
因為證明方和校驗方都是基於時間來計算OTP，如果證明方在一個時間片段的最后時刻發送OTP，在請求達到校驗方時，已經進入下一個時間片段，如果校驗方使用當前時間來計算OTP，肯定會匹配失敗，這樣會導致一定的失敗率，影響可用性。
校驗方應該不僅僅以接收請求的時間，還應該用上一個時間片段來計算TOTP，增強容錯性。不過，容錯窗口越長，被攻擊風險越高，“后向兼容”一般推薦不超過一個時間片段。
2.支持校准
證明方和校驗方的時鍾可能不完全一致，特別是很長一段時間沒有進行過TOTP認證，時鍾偏移導致匹配失敗。校驗方的認證系統可以提供一種校准（re-sync）的能力，讓證明方輸入TOTP驗證碼，校驗方往前計算兩個時間片段（60s），往后計算一個時間片段（29s），通過匹配結果記錄證明方的時鍾的偏差值，完成時鍾校准。在證明方以后發起驗證時，校驗方直接使用偏差值計算TOTP。但如果廠商已經支持足夠的“后向兼容”，校准不一定需要支持。