hash password中文 function中文 - 醃製密碼:最佳實踐?




4 Answers

前綴或後綴是無關緊要的,只是增加了一些熵和長度的密碼。

你應該考慮這三件事情:

  1. 對於您存儲的每個密碼,鹽必須不同。 (這是一個很常見的誤解。)
  2. 使用密碼安全的隨機數生成器。
  3. 選擇足夠長的鹽。 想想生日問題。

Dave Sherohman回答了另一個問題,你為什麼應該使用隨機生成的鹽而不是用戶名(或其他個人數據)。 如果你遵循這些建議,放鹽的地方確實無關緊要。

hashed salt

我一直很好奇......當哈希值為前綴或後綴時,哪個更好? 為什麼? 或者它重要嗎,只要你鹽?

解釋一下:我們現在都希望知道,在我們將它存儲到數據庫之前,我們應該密碼。[ 編輯:所以你可以避免像最近發生的事情那樣的事情 ]。 通常,這是通過在將密碼與哈希算法傳遞之前串接鹽和密碼來完成的。 但是這些例子各不相同......有些例子在密碼之前加了鹽。 一些示例在密碼添加salt。 我甚至看到有些人試圖把鹽放在中間。

那麼更好的方法是什麼?為什麼? 有沒有一種方法可以減少散列衝突的機會? 我的谷歌搜索沒有就這個問題做出體面的分析。

編輯:偉大的答案鄉親們! 對不起,我只能選擇一個答案。 :)




真正的答案,似乎沒有人涉及到,是兩個都是錯的 。 如果你正在實施你自己的加密算法,不管你認為自己在做什麼部分有多麼微不足道,你都會犯錯誤。

HMAC是一種更好的方法,但即使如此,如果您使用的是SHA-1之類的東西,那麼您已經選擇了一種由於速度設計而不適合密碼散列的算法。 使用bcryptscrypt類的東西,完全解決你的問題。

噢,甚至不要考慮將產生的哈希與您的編程語言或數據庫字符串比較實用程序進行比較。 如果字符不同,那麼將字符和短路比較為false 。 因此,現在攻擊者可以使用統計方法來嘗試確定散列是什麼,一次一個角色。




如果使用加密安全散列,則不論你是前置還是後置; 散列的一點是源數據中的單個位變化(不管在哪裡)應該產生不同的散列。

然而重要的是使用長鹽,用適當的密碼PRNG生成它們,並且使用用戶鹽。 在數據庫中存儲每個用戶的鹽不是一個安全問題,使用站點範圍的哈希




BCrypt哈希如果平台有提供者。 我喜歡你如何不擔心創造鹽,如果你願意,你可以讓它們變得更強壯。




Related