將 PBKDF 用於 AES 加密密鑰並將 Sha256 用於使用相同密碼文本的雜湊是否存在安全風險？

我正在使用 C# 編寫一個加密程序。我的目標是保護文件，即使電腦被盜並以某種方式登錄。

假設

• 用於編寫程序的程式碼對惡意使用者可見
• 程序登錄過程中使用的密碼雜湊也是可見的

關注點

• 我使用相同的密碼來：

  1. 派生使用 AES 加密密鑰Rfc2898DeriveBytes
  2. 通過比較儲存的SHA256雜湊登錄軟體

• 我不知道儲存的雜湊是否可以用來計算加密密鑰

筆記

我使用兩種不同的鹽：一種用於雜湊，另一種用於密鑰。我不確定這是否真的有幫助，因為它們都與使用者的密碼雜湊一起以純文字形式儲存。

在同一密碼文本上使用 PBKDF 和 SHA256 散列算法是否會給單個電腦應用程序帶來安全風險？

是的，在同一個密碼上使用 PBKDF 和 SHA-256 雜湊算法否定了 PBKDF 的用處，允許使用單個雜湊測試候選密碼；並且（假設未加鹽的密碼雜湊，問題中不是這種情況）在多個使用者/實例之間攤銷彩虹表的計算，如果其雜湊已被預先計算，則允許快速找到密碼。

打個比方，想像兩個保險箱，每個保險箱都有一個 3 位密碼鎖，並且已知使用相同的 3 位密碼。一個保險箱包含貴重物品並使用定時鎖，防止密碼嘗試速度超過每小時一次；另一個保險箱什麼都沒有，並且使用了非定時鎖。通過允許快速找到第一個保險箱的密碼並提取貴重物品，第二個鎖否定了第一個定時的好處。

使用溫和密碼的無鹽 SHA-256，一個有大腦和網路瀏覽器的孩子就能破解它。加點算力，鹽漬雜湊就可以破解了。讓 10 個隨機的人選擇一個一周後他們能記住的密碼，我敢打賭，至少有一個密碼會受到攻擊。

雖然Rfc2898DeriveBytes是上個世紀的密碼散列/密鑰拉伸，但它仍然沒有普通散列那麼糟糕。IterationCount 參數的壞程度的數量級（如果沒有對普通雜湊加鹽：乘以對手破解密碼的使用者數量）。

對於實踐中經常可用的更有效的密鑰延伸，請考慮bcrypt或scrypt。

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