使用SHA1作爲鏈中最內部散列的散列

客戶端程序（通過它我無法控制）通過發送密碼進行認證，散列爲SHA1(password)。我很不願意在我的數據庫中存儲使用SHA1的密碼散列，所以我建議將數據庫中的密碼存儲爲散列爲SHA256(SHA1(password))（其中密碼使用PBKDF-2或類似的東西進行多次迭代散列）。使用SHA1作爲鏈中最內部散列的散列

我的問題是：在這種情況下，使用SHA1的最內部散列值有什麼不安全感？我意識到碰撞的可能性會增加，但由於這僅僅是用於在數據庫中存儲密碼，所以我不認爲我需要擔心這一點。還有什麼我失蹤？

來源

2012-10-25 Neil

對於這個問題（可能）更正確的答案，請嘗試http://crypto.stackexchange.com/ –

考慮在進行最終加密之前添加一行是唯一的鹽。例如：

假設您收到W6ph5Mm5Pz8GgiULbPgzG37mj9g=（SHA1'd加密"password"）。這與用戶應該有一個唯一的密鑰相關聯，例如UserID和/或UserName。

我的建議 - 避免碰撞 - 將字節轉換爲Base64String（在C＃中，這將是Convert.ToBase64String(byteVariable) - 然後將字符串連接到用戶的唯一ID（使新字符串如下）：

W6ph5Mm5Pz8GgiULbPgzG37mj9g=+103（我添加了+103以反映用戶的ID） - 然後應用SHA256算法，這將產生：mNXRjWsKJ7V+BHbAuwJJ7neGT+V1IrLQSQXmb4Vv1X8= - 您可以將其存儲在數據庫中SHA256哈希 - 消除來自不太安全SHA1的衝突算法

而且 - 由於您使用的是單向加密 - 當您檢查密碼是否爲在將來有效時，您只需在檢查之前再次附加用戶標識。

來源

2012-10-25 20:42:30

PBKDF-2使用base64或其他任何冗餘進行任何擴展。不過，添加一個鹽 - 無論是用戶的內部唯一ID還是存儲在其記錄中的不可變的內容 - 始終是一個好主意。 – SilverbackNet

確定性數據（如用戶ID）對Salt來說不是一個好的選擇。發明自己的密碼系統也不是 - 這就是PBKDF2和其他密碼哈希原語存在的原因。 –

感謝您的回答。然而，我想知道爲什麼我應該關心我是否碰到碰撞？ – Neil

如果客戶端總是向您發送相同的密碼，只需SHA1散列，那麼SHA1散列輸出就是的密碼，以達到所有意圖和目的。對待它並以與任何其他密碼相同的方式存儲它，例如使用PBKDF2，SCrypt或BCrypt。

來源

2012-10-26 11:27:42

使用SHA1作爲鏈中最內部散列的散列

回答

相關問題