2011-01-26 85 views
11

我正在研究構建一個登錄系統,並且當您將一個2位數的鹽傳遞給crypt()函數時,它會讀取PHP手冊,它將返回一個哈希字符串,並且該字符串的前兩位數字是您使用的鹽。爲什麼PHP crypt()會在salt中加入哈希值?

例如:

$salt = "kr"; 
echo crypt("mysecret",$salt); //returns "kreOI.F7eOQMY" 

我首先想到的是,就不會這樣幫助別人誰是試圖扭轉你的哈希?

爲了獲得最佳的安全性,鹽值保持祕密:

我在維基百科上說,它擡頭salt

所以我不明白爲什麼然後crypt函數返回所有使用salt值的哈希值?

這是有原因嗎?這應該是安全問題嗎?

+0

這就是爲什麼我建議兩部分的鹽。一個在配置文件中是祕密的,但對所有用戶都是一樣的,另一部分與每個用戶隨機生成的不同密碼一起保存。 – CodesInChaos 2011-01-26 17:34:31

+0

@meager,其實我試圖升級一個我繼承的。 – 2011-01-26 17:38:21

+3

維基百科不應該被視爲福音。鹽不是祕密。 – 2011-01-26 22:44:08

回答

1

crypt()函數已過時。在影子密碼支持出現之前,它被用於散列舊式Unix系統的密碼。鹽在那裏增加了暴力破解密碼的複雜性。但是,由於鹽是由密碼子系統隨機生成的,因此必須將其存儲在明文中,以便任何未來的密碼操作都能正常工作。如果在加密之前將鹽嵌入到密碼中,那麼將無法驗證密碼 - 只要進行密碼檢查,您就必須嘗試每一種可能的鹽 - 非常不切實際。所以,salt被預先加密到密碼中,所以你可以再次將它拉出以供將來使用。

crypted password: xxabcdefghijklmn 
        ^^- salt 
        ^^^^^^^^^^^^^^-- crypted pw 

if ('xx' + crypt('xx' + password) == 'crypted string') then 
    password is ok 
endif 

現在,crypt()是穀物盒解碼器環的安全等價物。出於歷史目的和低安全性「誰在乎它是否被破解」存儲。對於任何現代密碼的使用,你最好用更現代的哈希,比如sha1/sha256/md5。即使MD5被認爲這些天被破壞,sha1在邊緣有裂痕,並且(最後我檢查了)sha256仍然是安全的。

3

是的,鹽應該保密,但密碼散列也是如此。讓他們在同一個地方保持同樣的祕密是完全可以接受的。要根據散列檢查密碼,必須將salt與密碼組合,然後根據散列進行檢查。因此,任何有權查看密碼哈希的用戶或進程都應該有權查看salt,因爲密碼哈希本身對於檢查密碼沒有用處(除非您要暴力破解鹽)。

鹽的目的是,如果兩個不同的用戶有相同的密碼,他們會散列到不同的東西。這也意味着字典攻擊要複雜得多,因爲你不能只對所有可能的密碼進行散列,然後根據用戶密碼散列列表來檢查它們以找到多個用戶的密碼。相反,您必須嘗試單個salt的密碼才能找到一個用戶的密碼,或嘗試使用多種鹽的可能密碼的所有組合,以便找到匹配結果。但是鹽的知識本身並不意味着你可以反轉密碼散列。這隻意味着你可以對密碼哈希進行字典攻擊。

如果你能找到一種方法來保證salt比hash值更安全,那肯定不會是一件壞事,但很難看出當需要訪問某個需要訪問的程序時這是否可行二者皆是。

1

將salt添加到has中,以便在獲取密碼時知道使用哪種鹽,並且要查看它是否與散列匹配。這裏的想法是爲每個密碼使用不同的鹽,以便有人不能預先計算哈希表。

你也可以爲每個密碼添加第二個鹽(對所有人都一樣),而不是告訴任何人它是什麼。

1

PHP crypt從UNIX crypt()函數繼承此行爲,該函數用於在UNIX passwd文件中生成密碼哈希。有必要將鹽存儲在某個地方,或者以後不能驗證密碼是否正確。對於passwd文件,簡單的行爲只是將salt(通常是兩個字符)添加到加密密碼的開頭,這使得將它存儲在單個字段中變得很簡單。

鹽的價值應該保密的說法容易被誤解。爲了最佳實踐,您不應該發佈您的鹽,就像您不應該發佈密碼哈希一樣。向攻擊者提供散列和鹽分可以讓他們輕鬆運行強力攻擊,而不會對系統產生可疑流量。但是,即使攻擊者能夠看到鹽和哈希密碼,系統仍應該是安全的。

事實上,你無法在存儲散列,原則上這些散列不會被黑客以與散列密碼完全相同的方式破壞。如果密碼檢查代碼可以訪問它,那麼你必須假定系統受到攻擊的人也可以訪問它。

28

維基百科文章的作者正在將鹽與搜索空間的想法混爲一談,暗示鹽是阻止暴力攻擊的一種方法。混淆這些想法並沒有改善安全性;無法識別和描述這兩個問題的人不是一個可靠的指導。

鹽的目的是阻止預先計算的查找表(如彩虹表)。 Salt可以防止攻擊者爲「時間」交易「空間」。每一點鹽都會使表格的存儲需求翻倍;兩個字節的鹽會產生很大的差異(65536倍),但八個字節需要查找表中不存在的「yottabyte」存儲設備。

鹽必須存儲在某個地方。如果你有一個有效的方法來保持「祕密」,爲什麼不使用它來存儲密碼並忘記哈希?沒有;如果你想要真正的安全性,那麼即使攻擊者知道鹽,也需要設計系統以防止暴力攻擊。 本文假定鹽可以保密,應視爲錯誤。

最好通過加密(應用哈希函數數千次)和密碼選擇規則(最小長度,數字,特殊字符)來防止蠻力攻擊。

假設鹽不能保密,鼓勵更好的加密和密碼選擇,這會導致更安全的系統。

相關問題