在某些情況下，花椒會有所幫助。

作為一個典型示例​​，假設您正在構建Web應用程序。 Web應用程序代碼（在某些Web應用程序框架中運行，ASP.NET MVC，Python上的金字塔無關緊要）和用於存儲的SQL數據庫。 Web應用程序和SQL DB 運行在不同的物理服務器上。

最常見的數據庫攻擊是成功的SQL注入攻擊。這種攻擊不一定能訪問您的Web應用程序代碼，因為Web應用程序在其他服務器&用戶ID上運行。

您需要安全地將密碼存儲在數據庫中 ，並提出以下形式的內容：

  $ hashed_pa​​ssword = hash（$ salt。$ password） 

其中 $ salt 與 $ hashed_pa​​ssword 表示形式以及為每個新密碼或更改的密碼隨機選擇的 一起存儲在數據庫中。每個密碼哈希方案最重要的方面最重要的方面是 hash 是一種 slow 加密安全哈希函數，請參見 https：//security.stackexchange .com / a / 31846/10727了解更多背景知識。

然後問題是，假設為常量添加一個恆定值幾乎是零的努力。應用程序代碼，並且該應用程序代碼通常不會被破壞進行SQL注入攻擊，那麼下面的內容是否比上面的要好？

  $ hashed_pa​​ssword = hash（$ pepper。 $鹽。 $ password） 

，其中 $ salt 以明文形式存儲在數據庫中，而 $ pepper 是以明文形式存儲在數據庫中的常量。應用程序代碼（如果代碼在多個服務器上使用或源是公共的，則為配置）。

添加此 $ pepper 很容易-您只是在代碼中創建一個常量，輸入一個較大的加密安全隨機值（例如，來自/ dev / urandom hex或base64編碼的32byte）並在密碼哈希函數中使用該常量。如果您已有用戶，則需要一種遷移策略，例如，在下次登錄時重新哈希密碼，並在哈希旁邊存儲密碼哈希策略的版本號。

答案：

使用 $ pepper 確實增加了密碼散列的強度，如果數據庫的損害並不意味著的應用程序。在不了解Pepper的情況下，密碼仍然完全安全。由於密碼特定的鹽，您甚至無法找出數據庫中的兩個密碼是否相同。

原因是 hash（$ pepper。$ salt。$ password） 使用 $ pepper 作為鍵並輸入 $ salt。$ password 作為輸入有效地構建偽隨機函數（對於理智的 hash 候選對象，例如帶有SHA *，bcrypt或scrypt的PBKDF2）。偽隨機函數的兩個保證是，您不能從秘密密鑰下的輸出推論輸入，也不能在不知道密鑰的情況下從輸入推論輸出。這聽起來很像哈希函數的單向屬性，但是不同之處在於，使用像密碼這樣的低熵值，您可以有效地枚舉所有可能的值，並在公共哈希函數下計算圖像，從而找到其值圖像與原圖像匹配。使用偽隨機函數，沒有鍵就無法做到這一點（即沒有胡椒），因為沒有鍵就無法計算單個值的圖像。

如果可以長時間訪問數據庫，並且仍然可以從外部正常使用該應用程序，則 $ salt 在此設置中的重要作用將發揮作用。如果沒有 $ salt ，則可以將您控制的帳戶的密碼設置為已知值 $ passwordKnown ，然後將哈希值與未知密碼的密碼進行比較 $ passwordSecret 。作為 hash（$ pepper。$ passwordKnown）== hash（$ pepper。$ passwordSecret）的情況，當且僅當 $ passwordKnown == $ passwordSecret 時，您才可以將未知密碼與任何選擇的值（出於技術上的考慮，我假設哈希函數具有抗碰撞性）。但是如果加上鹽，則當且僅當 $ salt1時，您會得到 hash（$ pepper。$ salt1。$ passwordKnown）== hash（$ pepper。$ salt2。$ passwordSecret）。 $ passwordKnown == $ salt2。分別為 $ passwordKnown 和 $ passwordSecret code分別隨機選擇了$ passwordSecret 和 $ salt1 和 $ salt2 。 >鹽將永遠不會相同（假設隨機數足夠大，例如256位），因此您將無法再將密碼進行相互比較。

（注意：使用鹽僅是工作的一半；您還需要使散列函數變慢-因此攻擊單個低熵密碼仍然很困難。緩慢性通常是通過多次迭代或散列來實現的鹽和密碼的10000個副本的串聯。）

“胡椒粉”的作用是將哈希值轉換為 MAC。用散列函數製作一個好的，安全的MAC並不容易，因此，您最好使用 HMAC而不是自製的結構（將其用作抗碰撞散列函數的理論方法是

使用MAC，您可以 在以下意義上獲得一定的安全性：可能，攻擊者對數據庫的讀取訪問可能不再是一種安全。真正的問題。 MAC密鑰（“ pepper”）可以集中機密性需求。但是，這依賴於MAC也是一種單向函數，這是您可以從許多MAC構造（包括HMAC）中獲得的屬性，但是從密碼上來說，並不能真正保證它的存在（有些微妙之處）。

“ pepper”意味著您需要管理一個密鑰，包括以不會重啟的方式進行的安全存儲。密鑰很小並且適合RAM，但是由於存儲要求，目前尚不清楚它是否真正提高了安全性。可以讀取整個數據庫的攻擊者通常還可以讀取整個硬盤，包括任何“受保護”的文件。較小的按鍵可能允許某些高級設置，例如密鑰存儲在智能卡上，該智能卡在引導時使用，但之後未保持連接狀態。綜上所述，加薪是否值得付出的努力完全取決於具體情況，總的來說，我建議不要這樣做，以免增加複雜性。

我想指出胡椒的真正作用。

胡椒什麼時候提供幫助？

正如其他人已經指出的那樣，加入胡椒只是一個優勢。 ，只要攻擊者可以訪問數據庫中的哈希值，但無法控制服務器，因此不知道Pepper 。這對於SQL注入來說是典型的，因為它很容易做到，可能是更常用的攻擊之一。

Pepper有什麼改進？

  $ hashValue = bcrypt（'12345'，$ cost，$ salt）;  

即使正確使用了慢速鍵派生功能，也可以通過字典攻擊輕鬆獲得此密碼。將最常用的密碼放入字典中，並使用此弱密碼進行暴力破解。

  $ hashValue = bcrypt（'12345anm8e3M-83 * 2cQ1mlZaU'，$ cost，$ salt）;  

使用Pepper，弱密碼的長度會增加，現在包含特殊字符，更重要的是，您不會在任何詞典中找到它。因此，只要Pepper保持秘密，它就會防止字典攻擊，在這種情況下，它可以保護弱密碼。

編輯：

有與使用服務器端密鑰相比，這是一種更好的方法。使用胡椒，攻擊者必須在服務器上獲得其他特權才能獲取密鑰。通過首先計算哈希，然後使用服務器端密鑰對哈希進行加密（雙向加密），我們可以獲得相同的優勢。

  $ hash = bcrypt（$ passwort，$ salt）; $ encryptedHash = crypto（$ hash，$ serverSideKey）;  
  $ hash = bcrypt（$ passwort，$ salt）;  en>代碼> 

關於Unix密碼鹽化和迭代發明的論文（密碼安全性：案例歷史，Morris & Thompson，1978）也描述了胡椒的等效性：

用戶密碼的前八個字符用作DES的密鑰；然後使用該算法對常量進行加密。儘管此常數目前為零，但可以輕鬆訪問，並且可以依賴於安裝。

我還沒有聽說過使用它。還有其他人嗎？

就像BTW一樣，新的NIST數字身份指南（草案）也強烈建議也使用Pepper：

https://pages.nist.gov/800-63-3/ sp800-63b.html＃sec5

5.1.1.2記憶秘密驗證者：

...密鑰哈希函數（例如，HMAC [FIPS198-1] ]），並且密鑰應與散列的身份驗證器分開存儲（例如，在硬件安全模塊中），應進一步抵抗針對所存儲的散列的身份驗證器的字典攻擊。

請考慮以下情形：

我即將使用SQL注入方法闖入網站X，以檢索用戶列表以及其密碼哈希和鹽。假設網站X也在使用全局Pepper。

我要做的就是在網站X上用SQL注入之前我已知的用戶名和密碼註冊一個用戶。然後，對於數據庫中的特定記錄，我將知道密碼哈希，純文本密碼，salt（以純文本存儲），而根據此一條記錄來破解全局胡椒對我來說在計算上是微不足道的。

所以，實際上，胡椒將是使攻擊者在瑣碎的開銷時間內減速的一種方法。他們不必像預期那樣強行使用密碼+鹽+胡椒粉。

上面是選擇明文攻擊的一種形式。只要攻擊者知道算法（hash（）），輸出（$ hashed_pa​​ssword）以及所有輸入之一（“常量” $ salt & $ password和“變量” $ pepper），他們就可以“求解x就像線性代數方程式（h = s + p + x == hsp = x），但當然是蠻力。使Pepper長度超過bcrypt的限制56字節（448位），增加了時間成本，與bcrypt一樣好，但仍不如scrypt好。因此，只要胡椒足夠長，它就會有所改善。

對服務器如何隱藏全局Pepper常量不是很熟悉，但我的看法是滲透到服務器中的黑客遲早會弄清楚如何獲取Pepper的價值。安全將需要特殊的硬件。一種方法是使用服務器中安裝的FPGA板。 FPGA將包含用於執行哈希的代碼，包括Pepper值，並且所有哈希計算都在FPGA內部進行。使用FPGA，編程可以是一種單向功能。可以編程胡椒，但是沒有指令可以發送以將其讀出。胡椒粉將存儲在鎖在保險箱中的紙上。如果Pepper是隨機生成的128多個位，將沒有確定它的實用方法。
不確定會增加服務器硬件成本，因此不實用。