[hash] 醃製密碼:最佳實踐?


Answers

我認為這都是語義。 除了針對特定的威脅模型之外,將其放在前面或後面並不重要。

它在那裡的事實應該是擊敗彩虹桌。

我所提到的威脅模型將是對手可以在密碼後附加/附加普通鹽的彩虹表的情況。 (說美國國家安全局)你猜猜他們要么附加或預先,但不是兩個。 這很愚蠢,這是一個可憐的猜測。

假設他們有能力存儲這些彩虹桌,但不是,比如說在密碼中間散佈著含有奇怪鹽的桌子。 在這種狹隘的情況下,我猜想穿插會是最好的。

就像我說的。 它的語義。 每個密碼選擇一個不同的鹽,一個長鹽,並在其中包含奇數字符,如符號和ASCII碼:©¤¡

Question

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

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

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

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




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




在密碼中插入任意數量的字符是最不可預料的情況,因此在社交上是最“安全”的,但在一般情況下,只要您使用長密碼,每個密碼都是唯一的鹽的字符串。




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

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

@ onebyone.livejournal.com:

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

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

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

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




Related