在對數據庫存儲的密碼進行哈希處理時，我一直使用正確的按條目輸入的鹽字符串。出于我的需要，將鹽存儲在數據庫中散列密碼旁邊一直很好。但是，有些人建議將鹽與數據庫分開存儲。他們的論據是，如果數據庫遭到破壞，攻擊者仍然可以構建一個彩虹表，將特定的鹽字符串考慮在內，以便一次破解一個帳戶。如果該帳戶具有管理員權限，那么他甚至不需要破解任何其他帳戶。從安全角度來看，將鹽存儲在其他位置是否值得？考慮在同一臺計算機上具有服務器代碼和數據庫的Web應用程序。如果將鹽類存儲在該計算機上的平面文件中，則很有可能如果數據庫遭到破壞，則鹽類文件也會被破壞。有什么建議的解決方案嗎？
3 回答
開滿天機
TA貢獻1786條經驗 獲得超13個贊
彩虹表的要點在于，它們是預先創建的，并且可以批量分發以節省其他人的計算時間-動態生成彩虹表所需的時間與直接破解密碼+鹽組合所需的時間一樣長（因為實際上，在生成彩虹表時正在執行的操作是在對哈希進行強行的預運行），因此這樣的論據是虛假的，即通過了解鹽，有人可以“生成彩虹表”。
只要將鹽存儲在單獨的文件中就沒有實際意義，只要它們是基于每個用戶的-鹽的目的只是為了使其成為一個彩虹表而不會破壞數據庫中的每個密碼。
慕娘9325324
TA貢獻1783條經驗 獲得超4個贊
我將對此提供稍微不同的看法。
我總是將鹽和鹽密碼散列存儲在一起。
例如，我將鹽的前半部分放在密碼的哈希值之前，并將鹽的后半部分放在密碼的哈希值之后。應用程序知道此設計，因此可以獲取此數據，并獲取salt和salted-password哈希。
我對這種方法的理由是：
如果密碼/哈希數據被泄露并落入攻擊者的手中，那么攻擊者將無法通過查看數據來了解問題所在。這樣，攻擊者實際上無法執行蠻力攻擊來獲取與哈希匹配的密碼，因為他不知道哈希開頭，也無法知道數據的哪些部分是鹽的一部分，或者Salted-Password哈希的一部分（除非他確實知道您的應用程序的身份驗證邏輯）。
如果salted-password哈希按原樣存儲，則可以執行蠻力攻擊以獲得密碼，該密碼在salted和hashed時會產生與salted-password哈希相同的數據。
但是，例如，即使salted-password哈希按原樣存儲，但預先添加了一個隨機字節，只要攻擊者不知道該第一個字節將被丟棄，這也將增加難度攻擊。您的應用程序在用于驗證用戶身份時會知道丟棄數據的第一個字節。
結論到此。
1）切勿以正確的格式存儲身份驗證應用程序使用的數據。
2）如果可能，請對身份驗證邏輯保密，以提高安全性。
再往前走一步
如果您不能對應用程序的身份驗證邏輯保密，那么很多人都知道您的數據如何存儲在數據庫中。并假設您已決定將鹽密碼哈希與鹽混合在一起存儲，其中一些鹽放在鹽密碼哈希之前，其余鹽則附加在鹽密碼哈希之后。
生成隨機鹽時，您還可以隨機決定在鹽密碼散列之前/之后將存儲多少鹽。
例如，您生成512字節的隨機鹽。您將鹽附加到密碼中，并獲取鹽密碼的SHA-512哈希。您還會生成一個隨機整數200。然后存儲salt的前200個字節，然后存儲salted-password哈希，然后存儲salt的其余部分。
在驗證用戶的密碼輸入時，您的應用程序將越過字符串，并假定數據的前1個字節是salt的前1個字節，然后是salted哈希。此通行證將失敗。應用程序將繼續使用數據的前2個字節作為salt的前2個字節，并重復執行直到將前200個字節用作salt的前200個字節后找到肯定的結果。如果密碼錯誤，應用程序將繼續嘗試所有排列，直到找不到為止。
這種方法的優點：
增強的安全性-即使您的身份驗證邏輯已知，確切的邏輯在編譯時也是未知的。即使知道確切的邏輯，也幾乎不可能執行暴力攻擊。加鹽長度將進一步提高安全性。
這種方法的缺點：
由于在運行時可以推斷出確切的邏輯，因此這種方法會占用大量CPU。鹽的長度越長，此方法將占用更多的CPU。
驗證不正確的密碼將涉及最高的CPU成本。這可能會對合法請求產生反效果，但會提高針對攻擊者的安全性。
該方法可以以多種方式實現，并且可以通過使用可變寬度的鹽和/或鹽腌密碼哈希使其更加安全。
添加回答
舉報
0/150
提交
取消