非儲存密碼的鹽
我已經閱讀了很多關於在密碼中添加鹽的概念，並了解它可以防止各種攻擊，尤其是彩虹表的使用。但是這種攻擊是基於訪問伺服器端儲存密碼數據庫的。
如果從未儲存密碼怎麼辦？因為根據定義，鹽不是秘密的，所以使弱密碼更強大無濟於事（在我看來，在這種情況下，只有密鑰拉伸會有所幫助，對吧？）。因此，僅在客戶端加密的應用程序（使用者輸入密碼 > KDF > 密鑰 > 加密）在將鹽輸入 KDF 算法時似乎沒有任何好處。
是否可以將 KDF 函式（例如 PBKDF2）的強製鹽參數設置為硬編碼值？還是我完全忽略了另一個鹽功能？
如果您正在使用使用者提供的密碼處理加密，則生成的密文可能會使用預計算à la “字典攻擊”進行攻擊，這與我們在使用鹽儲存密碼時試圖減輕的攻擊相同。
當使用使用者提供的密碼進行加密時，KDF 被用作補償使用者密碼的不良熵的一種手段，但是因為您不能將鹽視為秘密，您必須以某種方式將其提供給解密方，如果您使用鹽，則不一定會增加密碼的“熵”，因為攻擊者可以簡單地使用相同的鹽來嘗試暴力破解您的密鑰。以同樣的方式，對加密數據的字典攻擊仍然可以通過簡單地使用與你相同的參數和鹽來工作，因為這些都是公開的（如果你有一個已知的明文-密文對，那就更容易了）。
所以最後，您仍然應該擔心盡可能昂貴地進行字典/蠻力攻擊，這對於現代 KDF（例如Argon2或Balloon ）是可能的，您可以在其中設置可以公開知道的參數，例如一種攻擊方式對攻擊者來說將變得越來越耗時和昂貴。
如此有效，我同意你的觀點，鹽不一定對你的案例有用，因為擁有更大的初始秘密熵對於保護你的數據更重要。但是請注意，擁有一個硬編碼的鹽對您是有害的，因為它允許攻擊者一次“預先計算”其表或字典攻擊您的所有密文。這意味著使用固定鹽可以降低平均破解多個密文的成本。
因此，您的案例受益於使用具有較大迭代次數的 KDF（不僅僅是散列函式）以增加攻擊成本，並且還受益於為每次加密使用不同的隨機鹽以避免“預-computation”攻擊，可以同時針對所有密文。這實際上意味著每個密文都需要自己的預計算，因此最終歸結為暴力破解。
PS：請注意，字典攻擊僅在對手能夠輕鬆判斷她是否找到正確的密鑰時才有用。這通常是已知明文攻擊的情況，但並非所有案例都如此。
PPS：我沒有提到胡椒，因為鑑於你的其他問題，你知道它的存在。但是胡椒通常在這種案例中很有用。請注意，鹽，當被認為是秘密時，基本上是胡椒。