Implementation
為什麼 SRP 沒有被廣泛使用？
與現在使用的任何其他東西相比，SRP 似乎是一個非常好的密碼驗證協議。那麼為什麼沒有流行的實現，甚至沒有有效的安全實現呢？
我嘗試設置TLS-SRP 協議，但它對我不起作用。
當我了解 SRP 時，我們被告知由於可能侵犯了 EKE 專利，它沒有看到太多部署。網路計算在 2002 年曾這樣說：
標準組織曾多次嘗試誘使朗訊談論其 EKE 專利，但均無濟於事。即使朗訊對此話題保持沉默，也很少有供應商願意使用 SRP。為了進一步模糊這種情況，發布了一項新專利，聲稱它也涵蓋了 SRP。
然而，SRP 網站聲稱
由於 SRP 是專門為解決該領域的現有專利而設計的，它使每個人都可以使用強大的、不受阻礙的密碼身份驗證技術，該技術可以廣泛用於各種用途。
如果我不得不猜測，我會說專利是最初問題的一部分，這種影響直到今天仍在繼續。專利是否是限制部署的唯一原因，甚至是主要原因，我都無法理解。
問題是
- SRP 僅在密碼被鍵入一側的可信實現時才有用。當您開始通過 HTTPS 從伺服器獲取它時，有兩件事會成為薄弱的安全連結：
- 無端希望使用者不要輸入密碼，除非相應域名左側有綠色鎖；
- 證書鏈（在實踐中可以規避：從合法 CA 獲得流氓證書並不難；如果流氓證書被注意到，流氓 CA 更容易假裝善意頒發了流氓證書, 這需要特別注意。如果一個主要的 CA 被發現錯誤地簽發了包括www.google.com和www.gmail.com在內的 30000 個證書，我們可以信任證書鏈還是安全劇院？）。更新：另一個例子。
- 用 JavaScript 實現的 SRP 很慢（至少在缺少帶有 JIT 的 JavaScript 的客戶端上）；它在 Java 中是可以忍受的，但在瀏覽器中對 Java 的支持從未變得普遍。
- SRP 不能防止鍵盤記錄器或客戶端機器或軟體的其他危害；更糟糕的是，一旦客戶端機器受到某些惡意軟體的攻擊，假設的標準化 SRP 客戶端界面可能會成為惡意軟體收集登錄憑據的方便目標（由於 Web 界面過多，惡意軟體可以可靠地從其他使用者輸入中篩選登錄憑據） .
- 客戶端電腦上的 SRP 不提供雙重身份驗證。
- 與通過 HTTPS 發送密碼的做法相比，SRP 的好處只有在您假設伺服器或 HTTPS 受到威脅之後才會存在。
- 更新：標準化的 SRP 不能防止伺服器端數據洩露；有了這些數據，就可以測試密碼的有效性，讓字典中的密碼搜尋變得恐懼（以及技術進步/ECC 的使用積極地對抗安全性）。為了解決伺服器數據洩露的威脅（這是標準安全要求的一部分），SRP 需要輔以故意緩慢的基於密碼的密鑰派生功能，例如 PBKDF2、Bcrypt、Scrypt、Argon2、Balloon，而不是快速雜湊。RFC5054或 ISO/IEC 11770-4:2006（沒有檢查最新版本）沒有標準化鹽和安全參數的來源，也沒有促進少數 SRP 客戶端的互操作性。
- 更新：在註冊時如何建立伺服器端數據不是標準化的，AFAIK 和 HTTPS 可能是薄弱環節的另一個領域。
由於所有這些原因，瀏覽器中的 SRP 從未被擷取，既沒有從伺服器下載，也沒有內置到瀏覽器中。當有錢花在安全上時，它會進行兩因素身份驗證。否則，業務決策者希望現在可以在任何地方都可以使用並具有流暢的使用者體驗，而 SRP 沒有業務案例。