使用客戶端哈希密碼密碼

Question

鑑於您真的必須在客戶端執行密碼哈希，您如何實現服務器端的salting？

我能想到的第一個解決方案是在執行哈希之前從服務器的用戶表中詢問用戶的salt。但這意味着你確認用戶「存在」，因爲你給了他用戶的有效鹽。

我也認爲，不要將salt存儲在用戶的表中，而是可以使用戶可以使用的鹽，例如，他的用戶名的變體。但是可能會出現一致性問題，因爲服務器和客戶端需要記住從提供的用戶數據得到的salt的確切含義。

這樣做的最好方法是什麼？

Answer 1

我不是專家關於這個話題的專家，但是如何使用像一次鹽一樣的東西以及您提到的解決方案。

這意味着，您可以爲客戶端提供一個salting函數，該函數根據短時間幀內的隨機種子生成鹽。種子本身是動態的，並在一段時間後發生變化，並且在服務器和客戶端之間必須相同。畢竟，鹽不一定是祕密的。

在客戶端，使用用戶名（或任何可用的用戶數據）生成鹽，假設它是唯一的。然後你在連接的密碼和salt上生成哈希，並將其發送到服務器上。

在服務器端，您使用用戶名作爲輸入的客戶端中相同的salting函數來計算salt。然後生成哈希值，並確定這兩個值是否匹配。您只需確保時間窗口足夠寬以允許成功驗證。

Answer 2

如果您沒有HTTPS登錄，哈希客戶端很有用，但它可能有一些缺點，例如顯示您的哈希和/或醃製方法。話雖如此，如果他們有權訪問您的密碼哈希數據庫，他們可能已經有權訪問該信息。

爲了只做一個服務器端鹽，您將需要使用鹽和密碼哈希重新密碼。在這種情況下，你將只存儲用戶名，鹽（如果不使用用戶名和密碼哈希鹽）和第二個哈希。

如果從您的示例中您希望在客戶端和服務器上執行salting，我會建議使用用戶名和初始密碼哈希的組合來salt。客戶不會不知道鹽，因爲任何人都可以檢查您的醃製方法，甚至將其應用於密碼破解程序，但它會避免使用彩虹表破解相同的密碼用戶。

不要將用戶名本身用作鹽。如果它的通用用戶名（例如管理員），那麼可能有一個表已經有了這個鹽。

使用nyde1319的答案（抱歉，沒有權利評論答案）的問題是，您需要在數據庫中擁有未加密版本的密碼才能執行密碼+ salt哈希。擊敗哈希的目的。如果使用散列版本的密碼完成，則必須存儲第一個散列，然後他們可以破解該散列，從而擊敗鹽的目的。