仿新浪微盾客戶端項目簡介三

上節咱們說到，關於opt算法的說明，也說到這個項目是使用TOTP（基於時間）方法。  

這節講的主要把它怎麼整合項目中。整合項目中，此算法須要注意這麼幾點。

1. 與服務器端統一的準確時間

因爲是使用totp算法，客戶端與服務器端的算法是必需要保存一致的。

對時接口，獲取服務器端準確時間，返回{「svr_time」:1319512158}，以秒爲單位的時間戳。時間偏移量 = 本地時間 – 服務器端時間， 將時間偏移量保存在地SharePreference中，供計算動態密碼時讀取服務器端時間 = 本地時間 - 時間偏移量使用時間偏移量的好處是：只須要從服務器獲取一次時間，之後均可以離線使用微盾。

2. 靜態密鑰。

加密後靜態密鑰保存在本地，加密算法爲DES，一種對稱加密算法，支持加密解密密鑰 = 固定字符串 + 設備IMEI號碼

這個解密的密鑰有什麼做用了，是用於微盾兩邊安全性的提高了。這就引出一個話題，密鑰的做用。公鑰加密，保存在客戶端 不少個，用戶知道。私鑰解密，保存在服務器 只有一個，只有服務器知道。這種不對稱加密的方式，大大的提高了破解難度。至於你們認爲，設備的IMEI號是否是畫蛇添足，在之後我會專門用一篇文章論述，這裏，就不作過多的贅述了。

有了這兩點的分析，咱們有了一個完美的設計方案:

有了準確的服務器時間和靜態密鑰，就能計算出正確的6位動態密碼

當用戶輸入動態密碼登陸時，服務器會使用一樣的時間和密鑰算出6位密碼進行比對。

服務器作了容錯處理，會計算出在某個時刻前1分鐘和後一分鐘的全部6位密碼，只要用戶輸入正確了其中一個，就算經過.

至於這個方法具體代碼，我準備是在Google一個開源項目Google Authenticator 修改。

下面的課程，咱們將進入具體的源代碼的說明。

用了3節的篇幅，說明了微盾概要設計和技術實現，不知道你們明白沒，請給予反饋。