在用Perl編寫並使用PostgreSQL的Web應用程序中，用戶擁有用戶名和密碼。建議存儲密碼的方式是什麼？建議如何在數據庫中加密用戶密碼？
使用Perl和隨機鹽的crypt()函數對它們進行加密？這將限制passswords的有用長度爲8個字符，並且需要獲取存儲的密碼以便與用戶在認證（提取附加到其中的鹽）時給出的密碼進行比較。
在PostgreSQL中是否有內置的方式來執行此操作？
我應該用Digest::MD5？
使用SHA1或SHA256哈希與醃製。這是存儲密碼的方式。
我建議將它存儲爲一個鹽醃的md5散列。
INSERT INTO user (password) VALUES (md5('some_salt'||'the_password'));
如果你願意，你可以在perl中計算md5散列，除非你是微優化的，否則它沒有太大的區別。
您也可以使用sha1作爲替代，但我不確定Postgres是否具有本地實現。
我通常不鼓勵使用動態隨機鹽，因爲它是另一個必須存儲在數據庫中的字段。另外，如果你的桌子受到損害，鹽變得毫無用處。
我總是隨機生成一次性鹽，並將其存儲在應用程序源代碼或配置文件中。
對密碼使用md5或sha1散列的另一個好處是您可以分別將密碼列定義爲md5和sha1的固定寬度CHAR（32）或CHAR（40）。
如果您不使用密碼恢復機制（不是密碼重置），我認爲使用哈希機制比嘗試加密密碼要好。你可以檢查哈希值，沒有任何安全風險。即使你不知道用戶的密碼。
考慮到他提到了Perl的crypt（）函數，它「恰如C庫中的crypt（3）函數一樣創建摘要字符串」，我懷疑他/她知道他們應該使用哈希機制，並且使用了錯誤的術語。 – 2010-01-07 09:49:54
PostgreSQL中的pgcrypto模塊已經內置了密碼散列suppotr，這是非常聰明的存儲，生成，多算法等見http://www.postgresql.org/docs/current/static/pgcrypto.html，在密碼散列函數部分。您還可以看到http://www.hagander.net/talks/hidden%20gems%20of%20postgresql.pdf的pgcrypto部分。
我最近已經實現了pgcrypto，並且在你的數據庫上工作很煩人（而且你必須真正小心你的查詢使用它，如果你以某種方式格式化它們，真的會減慢執行速度）。你必須安裝模塊，以root身份運行一個腳本，然後才能使用'crypt'。它是安全的，但不容易添加。 如果你有一個好的代碼級哈希算法，那可能是一個好的選擇。 – Kzqai 2010-06-29 23:00:29
MD5常用，但SHA1/SHA256更好。仍然不是最好的，但更好。
所有這些通用哈希算法的問題是，它們的優化速度很快。然而，當你將你的密碼散列存儲時，快速就是你想要的不需要 - 如果你可以在一微秒內散列密碼，那麼這意味着攻擊者每秒可以嘗試一百萬個密碼手上你的密碼數據庫。
但是你想盡可能減慢攻擊者的速度，不是嗎？使用一個十分之一秒的算法來代替密碼是不是更好？十分之一秒仍然足夠快以至於用戶通常不會注意到，但擁有數據庫副本的攻擊者每秒只能嘗試10次嘗試 - 要花10萬次才能找到工作集的登錄憑證。每個小時，每次嘗試只需要十分之一秒的時間，每次嘗試的時間就會變成11個年。
那麼，你如何做到這一點？一些人通過運行多輪MD5/SHA消解來僞造它，但是bcrypt算法是專門爲解決這個問題而設計的。我不完全理解它背後的數學，但我被告知它基於Blowfish框架的創建，這本質上很慢（不像MD5操作，它可以在正確配置的硬件上大大精簡），它有一個可調的「成本」參數，因此，隨着摩爾定律的發展，您所需要做的就是調整「成本」，以便在今天的十年內保持密碼散列速度與十年一樣緩慢。
+1。有趣。 – 2010-01-08 00:16:41
+1注意到更安全的方法的額外時間通常不會被最終用戶注意到。 – 2011-04-05 16:32:37
不像大多數人所暗示的那樣，不要使用SHA1或SHA256。 絕對不要使用MD5。
SHA1/256和MD5都設計用於創建文件和字符串（以及其他數據類型，如有必要）的校驗和。正因爲如此，它們被設計得儘可能快，所以校驗和很快產生。
這樣快的速度使密碼暴力變得更容易，因爲一個寫得很好的程序很容易每秒產生數以千計的哈希值。
而是使用專門爲密碼設計的緩慢算法。它們的設計需要花費更長時間才能生成，其優勢在於暴力攻擊變得更加困難。正因爲如此，密碼將更安全。
如果您只是一次只查看一個密碼，這是存儲和檢查密碼的常規實現，您不會遇到任何重大的性能劣勢。它只是在實際區別的大部分。
我個人比較喜歡bcrypt。應該有一個可用的Perl版本，因爲快速的谷歌搜索產生了幾個可能的匹配。
你不知道你在說什麼，遠離安全標籤。消息摘要算法意味着要快速消解數據，並儘量不可逆轉。 NIST不會批准緩慢的加密算法。 – rook 2010-01-08 02:55:34
我不是在說反轉，我在說暴力。如果我不知道我在說什麼，我認爲像Paul Buchheit（1）（Gmail的創建者）和Phusion（2）這樣的人也不知道？即使Google建議（3）在其中一個項目中進行加密。這些只是我通過谷歌搜索「使用bcrypt」發現的一些鏈接。 – vonconrad 2010-01-08 03:41:55
以前評論的鏈接： 1：http://paulbuchheit.blogspot.com/2007/09/quick-read-this-if-you-ever-store.html 2：http：//blog.phusion .nl/2009/08/13/secure-store-passwords-with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/ 3：http：//code.google。com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ – vonconrad 2010-01-08 03:46:14
我喜歡bcrypt最好的，SHA2（256）接近第二。我從來沒有見過MD5用於密碼，但也許有些應用程序/庫使用它。請記住，你應該總是使用鹽。鹽本身應該是完全獨特的每個用戶，並在我看來，儘可能長。我永遠不會只用一個哈希來對付一個沒有添加鹽的字符串。主要是因爲我有點偏執，還有一點更加面向未來。
在用戶再次嘗試和自動鎖定（使用自動管理通知）之前延遲也是一個好主意。
還記得鹽你的密碼。 http://www.aspheute.com/english/20040105.asp – 2010-01-07 13:55:04
請確保您不需要支持基於哈希的身份驗證方案。由於支持LDAP {SSHA}方案的新要求，我很遺憾我決定在數據庫中散列密碼。 – 2010-01-07 14:30:36
@ZZ編碼器：爲什麼會出現這個問題？只需創建新的設置，並在用戶登錄時執行一些幕後的魔法，以便在新數據庫中升級她。您應該*永遠不會*存儲可以以純文本格式檢索的密碼，而散列則是一種很好的方法。 – 2010-01-07 19:02:14