Protocol-Design
RFC 6238/4226 的替代方案 - 通過 SMS 的一次性密碼(單因素身份驗證)
目前,我們已經實施了一次性密碼 (OTP) 作為第二次身份驗證,效果很好。我們使用 TOTP - RFC 6238
一些客戶希望有一個“僅簡訊”登錄,所以它是單因素身份驗證。在某些情況下(取決於數據)這很好。我們將通過 SMS 發送令牌,它不必與 OTP 應用程序兼容(例如 Google Authenticator)
我們認為 RFC 6238 (TOTP) 對於單因素身份驗證來說太弱了,因為時間組件會出現問題:
- 如果密碼長度為 30 秒,則在 30 秒內兩次登錄嘗試將給出相同的密碼
- 如果我們將時間更改為 1 秒,我們必須檢查多個“幀”
- 此外,密碼中的字母數字字元與 RFC 不兼容?
我們也知道有一個基於計數器的算法(HOTP - RFC 4226),但如果我們不能正確同步計數器(在伺服器之間),它們可能是安全問題。
因此,我們正在尋找一個 RFC 來生成具有以下要求的一次性密碼:
- 生成密碼,基於時間,無計數器
- 生成包含字母數字和數字字元的密碼
流程將是:
- 生成一次性密碼
- 將密碼儲存在(伺服器端)會話中(包括過期)
- 檢查令牌並清除會話。
我們可以使用以下程式碼來創建 OTP
- 生成隨機(安全)字節
- 轉換為文本
但這不符合 RFC,最好遵循 RFC。
我的問題:
- 我們可以使用另一個滿足要求的 RFC 嗎?
- 我們是否符合 RFC 6238,如果我們: 在短時間內(例如 1 秒)生成 TOTP,並將結果儲存在會話中。
假設我正確理解了您的要求,我的建議是使用 HOTP,但使用會話密鑰。
- 使用者在客戶端輸入他們的使用者名,然後發送到伺服器。
- 伺服器生成隨機鹽並將其發送給客戶端。
- 伺服器生成並儲存從長期密鑰和隨機鹽(例如使用 HKDF)派生的會話密鑰。
- 帶有會話密鑰的 HOTP 用於生成通過 SMS 發送的一次性密碼。
- 客戶端發送隨機鹽和使用者輸入的一次性密碼。
- 伺服器驗證它們是否匹配它儲存的會話密鑰。
由於僅使用一次性密碼不足以登錄,因此它應該比簡單地通過 SMS 發送令牌更安全。一半的秘密通過(希望)TLS 發送並儲存在客戶端記憶體中(無論是網頁還是應用程序),因此僅攔截 SMS 的人將無法登錄。
沒有時間步長。如果需要同時登錄,您可以選擇是否為每個使用者僅儲存一個會話密鑰或任何數量。
注意:請注意將會話密鑰與正確的使用者關聯,以便客戶端無法使用 salt+OTP 進行身份驗證。