hash - type - 醃製密碼:最佳實踐?




type salt hashed password (6)

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

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

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

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

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


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

你應該考慮這三件事情:

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

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


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

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


它不應該有任何區別。 無論你放鹽的地方,散列都不會更容易被猜出。 哈希碰撞是非常罕見和不可預測的,因為它是故意非線性的。 如果它對安全有所不同,那麼這就意味著哈希問題,而不是醃製問題。


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

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

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


首先,“彩虹桌”一詞一直被濫用。 “彩虹”表只是一種特殊的查找表,它允許在鍵上進行特定類型的數據壓縮。 通過交易空間計算,可以將需要1000 TB的查找表壓縮一千次,以便將其存儲在較小的驅動器驅動器上。

你應該擔心哈希密碼查找表,彩虹或其他。

@ onebyone.livejournal.com:

攻擊者擁有的“彩虹表”不是由字典單詞的散列組成的,而是在完成散列計算之前的散列計算狀態。

然後使用後綴salt比前綴salt強制密碼文件條目更便宜:對於每個字典單詞,反過來,您將加載狀態,將salt字節添加到散列中,然後最終確定它。 使用前綴鹽,每個字典單詞的計算之間沒有共同之處。

對於通過輸入字符串線性掃描的簡單哈希函數(如簡單線性同餘生成器),這是一種實際的攻擊。 但是密碼安全的散列函數被故意設計為具有多個回合,每個回合都使用輸入字符串的所有位,因此在第一輪之後計算內部狀態在添加鹽之前是沒有意義的。 例如,SHA-1有80輪。

此外,像PBKDF這樣的密碼哈希算法多次組合它們的哈希函數(推薦將PBKDF-2迭代至少1000次,每次迭代應用SHA-1兩次),使得這種攻擊變得非常不切實際。





salt