雙因素算法存疑
阿新 • • 發佈：2018-02-01
isp 而不是 1.5 情況下 div 等待 你是 參考 range
TS為間隔時間，假設從0秒開始，那麽當服務端的時間接近TS秒時，會出現什麽問題呢？
而不是從現在時刻往後的時間段(如now+29)。
如果出現超時，提示用戶重修獲取口令，就這麽簡單。
0x00 雙因素算法的原理
可以參考阮一峰老師的這篇文章，這裏主要對阮老師提供的算法存疑
TC = floor(unixtime(now) / 30)
0x01 問題
一開始覺得挺有道理的，看到評論提到算法是錯誤的。
你是看懂了，但你沒動手驗證過，這個算法沒法保證在30s內是相同的
舉個例子：
1510279844
1510279845
這2個時間戳只差了1s，但兩者除以30四舍五入後並不相等,望修正
汗顏啊，紙上得來終覺淺，絕知此事要躬行，動手驗證後，發現果然算法是錯的。
雙因素驗證一般情況下，是服務端已經生成好了口令，然後客戶端再生成一個口令，並提交給服務端驗證。
TS為間隔時間，假設從0秒開始，那麽當服務端的時間接近TS秒時，會出現什麽問題呢？
服務端 TC = floor(now/TS) = 0
客戶端 TC = floor((now+TS-1)/TS)= 1 //假設在TS秒前一秒客戶端生成一個TC
這裏出現了一個大問題，當服務端的時間接近TS的整數倍時(實際上只要超過TS/2，客戶端等待TS/2後生成)，就會出現兩邊的TC不相等。
0x02 解決思路
當服務端的起始時間大於TS/2時，使用兩個TC，一個是原始的TC，一個是TC+1，防止出現超時。
但是這樣又出現另外一個問題，客戶端再超過1.5TC後，仍然會驗證通過（如服務端時間為14秒，客戶端時間46秒，TS為30秒）
而不是從現在時刻往後的時間段(如now+29)。
如果出現超時，提示用戶重修獲取口令，就這麽簡單。
0x03 擴展
如果有一個函數y=f(x)，當 x0<=x<=x0+TS，取值都相同，那麽就可以做到現在的時刻往後+TS 的計算了。
然而回想起函數的定義，一個x和一個y要一一對應，而這個顯然不符合函數的定義了，因為一個x會出現多個y。
看來只能做到連續時間段的校驗了，另外看到有雙因素驗證有人提到窗口期，和我的解決思路類似，即多求一個TC。
雙因素算法存疑