Rfc2898DeriveBytes/PBKDF2 的正確鹽字節數
我知道 .NET 的 Rfc2898DeriveBytes 至少需要 8 個字節的鹽，但理想的字節數是多少？
當創建使用者或更改其密碼時，我的伺服器為該使用者儲存一個新的隨機鹽，以及一個“雜湊”，它實際上只是來自
Rfc2898DeriveBytes（ed：.NET 的 PBKDF2 實現）的一些字節數，使用使用者的密碼和鹽，以及 5000 次迭代。我的客戶端應用程序通過 SSL 連接到伺服器，發送使用者的使用者名，伺服器發送該使用者的 salt，客戶端
Rfc2898DeriveBytes使用使用者的密碼和 salt 呼叫，並將該“雜湊”發送到伺服器進行身份驗證。如果伺服器接收到一個無效的使用者名，它會返回一個隨機的鹽，這樣客戶端就不知道使用者名或密碼是否無效，從而浪費了一些時間來阻止黑客攻擊。我對 salt 的理解是，它實際上只是為了為同一個密碼獲取不同的密鑰，這會讓我認為 8 個隨機字節就足夠了，但是由於我是通過 SSL 發送的，所以我想知道更長的 salt會以某種方式增加安全性。
除了鹽字節數之外，最好有多少“散列”字節？
簡短回答： 8 個字節就可以了
**更長的答案：**密碼散列中的鹽點是為了防止預先計算散列列表，通常以彩虹表的形式完成。如果有人仍然想進行預計算，他將不得不為每個可能的鹽值建構一個彩虹表，因此你正在增加對手的儲存需求。
使用 8 字節的鹽，攻擊者需要建構 $ 2^{64} \approx 10^{19} $ 表。這些表的大小取決於您嘗試的密碼類型和長度（您可以在此處找到一個很好的概述），但您通常期望在 2-3 位千兆字節範圍內（ $ 10^{11}-10^{12} $ 字節）。把這些放在一起，為 8 個字節的鹽儲存彩虹表需要的東西在 $ 10^{30} $ 字節，這是完全不可能的。