我一直在尋找方法來保護我的用戶密碼。我目前正在使用哈希算法和隨機鹽的組合。如何保護加密密碼即使是最弱的一個？
這個問題的主要原因是當我的用戶設置一個非常非常弱的密碼。無論我的混合哈希算法有多困難，以及我的鹽有多久，我認爲它可以在不到一年的時間內被破解。
我一直在想一個新的方式。我已經創建了一個腳本，每次用戶通過在舊的散列密碼上添加一個隨機鹽註銷，然後再次加密，就會重新加密密碼。所以，每次用戶回來時，加密的密碼都是不同的。得到它？
但是這個想法的主要問題是，每次用戶註銷時我都必須存儲新鹽。想象一下，如果用戶每天都登錄和註銷，我的代碼看起來就像：
有什麼想法？
哦，我有一個想法。如何每年重新生成新的加密密碼？
您的主要假設有兩個問題。第一個是關於儲存鹽的問題。你已經爲醃製密碼解決方案做了。用你的新方法，鹽會隨着時間而改變，就是這樣。所以你可以使用這種方法，並且唯一的額外成本是在每次登錄時重新計算散列值（當你實際上擁有密碼字符串本身時）。
第二個問題是更重要的問題：重新哈希不會改變任何東西。一旦攻擊者獲得了一個醃製散列值，就足以裝入字典式攻擊。事實上，你改變你的鹽和數據庫中的散列不會讓它變得更困難。所以在創建第一個散列之後不需要重新計算散列。
重新加密不能解決您的問題。
你唯一能做的就是創建一個多部分哈希，並且希望攻擊者不會得到所有這些哈希。我通常使用兩部分鹽：
一部分是隨數據庫中隨機存儲的每個用戶值。
另一部分是每個應用鹽。您可以將其存儲在應用程序配置中或OS提供的特殊密碼存儲區中。
該拆分的優勢在於，如果攻擊者只是獲得對數據庫的訪問權限是不夠的，但他需要訪問應用程序salt的存儲位置。因此，例如，一個簡單的SQL注入竊取你的數據庫是不夠的。如果攻擊者可以執行代碼，它可能根本沒有任何幫助。
而且你應該使用一些方法來減緩哈希。典型的散列函數速度很快，所以蠻力也很快。但是，如果你迭代哈希函數一百萬次，它仍然不會減慢有效的登錄速度，但會大大減緩蠻力。
您可以使用Password Based Key Derivation Function（如PBKDF2）來實現此目的。
我明白了。所以這個想法是儘可能降低蠻力。我會嘗試這一個。 – dimassony 2011-02-27 13:58:00
這是第二部分的想法。但是，當然，您的合法登錄次數也會減少相同的因素。所以這是登錄的計算成本和放慢攻擊者之間的折衷。根據用戶數量的不同，服務器應用程序可能需要10毫秒左右的時間，而磁盤加密時間則需要1秒左右。 – CodesInChaos 2011-02-27 14:10:15
您可以使用「密鑰延伸」：在醃製後迭代哈希，例如，一百萬次。 然後存儲哈希值，鹽值和迭代次數。 然後，攻擊者每秒可能比每次散列一次檢查密碼減少百萬次。但是一個非常短的密碼仍然會下降：請注意，您自己要驗證合法密碼，需要執行相同的操作。假設你接受1秒的時間讓自己檢查，那麼攻擊者也可以在類似的機器上檢查每個密碼1秒的密碼（如果他使用更多或更快的機器，則更多）。每個密碼1秒仍然足以檢查弱密碼和短密碼，標準字典等。實際上沒有防禦措施，只會讓它更難。
只要使用很長的鹽，或開始執行人民的密碼標準。 – Marcin 2011-02-27 13:45:54