SRP 中間人
該站點建議當“攻擊者可以攔截、修改和偽造客戶端和伺服器之間的任意消息”時，安全遠端密碼協議是安全的。
然而，從SRP [1 ]上的 Wikipedia 頁面的快速閱讀來看，該方法的一個明顯缺點似乎是伺服器通常不能被信任。由於組織黑客攻擊和竊取憑據是通過不以純文字形式儲存密碼來解決的問題，因此客戶端的密碼驗證器和 salt ( $ v $ 和 $ s $ 在 [ 1 ] 的符號中）不能假定只有伺服器知道。因此，攻擊者俱有以下知識 $ v $ 和 $ s $ （從伺服器竊取）可以對 SRP 身份驗證執行中間人，使用與伺服器相同的過程獲取對稱密鑰。使用已知的對稱密鑰，攻擊者現在似乎可以偽裝成客戶端向伺服器發出任意請求。
我不是安全專家，所以我幾乎可以肯定在這裡遺漏了一些東西。有什麼問題？
問題中概述的攻擊不起作用，至少是這樣。儘管如此，SRP6a 仍然很容易受到伺服器數據洩露的影響，這不是它所解決的威脅模型的一部分。
具有以下知識的攻擊者馬洛里 $ v $ 和 $ s $ （從伺服器竊取）確實可以偽裝成伺服器到客戶端並與客戶端建立共享密鑰。但是，沒有密碼，Mallory 無法偽裝成伺服器的客戶端並到達伺服器使用私鑰的地步。此外，如果 Mallory 試圖劫持合法客戶端先前與伺服器建立的連接，那將失敗，因為該連接使用了另一個私鑰，而不是客戶端和 Mallory 之間共享的私鑰。
然而，隨著 $ v $ 和 $ s $ 從伺服器竊取，純 SRP6a，攻擊者可以通過字典攻擊找到弱密碼（從最有可能開始依次嘗試可能的密碼），然後冒充合法客戶端到伺服器。從這個角度來看，技術進步（“摩爾定律”）傾向於使 SRP6a 按比例降低安全性。唯一的辦法（除了不讓 $ v $ 和 $ s $ 洩漏，或者希望使用者會神奇地開始使用強密碼）是 SRP6a 再次通過使用密碼的慢速密鑰派生函式（也稱為密碼雜湊，基於密碼的密鑰派生函式）進行修改，例如 PBKDF2、Bcrypt、Scrypt、 Argon2，氣球而不是快速雜湊。
底線：使用 SRP6a 時，如果 $ v $ 和 $ s $ 被認為可能從伺服器被盜，則客戶端軟體必須為密碼實現適當參數化的慢速密鑰推導功能；選擇該功能、參數化以及鹽的來源沒有由我知道的任何標准定義，包括RFC5054或 ISO/IEC 11770-4:2006（未檢查最新版本）。相應地，實踐絕大多數是忽略 SRP 並在 https 隧道中以鍵入的形式發送密碼（問題是偽造證書或正確域名的變體通過了使用者審查Glance 會向有能力的攻擊者透露使用者的登錄名/密碼）。這種做法還解決了典型瀏覽器沒有內置 SRP 客戶端支持的問題，以及將一個通過 https 作為 Javascript 容易受到上述 https 攻擊的問題。