最近，我一直在尋找添加一些項目的安全性。我一直在進行大量的研究，發現密碼哈希是必須的。此外，我得出結論，最好的選擇是使用bcrypt，PBKDF2或scrypt。散列，加密或兩者都
另外我也看到了關於哈希與加密的大量討論，並發現很明顯哈希更重要。也就是說，經過多次搜索谷歌深度之後，我還沒有找到任何有關加密已經適當散列的密碼是否有益的任何信息，這些信息會造成傷害或相對中性。
做這兩項工作的CPU成本是否值得呢？有沒有什麼陷阱？
加密某些東西會導致需要解密，這反過來會導致您已經擁有的問題：安全存儲祕密。
假設你要存儲密碼的哈希值，而不是純文本你基本上是這樣做的：
hashpw := hash(salt + password)
您然後存儲在一個文件中salt和hashpw和使用這些數據，而不是明文密碼。 （請注意，在許多情況下，鹽和密碼連接的順序是至關重要的，並且這只是過程的可視化，僅此而已;使用工具來生成鹽漬散列）。
一個可能的攻擊者則需要猜測鹽和明文密碼與 存儲hashpw，這是因爲你正在使用的哈希算法（碰撞率）作爲安全檢查的匹配。
使用某些密碼加密某些東西的好處是能夠恢復純文本，而散列方式並不提供這種純文本。它還要求解密密文的系統具有可用的密鑰 。假設您用一些密鑰bar加密字符串foo。要解密產生的密文 brn您需要再次輸入密鑰bar。此密鑰需要系統上的安全存儲，並且如果密鑰向攻擊者暴露 ，則所有安全性都將消失。
作爲一般經驗法則，我會說哈希提供了一種很好的方式來存儲 檢查的文本（例如密碼），因爲其安全性由散列算法的衝突率確定。另一方面，加密技術是您正在使用的技術來安全地存儲數據的其餘部分。
我只是簡單地加密密碼。散列速度很快，但對密碼有點不安全。當我出於安全目的使用散列時，通常用於消息簽名等。消息+散列（消息+密碼），以便可以驗證消息，但我不是該領域的專家。我沒有看到兩者兼而有之。
加密是可逆的。絕對不是一個獨立的解決方案 – foochow 2013-03-24 06:07:56
密碼加密通常是不被接受的。哈希是相當安全的，當與鹽結合時被認爲是最佳實踐。 – 2013-03-24 11:12:52
你在正確的軌道上。使用密鑰派生/密碼散列函數，就像你所提到的那樣。
不要只使用散列或鹽漬散列。主要問題是傳統的散列算法（MD5，SHA- *等）是快速的。這對密碼存儲沒有好處，並且許多實現都是易碎的，即使添加鹽也是如此。
加密總是引入與密鑰管理相關的問題。應該避免密碼存儲。
KDF的優點是工作因素。它的設計速度慢，計算成本高昂，這就是爲什麼他們想到這種情況。因爲Scrypt需要一定數量的內存才能執行，所以Scrypt是您正在查看的選項中最具彈性的選項。這會殺死GPU攻擊矢量。無論您選擇哪種方式都有權衡，但只要您在可配置的地方使用適當的工作因素，您的所有選擇都可以。
我喜歡你對密鑰管理有關加密的觀點，似乎與單獨使用散列最好用於密碼的共識一致 – foochow 2013-06-27 03:31:16
+1您的最後一段是關鍵部分 - 瞭解通行短語需要*確認*而不是*取回*。 – 2013-03-24 11:14:52
我同意鄧肯。最後一段確實指出了這個問題。由於它是一個確認問題，而不是檢索，因此單獨使用密碼似乎是一種方法。 – foochow 2013-03-24 17:01:17
@Foo_Chow - 實際上在加密散列值方面有益處。這可能是向散列添加服務器端祕密（胡椒）的最佳方式，我在[答案]（http://stackoverflow.com/a/16893270/575765）中解釋了這個問題。 – martinstoeckli 2013-06-27 09:41:46