是否知道在Rfc2898DeriveBytes中使用的鹽具有安全風險？

很抱歉，如果這是重複的，但我找不到與數據庫加密無關的任何內容。我的問題不在於數據庫。我有一組使用RijndaelManaged加密的文件。在加密代碼中，我使用Rfc2898DeriveBytes來生成給定密碼和鹽以及一定數量的迭代的密鑰。正如它發生的那樣，鹽不是安全存儲的（只是一個字符串）。是否知道在Rfc2898DeriveBytes中使用的鹽具有安全風險？

我想知道：有權訪問我的代碼的人可以很容易地得到鹽（例如拆解dll），當然還有迭代次數。

這樣的安全風險是什麼？由於認爲密碼本身不容易檢索（是的，讓我們現在就認爲它是理所當然的）？

我假設沒有密碼解密將是不可能的，或者至少它需要一些時間來蠻力......或者它是否可能對解密文件進行一些分析？

一個明顯的問題是被盜的代碼比偷來的DB不太容易檢測的...

來源

2013-05-28 Tallmaris

這完全取決於多少熵的密碼了。「鹽......不必保密」 - RFC 2898. –

鹽對每個文件應該是不同的。 – mikey

感謝您的評論，他們指出我正確的方向（最後重寫一些代碼）。我認爲這個問題更適合進入安全堆棧交換站點......任何人都可以遷移它嗎？ – Tallmaris

總之，鹽是罰款將被明文存儲。但是，您應該在文件中存儲每個密碼的唯一鹽（請參閱this）。這樣，沒有人可以創建一個Rainbow table爲所有存儲在文件中的密碼（注意，他們仍然可以在文件中爲一個密碼創建一個彩虹表）。

有關整個哈希/密碼存儲過程的詳細背景，請參閱：

Hashing

來源

2013-05-29 00:57:42 AtinSkrita

這將適用於我將密碼存儲在數據庫（或文件）中的情況。我正在加密硬盤上的文件，並使用相同的密碼+ salt來導出每個文件加密的密鑰。我問是否知道鹽是潛在的安全風險。 – Tallmaris

不可以。使用鹽（應該未加密存儲）不會打開任何（新）安全漏洞。對所有文件使用一種鹽比根本不使用鹽要好。然而，爲每個文件使用獨特的鹽比以前更好。 – AtinSkrita

是否知道在Rfc2898DeriveBytes中使用的鹽具有安全風險？

回答

相關問題