Rfc2898DeriveBytes - 密碼長度

試圖找到相關答案很長一段時間，但還沒有被說服。

我正在嘗試使用RijndaelManaged. 要創建密鑰，我將密碼、鹽和迭代傳遞給Rfc2898DeriveBytes.

如果使用者輸入的密碼低於特定長度，我正在考慮添加常量，然後再將其傳遞給Rfc2898DeriveBytes.

到目前為止，我發現添加常量不會為安全性增加任何好處。假設攻擊者可以訪問包含加密數據和鹽的數據庫，但不保持不變會給他帶來一些困難。雖然最後他會發現那個不變。

或者將任何長度的密碼傳遞給“非常非常”安全而Rfc2898DeriveBytes不用擔心？

傳遞較短或較長的密碼是否會影響密鑰派生過程，哪個更好和最推薦？

到目前為止，我所知道的隨機鹽和更多迭代很重要。

以下是程式碼，我應該刪除向密碼添加常量還是保留它？

（注：使用者密碼長度限制在 GUI 沒有應用，使用者可以傳遞 1 個字元甚至超過 10 個字元）

string constant = "AnyConstantToMakePasswordBigger";

if (password.Length < 8)
{
 password = password + constant;
}

RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] salt = new byte[8];
rng.GetBytes(salt);
Rfc2898DeriveBytes derivedKey = new Rfc2898DeriveBytes(password, salt, 1000);
aes.Key = derivedKey.GetBytes(keyLength);
.....

歡迎任何正面或負面的評論和回應。

用（非秘密）常量填充短密碼沒有任何優勢。

• 它不會使密碼雜湊更難通過暴力猜測來破解：如果攻擊者可以對電腦進行程式以嘗試常見的密碼abc，如很容易讓它嘗試，，等等。123``swordfish``abcAnyConstantToMakePasswordBigger``123AnyConstantToMakePasswordBigger``swordfishAnyConstantToMakePasswordBigger
• 它不會使散列算法（PBKDF2 - HMAC - SHA1，根據 CodesInChaos ）更難破解（不是任何人都知道如何破解它）。

事實上，從技術上講，HMAC-SHA1 算法確實在內部將密碼填充到 512 位（= 64 字節）；它只是碰巧用空字節填充它（然後0x36為內部雜湊計算和0x5C外部雜湊計算對每個字節進行異或）。請注意，考慮到 SHA-1 和幾乎任何其他現代加密雜湊的工作方式，使用空字節填充並不比任何其他固定填充更安全或更不安全。

然而，用秘密常量（通常稱為“pepper”）填充密碼可以提高某些情況下的安全性——特別是，如果攻擊者獲得了對密碼數據庫的訪問權（例如通過 SQL 注入漏洞），但不能訪問秘密的任何地方常量被儲存。但是，如果您想這樣做，您應該將胡椒添加到所有密碼中，而不僅僅是短密碼。

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