客戶端和伺服器端的鹽和胡椒？

撇開它可能聽起來很偏執。

我知道許多使用者傾向於在許多網站上使用相同的密碼。然後，從道德的角度來看，我不僅應該關注影響我自己系統的安全漏洞，還應該關注我的系統如何促進破壞其他系統的安全。

假設攻擊允許第三方讀取（但不能修改1）通信，包括登錄期間的密碼交換。如果他們可以讀取使用者的名稱和密碼，如果他們在那裡使用相同的名稱和密碼，他們就可以訪問該人在其他系統上的帳戶。

為了避免這種情況，我正在考慮在客戶端執行 hash(system_public_pepper+username_as_salt+password) 以及帶有秘密系統胡椒的 bcrypt（包括鹽）。兩個辣椒都會在每台伺服器上發生變化（安裝時隨機生成）。

但是我的新問題是這個客戶端雜湊是否會削弱密碼（例如：限制熵）。

接著：

1. 我應該使用什麼雜湊來確保沒有顯著的熵損失？MD5可以嗎？
2. 辣椒和/或鹽能否削弱熵，考慮到它是公眾知識（儘管鹽在使用者之間會發生變化）？
3. 鹽（使用者名）或胡椒（公共）是前置還是後置有區別嗎？哪個順序最好？

我認為，如果前面加了鹽或胡椒，可以將雜湊算法當時的狀態作為開始，然後計算每個密碼的雜湊會花費更少（就像沒有鹽和胡椒一樣）。

但是，也可以將相同的密碼應用於普通密碼，如果它們是在開頭。

4. 還有什麼我應該考慮的嗎？

---

編輯：我認為我的提議存在誤解。所以，我舉個例子。U 是使用者，C 是客戶端，S 是伺服器，D 是數據庫（為了清楚起見，我們可以將 PDO 用於準備好的語句等）。

註冊範例：

C>S: I need to signup, send me the public pepper.
S>C: {"system_public_pepper":"Potts"}
U>C: {"username":"johndoe","password":"IWasBornOn1987"}
C: P=system_public_pepper+username+password; //P="PottsjohndowIWasBornOn1987"
C: H=md5(P); //="28d36f3969e05dedb5f9ba20acd3842a"²
C>S: {"username":"johndoe","hashpass":"28d36f3969e05dedb5f9ba20acd3842a"}
S: private_pepper="GwynethPaltrow";
S: new_pwd=private_pepper+hash_pass; //"GwynethPaltrow28d36f3969e05dedb5f9ba20acd3842a";
S: pwd_bcrypted=bcrypt(new_pwd); //"$2a$04$qh7z5sSkMCrLq6mrpdOwM.ohlvCKWvU3vQm.CrjrxcQc6otwByBle"³
S>D: INSERT INTO users ('username','password') VALUES ('johndow','$2a$04$qh7z5sSkMCrLq6mrpdOwM.ohlvCKWvU3vQm.CrjrxcQc6otwByBle')

登錄範例：

C>S: I want to sign in, send me the public pepper.
S>C: {"system_public_pepper":"Potts"}
U>C: {"username":"johndoe","password":"IWasBornOn1987"}
C: P=system_public_pepper+username+password; //P="PottsjohndowIWasBornOn1987"
C: H=md5(P); //="28d36f3969e05dedb5f9ba20acd3842a"²
C>S: {"username":"johndoe","hashpass":"28d36f3969e05dedb5f9ba20acd3842a"}
S: private_pepper="GwynethPaltrow";
S: attempt_pwd=private_pepper+hash_pass; //"GwynethPaltrow28d36f3969e05dedb5f9ba20acd3842a";
S>D: SELECT 'username', 'password' FROM users WHERE 'username'='johndoe'  //'$2a$04$qh7z5sSkMCrLq6mrpdOwM.ohlvCKWvU3vQm.CrjrxcQc6otwByBle'
S: password_verify(attempt_pwd,stored_hash)

---

腳註：

1. 我知道這很奇怪，因為通常如果您可以嗅探 HTTPS 通信，您也可以執行中間人攻擊。但我正在考慮一種僅針對閱讀的通用攻擊，因為它可能適用於大量網站。雖然修改它們需要更多的工作。所以，至少我可以阻止這些。另外，我想這可能是對允許讀取通​​信的作業系統或 HTTPS 守護程序的特定攻擊。
2. 這裡是關鍵，使用者密碼不離開客戶端。假設伺服器存在錯誤，並且接收到的通信被記錄：您無法記錄密碼，只有散列版本。
3. 儲存的雜湊既不是原始密碼，也不是收到的密碼。

我認為你給出的詳細方法可以工作。為了解決您的具體問題：

1. 經驗法則：對於任何事情，沒有 md5 是絕對不行的。
2. 我不確定你的意思，但很確定答案是：不。
3. 儘管您的觀點是正確的，但順序並不重要，您可能應該添加欄位分隔符而不僅僅是連接。

我認為提出這種改變需要考慮攻擊者模型。您的連接應該由 TLS 保護，而這一切都變得毫無意義。

你可以做更高級的事情，它們很棒，但工作方式略有不同。也許看看密碼驗證密鑰交換 (PAKE)會給你一些啟發。

引用自：https://crypto.stackexchange.com/questions/55229