Rfc2898DeriveBytes - 密碼長度

試圖找到相關的答案很長一段時間，但尚未確信。Rfc2898DeriveBytes - 密碼長度

我在嘗試的是使用RijndaelManaged進行加密。要創建密鑰，我將密碼，鹽和迭代傳遞給Rfc2898DeriveBytes。

我想在用戶輸入密碼低於指定長度之前添加常量，然後再將它傳遞給Rfc2898DeriveBytes。

到目前爲止，我發現添加常量不會增加安全性的好處。假設攻擊者可以訪問包含加密數據的數據庫以及salt，但是不會保持不變會給他帶來一點困難。儘管最終他會發現這一點。

或者將任何長度的密碼傳遞給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); 

using (RijndaelManaged aes = new RijndaelManaged()) 
{ 
    aes.Key = derivedKey.GetBytes(keyLength); 
    ..... 
}

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

來源

2014-02-28 toughcanny

唯一的解決辦法是要求用戶輸入至少一定長度的密碼。添加一個或多個循環不會彌補1個字符的密碼。 – mfanto

是的，鹽和更多的迭代更重要。事實上，更多的迭代正是BCrypt所做的。我不認爲增加固定數據來製作「更長的密碼」會帶來很大的改變 - 你不會改變密碼安全性的有效深度。 –

增加常數毫無意義。鹽已經達到了你想要不斷實現的目的。事實上，增加這個常量有可能使安全性更糟糕（儘管我認爲使用Rfc2898DeriveBytes可以保證安全）。如果您想提高安全性，請確保密碼超過最小長度。 – Jodrell

假設攻擊者不知道「常量」，那麼，是的，它會通過使蠻力攻擊變得更難以有效地增加安全性。但是，這是一個非常糟糕的假設，你應該始終假設攻擊者擁有你的源代碼。

繼續我們的錯誤假設：如果足夠的密碼被破解，攻擊者最終可能會發現您的常量，這是正確的。

至於是否在密碼中添加更多字符可以提高密鑰推導的準確性：不是。無論如何，你生成的關鍵字都是相同的長度。但是攻擊者不會試圖猜測你的鑰匙，他們太長而且實際上不可能蠻橫。任何攻擊者都會在密碼後面去。

這就是迭代，鹽和很難猜測長密碼進來的地方。迭代通過增加每次猜測所花費的時間來增加難度。雖然合法用戶登錄時執行數千次迭代的時間可以忽略不計，但暴力攻擊者的成本卻非常高。長密碼還增加了強力的難度。 salt有助於保護相同的密碼不被同時解決（攻擊者必須獨立攻擊每個密碼，即使它們是相同的）。

來源

2014-02-28 16:50:21 MikeH

什麼是「加密」？如果你創造一個沒有人知道的新詞，很難說迭代是否會增加「加密性」。你繼續說迭代使暴力攻擊更難 - 因此更安全。所以，如果「加密」與安全有關，那麼你就是在自相矛盾。 –

@PeterRitchie你說得對的話很差。我現在編輯。 – MikeH

給密碼加一個常數減少熵，'Rfc2898DeriveBytes'設計用來增加（在鹽的幫助下）的東西。 – Jodrell

Rfc2898DeriveBytes - 密碼長度

回答

相關問題