在散列之前是否將一個常量字符串添加到用戶的密碼使其更安全？

Question

在散列之前是否將代碼中存儲的常量字符串添加到密碼中使得攻擊者難以找出原始密碼？

這個常量字符串是除鹽之外的。因此，Hash(password + "string in code added to every password" + randomSaltForEachPassword)

通常情況下，如果攻擊者拿到他們的數據庫，他們可能通過蠻力找出某人的密碼。數據庫包含與每個密碼相對應的鹽分，因此他們會知道應該用什麼方法來限制他們的蠻力嘗試。但是，通過代碼中的常量字符串，攻擊者還必須獲得源代碼，以瞭解要對其每個暴力試圖追加什麼內容。

我認爲這會更安全一些，但我希望得到別人的想法，同時也要確保我不會無意中使其不那麼安全。

Answer 1

鑑於您已經有了一個隨機salt，所以附加其他字符串既不會增加安全級別也不會降低安全級別。

基本上，這只是浪費時間。

更新

這是越來越有點長使用的意見。

首先，如果攻擊者擁有數據庫，並且唯一加密的是密碼，那麼無論如何遊戲。他們擁有的數據是真正重要的部分。

其次，鹽意味着他們必須創建一個更大的彩虹表，以包含更大的密碼長度可能性。這取決於鹽的長度和裂解器可用的資源而變得不切實際。看到這個問題了一點信息： How to implement password protection for individual files?

更新2 ;）

這是事實，用戶重複使用的密碼（如一些最新的被黑網站的顯示），並要它的好防止數據丟失影響他們。但是，一旦閱讀完此更新，您將會看到爲什麼這不是完全可能的。其他問題將不得不一起考慮。 salt的全部用途是確保相同的兩個密碼導致不同的散列值。每個salt值都需要創建一個包含所有密碼哈希可能性的彩虹表。

因此，不使用鹽值意味着可以引用單個全局彩虹表。這也意味着，如果您只對網站上的所有密碼使用一個salt值，那麼他們又可以創建一個彩虹表並一次獲取所有密碼。

但是，當每個密碼有一個單獨的鹽值時，這意味着他們必須爲每個鹽值創建一個彩虹表。彩虹表需要時間和資源來建立。可以幫助限制創建表所需時間的事情是知道密碼長度限制。例如，如果您的密碼必須介於7到9個字符之間，那麼黑客只需計算該範圍內的散列值。

現在鹽值必須可用於要散列密碼嘗試的函數。一般來說，你可以在別處隱藏這個值;但坦率地說，如果他們已經竊取了數據庫，那麼他們就可以很容易地追蹤到它。因此，將值放在實際密碼旁邊對安全性沒有影響。

添加額外的字符是所有密碼共同的沒有增加任何混合。一旦黑客破解第一個，很明顯其他人有這個價值，他們可以相應地編碼他們的彩虹表生成器。這意味着它基本上不會節省時間。此外，它會導致您的安全感錯誤，從而導致您做出錯誤的選擇。

---

這導致我們回到salting密碼的目的。目的不是爲了使它不可能，因爲有時間和資源的任何人都可以破解它們。目的是讓它變得困難和耗時。耗時的部分是讓您有時間檢測到中斷，通知您需要的所有人，並在系統中強制更改密碼。

換句話說，一旦數據庫丟失，應通知所有用戶，以便他們可以採取適當的措施在您的系統和其他系統上更改密碼。鹽只是買你和他們的時間來做到這一點。

我之前提到的「不切實際」之所以關於破解它的原因是，這個問題實際上是黑客確定密碼的價值與破解密碼的成本之間的一個問題。使用合理的鹽值可以將計算成本提高到足以讓很少黑客煩惱的程度。他們往往是低掛水果的人;除非你有理由成爲目標。此時您應該查看其他形式的身份驗證。

Answer 2

這隻有在您的威脅模型包含攻擊者以某種方式獲取您的密碼數據庫但無法讀取存儲在您的代碼中的密鑰的情況下才有所幫助。對於大多數人來說，這不是一個非常可能的情況，所以它不值得迎合。

即使在這種有限的情況下，它也不會爲您帶來很多額外的安全性，因爲攻擊者可以簡單地使用自己的密碼並遍歷所有可能的密鑰值。一旦他們找到了正確的密碼（因爲密碼正確），他們就可以像通常那樣攻擊數據庫中的所有其他密碼。

如果你擔心安全地存儲密碼，你應該使用一個標準的方案，如PBKDF2，它使用密鑰伸展使暴力強制更不實際。