為什麼在實踐中不使用零知識證明進行身份驗證？
我在維基百科上讀到零知識證明在實踐中不用於身份驗證。相反（我認為）伺服器被委託以明文形式查看密碼，然後它應該添加鹽和散列。但是一瞬間，伺服器知道了這個秘密。為什麼我應該像這樣隱式信任伺服器？它可能會變得流氓並以純文字形式記錄我的密碼。我可以將相同的密碼用於其他敏感的事情。零知識證明不是必需品嗎？為什麼不使用它們？或者他們被使用了？
更新，另一種選擇：永遠不要重複使用您的密碼，而是僅使用在客戶端上執行的程序從主密碼和網站名稱生成不同的密碼呢？看起來要簡單得多，因為您永遠不會透露主密碼。這樣，您幾乎不需要信任該網站。
這澄清了我之前的問題。
回答你標題中的問題（而不是解決你提出的我不太理解的替代方案）有一個密碼協議“ SRP ”的零知識證明，它快速有效。
SRP 似乎沒有得到應有的廣泛宣傳。實現了它，並且作為它使用的倡導者，我真的不明白為什麼每個人都不一直使用它。我看到的一些駁回它的理由是：
- 相信伺服器要麼完全“好”，要麼完全“壞”，並且使用 HTTPS 可確保您始終與“好”伺服器通信，這些伺服器可以使用明文密碼進行信任。現實生活不像電影。它更複雜。Heartbleed崩潰表明，原本值得信賴的網站可能會洩漏一些記憶體，因此通過 HTTPS 發送的明文密碼可以被第 3 方觀察到。更常見的是自定義網站程式碼中的錯誤處理不佳，這會將純文字密碼列印到日誌文件中，該日誌文件可以被只能看到伺服器上文件系統的入侵者讀取。大型系統將日誌流式傳輸到中央位置。這使得由於錯誤處理不當而洩露純文字密碼的可能性更大。
- 認為客戶端要麼完全安全，要麼完全受到威脅，這樣攻擊者什麼都看不到，否則可以記錄正在輸入的內容。如果攻擊者可以記錄輸入的內容，他們可以直接竊取密碼；SRP 僅防止線路上的攔截，而 TLS 保護線路。實際上，即使使用配置良好的 HTTPS，攔截也比人們意識到的要正常得多。大型雇主會定期解密和掃描 HTTPS，以保護自己免受員工的智慧財產權盜竊。即使他們這樣做只是為了保護自己的數字財產權，也會增加漏洞洩露明文密碼或流氓員工竊取密碼的風險。大型筆記型電腦供應商安裝了諸如超級魚之類的東西解密客戶 HTTPS 流量以在頁面上出售“智能廣告”。他們可能不都是壞人；但它增加了漏洞洩露密碼或流氓員工竊取密碼的風險。還有一些證書被洩露的例子，這意味著可以窺探加密的流量。所有這一切意味著攻擊者可能經常無法直接記錄使用者在鍵盤上鍵入的內容；但即使在使用 HTTPS 時也可以查看通過網路傳遞的任何內容。SRP 可以防止任何此類攔截，因為它是零知識密碼證明。
- 認為 SRP 被定位為 HTTPS 的替代品。SRP 不會（開箱即用）驗證伺服器（在註冊時），因此您可能正在與假伺服器交談。因此，在 SRP 和 HTTPS 的“非此即彼的比較”中（假設沒有上面詳述的問題），通常認為 HTTPS 更勝一籌。這是一種錯誤的二分法，因為在實踐中，現實世界的 HTTPS 有許多弱點，可以通過使用基於 HTTPS 的 SRP 來解決。通過 HTTPS 執行 SRP 可為您提供加強 SRP 的伺服器驗證。因此，人們應該始終同時使用兩者。
- 很多人關注兩因素身份驗證作為對明文密碼的增強。已確定密碼具有高風險的公司傾向於採用第二個因素（例如，向您的手機發送簡訊）。該站點可能仍會洩漏密碼，使用者可能在多個站點上使用這些密碼，其中許多站點不使用第二個因素。如果站點升級為使用 SRP 和第二個因素，他們將充分保護其使用者。
在實施 SRP 時，有幾個阻礙因素：
- 歷史上缺乏純 JavaScript 範例。早期的權威展示使用了 Java 小程序。最近，在Heartbleed崩潰之後，SRP 重新出現，現在有一些可靠的開源 JavaScript 庫和展示。
- 額外的往返登錄。使用純文字，您可以在一篇文章中發送使用者名和密碼。使用 SRP，您首先發送使用者名以獲取鹽（和質詢），然後生成密碼證明以發送到伺服器。大多數 Web 安全框架都假設所有內容都是在一次往返中發送的。這可以通過第一次往返的 AJAX 呼叫並將密碼證明作為密碼發布來解決。更多網站現在將使用者名和密碼拆分為兩個頁面以實現“社交登錄”。根據您在第一頁提供的電子郵件，他們會顯示一個針對正確社交登錄伺服器的密碼頁面。這種兩頁模式非常適合 SRP，並且最終使用者越來越熟悉它。
說了這麼多，沒有充分的理由為什麼每個站點現在都不使用 SRP。因此，您對仍在使用明文密碼感到驚訝是正確的。
更新：我仍然遇到加密專家對 SRP 的強烈反對，他們認為 TLS 就足夠了。我敢肯定，他們只受僱於（理論上）永遠不會犯上述錯誤的高安全性機構。他們使用他們的理論知識來擊落 TLS 和 SRP 的實際附加縱深防禦策略這一事實令我感到驚訝。由於理論上的原因，我沒有成為 SRP 的粉絲。在我剛剛升級的網上銀行系統未能通過完美配置的 TLS 進行滲透測試後，我成為了粉絲，而外部測試人員設法收穫了最多的實時密碼。正如我祖父告訴我的：“理論上，理論和實踐都是一樣的。在實踐中，它們不是。” 客運航空公司使用冗餘來維持人們的生命。
SRP 通過身份驗證進行 DH 密鑰交換，並且還具有對伺服器進行身份驗證的能力（儘管通常通過對驗證者保密來對伺服器進行身份驗證）。如果密鑰是嚴格從密碼和鹽生成的，鹽儲存在伺服器上，您可以對驗證者進行字典攻擊（例如，如果伺服器被入侵或伺服器是惡意的），但有一些方法可以增強抵抗力到那個。
如果不進行（相當昂貴的）字典攻擊，伺服器永遠不會看到密碼，並且有多種可能性使字典攻擊不可行。
更新以回答更新的問題：如果算法已知，則特定於站點的密鑰與任何其他方案一樣容易受到字典攻擊。
您可以使用兩個密碼的方法來使字典攻擊變得不可行。
例子：
$ MasterKey = HMAC(MasterPassword, Identity) $
$ SiteKey = HMAC(MasterKey, Password, SiteIdentifier) $
在哪裡 $ Identity $ 可以是任何您想要的（例如電子郵件地址、SS#、暱稱）。我正在使用 $ SiteIdentifier $ 作為某種形式的持久身份。域名可能不夠穩定，因此可以使用某種 GUID 或公鑰或其他東西。
這 $ MasterKey $ 也可以從儲存在密鑰伺服器或專用設備上的值派生（可能仍與主密碼結合使用）。有很多可能性。
$ SiteKey $ 可以直接用作 SRP 等協議中的密鑰，或者以與隨機密碼生成器相同的方式變成可鍵入的密碼。
使用 SRP，標準實現的協議有一個由伺服器提供的鹽，可以用來代替 $ Password $ ，或者像往常一樣生成一個可鍵入的密碼並將其與鹽相結合（儘管使用隨機密碼消除了對鹽的需求，這將允許通過手動鍵入生成的密碼將密碼與 SRP 的其他實現一起使用）。