實施SCRAM - 隨機數驗證和服務器/客戶端密鑰

Question

技術上有兩個問題 - 但它們之間的關係如此密切，我不想將它們分開;但如果社區覺得我應該，我會的。

繼recent question我正在爲網站登錄和Web服務API實施SCRAM。客戶端環境將是.Net和Javascript（將來可能會有Java）。

我的第一個問題是基本的：The protocol utilises a client and server key作爲身份驗證過程中的關鍵步驟;然而爲了驗證，兩者都需要事先被雙方知道，因爲協議不允許交換這些信息（這樣做會導致一些雞雞和雞蛋的情況）。例如，如果您考慮一個Javascript客戶端，這意味着這兩個鍵都可能是在源代碼中定義的常量 - 這使得它們易於獲取。所以：爲什麼要麻煩？僅僅是爲了減輕'Eve'，因爲某些原因，'Eve'沒有打擾到JS或客戶端源代碼，而這些源代碼必須公開！？其次，像其他任何認證機制一樣，它需要客戶端+服務器隨機數。

鑑於認證隨機數，按照定義，不應該（同一用戶至少）使用一次以上，這大概意味着服務器必須維護所有用戶使用的所有現時值的記錄永遠 。與我們經常存檔的其他數據不同，這樣的表格只會變得越來越大，查詢反而會變得越來越慢！

如果這是正確的，那麼實施這個或幾乎任何其他認證機制在技術上是不可行的！因爲我知道這顯然是荒謬的;在合理的時間範圍內定義一些額外的範圍也是常見的。

與認證和加密一樣，儘管是一位非常有經驗的軟件開發人員，我覺得我要回到學校了！我錯過了什麼！？

Answer 1

都需要由雙方 提前知道，因爲協議不 允許這些交換（這樣做 會導致有點雞和蛋 情景）。

是的，這是正確的。挑戰反應不是密鑰交換協議。它只是規範，一旦客戶端和服務器共享一個密鑰，如何通過該密鑰計算出相同的值，而不通過網絡傳輸清除密鑰。

如果你考慮一個JavaScript客戶端， 例如，這意味着這兩個鍵是 可能是在 源定義的常量 - 從而使它們很容易 獲取。

這不是一個好主意。或者客戶和服務器可以在初步註冊過程中就密鑰達成一致。

鑑於認證隨機數， 按照定義，不應該（由同一 用戶至少）使用超過一次 多，這大概意味着一個 服務器必須維護所有 現時值的記錄所有用戶永遠使用 。

NO。應使用僞隨機數生成爲每個新會話生成一個新的隨機數。無論如何，如果攻擊者不知道它是否已被使用，那麼無論如何都會得到相同的nonce，這是非常不可能的。