Google Authentication 機制原理

Google Authenticator，谷歌身份認證器，Google公司推出的一款動態口令工具，旨在解
決大家Google賬戶遭到惡意攻擊的問題。該工具主要基於TOTP（Time-Based One-Time Password
，基於時間的一次性密碼）算法。


需求：攻擊者在通過某種方式持有了用戶的用戶名和密碼組合，就可以登錄用戶賬戶並進行
操作。為了增強用戶賬戶安全性，保護用戶數據不被獲取和利用，產生了該身份認證機制。

 
使用場景描述：用戶持有一部安裝有客戶端的移動設備，服務器端驗證用戶賬戶信息，確認
用戶身份后允許用戶登錄。客戶端輸入了用戶的賬戶名、密碼后，還需要客戶端生成一個隨
時間變化的一次性動態口令並要求用戶輸入，發送給服務器。服務器接收到用戶輸入的信息
后，在驗證用戶名、密碼的基礎上，再計算自己的動態口令值並和用戶數據對比，匹配成功
后允許用戶登錄成功，否則失敗。

以下為該機制的原理分析：
（1）HOTP算法分析。Google Authenticator機制主要基於TOTP算法來實現的，而TOTP算法
本身是基於HOTP（HMAC-based One-Time Password，一種基於HMAC的一次性口令算法）算法
改進的。算法核心內容包括三個參數：一個雙方共享的密鑰（一個比特序列）K，用於一次
性密碼的生成；雙方各持有一個計數器C，並且實現將計數值同步；一個簽署函數即如下公
式：HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))，上面使用了HMAC-SHA-1，也可以使用HMAC-MD5
等。簡單步驟如下：
1、客戶端利用持有的密鑰K和計數器數值C，通過上述算法公式生成HOTP值，同時計數器值
加1，然后要求用戶輸入該HOTP值，然后客戶端將用戶名、密碼，連同生成的HOTP值發送給
服務器；
2、服務器獲取到客戶端發送的信息，解析並驗證用戶名、密碼，然后服務器利用持有的密
鑰及自身的計數器數值C，通過相同的算法生成HOTP值，再與客戶端的HOTP值對比，如果成
功，則計數器值加1，並允許該客戶端登錄用戶賬戶，否則拒絕登錄。

算法存在的問題：客戶端每次請求生成一次性密碼操作都會使得計數器值加1，而同時如果
驗證失敗或者客戶端不小心多進行了一次生成密碼操作，那么服務器和客戶端之間的計數器
C將不再同步，因此需要有一個重新同步（Resynchronization）的機制。由於該重同步機制
對於TOTP算法分析沒有太多幫助，因此在此不再贅述，需要了解重同步機制詳細的，請參看
RFC4226。

（2）TOTP算法分析。利用HOTP算法，將其中的計數器C用當前時間T來替代，同樣可以得到
隨着時間變化的一次性密碼，並且減小計數器的代價，畢竟更多的使用場景中獲取系統時間
是方便的。TOTP算法的三個核心內容也容易理解了：共享密鑰K；客戶端與服務器的時間同
步；簽署函數TOTP = Truncate(HMAC-SHA-1(K, (T - T0) / X))，其中T0是Unix epoch（1970
年1月1日 00:00:00），X為時間分片長度。算法執行流程大致如HOTP算法，不再贅述，不同
的是，本算法中用系統時間T代替了計數器數值C作為HMAC算法的輸入。

 需要注意的有幾點：1、HMAC算法得出的值位數比較多，不方便用戶輸入，因此需要截斷
 （Truncate）成一組不太長的是進制數（至少6位）2、由於時間是一直動態變化的，這就導
致服務器接收到客戶端的消息，再進行TOTP值的計算時，時間上會有延時。因此，需要將時
間划片，當然，時間划片要合理，過短導致用戶來不及輸入並傳輸給服務器驗證，過長導致
攻擊者有足夠的時間對用戶賬戶進行攻擊。Google默認的采用30秒時間分片，即每過三十秒，
系統時間T的值就會發生變化，得到的動態口令也不相同。3、同樣利用系統時間的TOTP算法
也是需要重同步機制。由於網絡延時、用戶輸入延遲等因素，可能服務器端接收到一次性密
碼時，T數值已經發生了變化，這樣就會導致驗證失敗。解決方法是，服務器計算當前時間
片以及前面的n個時間片內的TOTP值，只要其中有一個與用戶輸入的TOTP值相同，則驗證通
過。同時也容易理解，n不能設置過大，否則將會降低安全性。該方法還有另外的功能，有
時候客戶端與服務器的時鍾會有偏差，這樣也會造成上面類似的問題。但是如果服務器通過
計算前n個時間片的密碼並且成功驗證之后，服務器就知道了客戶端的時鍾偏差。因此，下
一次驗證時，服務器就可以直接將偏差考慮在內進行計算，而不需要進行n次計算。

關於文中HOTP算法公式和TOTP算法公式的詳細實現，也可以參看RFC4226，其中對於算法通
用性的考慮而做的改進值得學習。

 
值得一提的是，由於利用了系統時間，在一般情況下，生成該動態口令內嵌與程序中，本身
是無需聯網的，並且系統時間普遍存在於各個設備中，算法通用性良好。

 一些總結：
1、無論是HOTP還是TOTP算法，都存在重同步問題。參考RFC4226可知，在前者的計數器C
重同步問題中，客戶端計數器的值可以預料到必然大於服務器計數器的值，在驗證過程中，
服務器向后計算N個HOTP值用來匹配一個客戶端HOTP值，驗證並通過。至於后者，TOTP
算法要求客戶端與服務器時間同步，並且服務器計算TOTP值時會向前計算N個TOTP值用來
匹配一個客戶端的TOTP值，從而保證了重同步。這是二者重同步問題中的區別。

2、由於上述的重同步方式，相對也會造成一定的系統安全性問題。同樣參考RFC4226，
兩種方式的系統服務器端，都會給服務器檢測HOTP/TOTP值設置一個閥值S，用來保證服務
器不會不停的檢測數值，從而限制了試圖制造HOTP/TOTP值的攻擊者的可能空間。