密碼哈希與真正的隨機鹽或用戶名鹽加胡椒粉？

考慮以下兩種方法：密碼哈希與真正的隨機鹽或用戶名鹽加胡椒粉？

hashedPassword = hash(trulyRandomSalt + password)

凡hashedPassword和trulyRandomSalt都存儲在數據庫中。

hashedPassword = hash(applicationConstantPepper + uniqueUserName + password)

凡hashedPassword和uniqueUserName存儲在數據庫和applicationConstantPepper存儲在應用程序配置。在這裏，uniqueUserName作爲一個鹽，通常是電子郵件地址。

我讀過這個question，它有很多很好的信息，但沒有解決應用程序不斷胡椒值，以及如何改善使用用戶名作爲鹽。

我總是使用方法一與32位加密隨機鹽。但是，我剛剛看到方法二在另一個應用程序中使用。我在方法二中遇到的第一個問題是，它將用戶名與哈希關聯，以便在不重新生成哈希的情況下永遠不會更改用戶名。

方法二的安全性問題是什麼？這將是最好的方法來使用？

來源

2014-03-25 Jason Eades

考慮以下兩種方法：

第一種方法是可怕的，因爲它允許攻擊者誰得到您的哈希使用像oclHashcat進行，通常情況下，每月的猜測萬億或quadrillions，第二個是可怕的，因爲這些相同的攻擊者不但可以每月進行相同的，通常每秒數萬億次的猜測，如果他們在獲取密碼之前掌握applicationConstantPepper和用戶名，他們可以預先計算他們的工作量獲取您的密碼。

請閱讀How to securely hash passwords?，其中Thomas Pornin寫道：「爲了使胡椒真正適用，您需要處於一個特殊的環境中，而不僅僅是一臺帶有磁盤的PC;您需要一個HSM。請閱讀上下文中的整篇文章，但它的要點是：

不要使用PBKDF2（也稱爲RFC2898和PKCS＃5V2），BCrypt，或SCrypt。
不管使用一次散列算法，不管你的調味品有多好。
請使用8-16字節的密碼隨機鹽。
使用最高迭代次數/工作因子，因爲您的機器可以在高峯負載下處理而不會導致用戶抱怨。
特別是對於PBKDF2，請不要請求或使用比散列函數的本機大小更多的輸出字節。
- SHA-1的20字節
- SHA-224的28字節
- SHA-256 32字節
- SHA-384的48個字節
- SHA-512 64字節
如果對於64位系統，請考慮使用PBKDF2-HMAC-SHA-384或PBKDF2-HMAC-SHA-512，這會降低2014年復古GPU對攻擊者的優勢。

如果你喜歡辣椒的概念，請再次閱讀Password Hashing add salt + pepper or is salt enough?，特別是Thomas Porrin的回答。

來源

2014-03-25 02:48:02

托馬斯·波林錯過了一些微妙的觀點（或者他知道他們，但他畫的畫面太寬泛）。 – jww

特別要指出的是，爲什麼不建議他們對該答案發表評論或編輯，所以他們可以被納入這樣一個流行的問題和答案？ –

「...爲什麼不建議他們在評論或編輯該答案」 - 這不是一個我有興趣打架的戰鬥。 – jww

考慮以下兩種方法...

也不是特別好....

什麼是與方法二的安全問題？

OWASP的John Steven提供了與密碼散列和存儲相關的更好的寫作之一。他帶領您瞭解各種威脅，並解釋爲什麼事情是以某種方式完成的。見

這將是最好的方法使用？

hashedPassword = hash(applicationConstantPepper + uniqueUserName + password)不提供語義安全性。也就是說，使用不斷的胡椒和用戶名，對手可以告訴一位神諭是否用隨機答案或真實答案回答。

hashedPassword = hash(trulyRandomSalt + password)可能相當於或略微好於其他方法。每個用戶的隨機鹽有很多理想的屬性。但它也可以改進。

最後，爲什麼要重新發明輪子？轉到Openwall的Portable PHP password hashing (phpass)並使用它。它由John the Ripper的作者撰寫。太陽能設計師密切關注密碼破解技術的發展狀況，因此圖書館在實踐中可能非常有用。

來源

2014-03-25 02:49:42 jww

你說這些輸入都不是很好。什麼會爲散列函數提供更好的輸入？ – Rick

@Rick - 你可能想放棄所有哈希，並使用密鑰哈希。密鑰散列是一個HMAC。你也可能想迭代輸入，而不是使用一次迭代。具體應用的胡椒可能是很好的。從更大的角度來看，這個問題不適合Stack Overflow。需要說明安全目標，並且需要執行分析。問其他程序員他們所做的是導致無用的答案無效的背景和分析。你應該閱讀約翰史蒂文斯的材料。 – jww

謝謝，我明白你的觀點，安全上下文確實需要定義以獲得有用的答案。對於密碼哈希，我認爲一旦你有一個獨特的鹽，長度擴展攻擊沒有任何用處，所以迭代哈希和密鑰哈希之間的差異可以忽略不計。除了對長度擴展攻擊的防護外，您是否還知道HMAC的另一個優勢是迭代哈希？ – Rick

除了反弱密碼的答案，我想指出，這兩個（鹽和胡椒）都有其目的。如果同時應用，則使用隨機salt並將其存儲在數據庫（不是derrived的數據庫）中，然後使用服務器端密鑰（胡椒）加密密碼哈希。

我寫了一個tutorial，其中對胡椒的優缺點進行了更深入的解釋。即使密鑰不能完全保護，使用服務器端密鑰也是一個優點。

來源

2014-03-26 09:56:21 martinstoeckli

兩種方法都大致相同，並罰款，只要你使用一個好的哈希（見其他答案）

使用用戶名是否該用戶名可以重新使用的問題。如果您不包含特定於應用程序的前綴，這可能是一個巨大的問題，因爲用戶名可能在很多地方使用過，因此可能已經有一個適合該用戶名的彩虹表。

「胡椒」通過要求彩虹錶針對您的應用程序來幫助緩解此問題。現在，只有用戶頻繁更改密碼纔會成爲問題，因爲攻擊者現在可以通過生成一個彩虹表來獲取所有舊密碼，而不是每次搜索只獲取一個密碼。在我看來，這是一個可以忽略不計近缺點，如

大多數人都沒有更改他們的密碼經常
攻擊者仍然要訪問的散列他們要破解每個密碼，等了一個實時數據庫違規將不會有任何區別。
任何經常更改密碼的人都可能不會在其他地方重複使用相同的密碼，因此獲取的其他密碼不太有用。

總的來說，從攻擊者的角度來看，如果與胡椒結合使用它們的獨特性，使用用戶名作爲鹽的目標沒有太多收益。

來源

2016-10-17 17:39:16 Rick

密碼哈希與真正的隨機鹽或用戶名鹽加胡椒粉？

回答

相關問題