替換應用程序的純文本密碼

Question

我們目前正在爲我們擁有的Web應用程序存儲純文本密碼。

我一直主張移動到密碼哈希，但另一個開發人員說這不太安全 - 更多的密碼可以匹配哈希和字典/哈希攻擊會更快。

這個說法有沒有道理？

Answer 1

絕對沒有。但沒關係。我之前發佈過類似的回覆：

這很不幸，但是人們甚至程序員都太情緒化，不容易被爭論所左右。一旦他投入了自己的職位（如果你在這裏發帖，他就是），你不可能單憑事實說服他。你需要做的是切換舉證責任。你需要讓他找出他希望能說服你的數據，並且這樣做才能瞭解真相。不幸的是，他有現狀的好處，所以你有一個艱難的道路。

Answer 2

我不是安全專家，但我有一種感覺，如果純文本更安全，哈希將不存在在第一位。

Answer 3

絕對沒有理由在web應用上保留純文本密碼。使用具有鹽值的標準哈希算法（SHA-1，不是MD5！），因此不可能發生彩虹攻擊。

Answer 4

如果你不加鹽了密碼，你嫌疑人彩虹表攻擊（即對一個給定的哈希有效輸入預編譯字典）

其他開發商應該停止談論安全，如果你存儲密碼在明文和開始閱讀有關安全。

碰撞是可能的，但通常不是密碼應用程序的大問題（它們主要是使用散列作爲驗證文件完整性的方式的一個問題）。因此：使用密碼（通過將Salt添加到密碼*的右側）並使用像SHA-1或SHA-256或SHA-512那樣的良好散列算法。

PS：有關Hashes here的更多細節。

*我有點不確定Salt是否應該到字符串的開頭或結尾。問題是，如果你有碰撞（兩個輸入具有相同的散列），將Salt添加到「錯誤」一側不會改變產生的散列。無論如何，你不會有彩虹表的大問題，只有碰撞

Answer 5

我不明白你的其他開發者的東西'更多的密碼可以匹配散列'。

有一個'散列攻擊會更快'的說法，但前提是你不要在密碼被哈希時進行醃製。通常情況下，哈希函數允許您提供一個鹽，這使得使用已知哈希表浪費時間。

就我個人而言，我會說'不'。基於上述情況，以及事實上，如果你以某種方式獲得明文暴露，那麼對於嘗試進入的人來說，醃製的散列值是沒有多大價值的。散列還提供了使所有密碼「看起來」相同的長度。

即，如果散列任何字符串總是導致20個字符的散列，那麼如果您只有散列來查看，則不能分辨出原始密碼是8個字符還是16個例如。

Answer 6

理論上，是的。密碼可以比散列更長（更多信息），所以存在散列衝突的可能性。但是，大多數攻擊都是基於字典的，碰撞的概率比成功的直接匹配小得多。

Answer 7

更多的密碼可以匹配散列，字典/散列攻擊會更快。

是和否。使用現代哈希算法，就像SHA變體一樣，並且該參數非常非常周。你真的需要擔心，如果這場蠻力攻擊只需要352年而不是467年呢？ （那裏有個軼事的笑話。）要獲得的價值（沒有在系統上以明文形式存儲密碼）遠遠超過了你的同事的關注。

Answer 8

從Wikipedia

一些計算機系統存儲用戶密碼 ，用以比較的嘗試 用戶登錄，如明文。如果 攻擊者獲得訪問這樣一個 內部密碼存儲區，所有密碼 等等所有用戶帳戶將 妥協。如果某些用戶對 不同系統上的帳戶使用相同的密碼 ，那麼這些帳戶也會被 損害。

更安全的系統存儲在加密 保護形式各 密碼，所以獲得了 實際的密碼仍然會 困難誰獲得了對系統 內部訪問探聽器，而用戶訪問嘗試 的 驗證仍然有可能。

一個普通的approache只存儲一個 「散列」形式的密碼 密碼。當在這樣的系統上的 密碼的用戶類型，該 密碼處理軟件運行 通過密碼散列 算法，如果從用戶的條目 生成的散列值 存儲在 密碼數據庫中的哈希值匹配時，用戶是 允許訪問。散列值是 ，通過將密碼 散列函數應用於所提交的密碼的 和通常爲 鹽的另一個值組成的字符串創建。 salt可防止來自 的攻擊者爲 常見密碼構建哈希值列表。 MD5和SHA1是 經常使用的加密哈希 函數。

還有很多內容您可以閱讀該頁面上的主題。在我看來，在我閱讀和處理過的所有內容中，散列是一個更好的場景，除非你使用一個非常小的（< 256位）算法。

Answer 9

有一個事實，如果你散列的東西，是的，會有碰撞，所以有可能兩個不同的密碼解鎖相同的帳戶。

從實際的角度來看，這是一個糟糕的參數 - 一個好的散列函數（md5或sha1會很好）幾乎可以保證對於所有有意義的字符串，特別是短字符串，不會有衝突。即使有，兩個密碼匹配一個帳戶也不是一個大問題 - 如果某人有能力隨機猜測密碼足夠快以至於他們可能能夠進入，那麼問題就更大了。

我認爲以純文本存儲密碼比密碼匹配中的散列衝突代表了更大的安全風險。

Answer 10

這取決於你對抗什麼。如果攻擊者拉下你的數據庫（或者欺騙你的應用程序顯示數據庫），那麼明文密碼就沒用了。有很多攻擊依賴於說服應用程序釋放它的私有數據 - SQL注入，會話劫持等。通常最好不要保留數據，而是保持散列版本，使壞人不能輕易使用它。

正如你的同事們所建議的那樣，這可以通過對字典運行相同的散列算法並使用彩虹表將信息提取出來而平庸地擊敗。通常的解決方法是使用一個祕密鹽加上額外的用戶信息進行散列結果獨特 - 是這樣的：

String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() + user.getPassword); 

只要你的鹽是祕密的，或者你的攻擊者不知道的確切創建日期用戶的記錄，字典攻擊將失敗 - 即使他們能夠拉下密碼字段。

Answer 11

我在我的工作場所遇到了同樣的問題。我做了什麼來說服他哈希更安全的是編寫一個SQL注入，它從我們網站的公共部分返回用戶名和密碼列表。它是升級的時候了作爲一個主要的安全問題:)

爲了防止對字典/哈希攻擊一定要湊對的令牌是唯一的每個用戶和靜態（用戶名/加入日期/ userguid效果很好）

Answer 12

沒有什麼比存儲純文本密碼更安全。如果你正在使用體面的哈希算法（至少SHA-256，但即使SHA-1比沒有好），那麼是的，碰撞是可能的，但它並不重要，因爲給定一個哈希值，不可能*計算出什麼字符串散列到它。如果你用密碼對用戶名進行散列，那麼這種可能性也會消失。

* - 在技術上不是不可能，而是「計算上不可行」

如果用戶名是「格雷姆」，密碼爲「計算器」，然後創建一個字符串「格雷姆 - 計算器-1234」，其中1234是隨機數字，然後散列它並在數據庫中存儲「散列輸出 1234」。在驗證密碼時，從儲值結束處獲取用戶名，提供的密碼和數字（哈希具有固定長度，以便始終可以執行此操作）並將它們散列在一起，然後將其與哈希值進行比較存儲值的一部分。

Answer 13

有句老話約程序員故作密碼學家:)

傑夫阿特伍德對這個問題的好崗位：You're Probably Storing Passwords Incorrectly

更廣泛地回覆，我同意所有上述情況，散列使​​得理論上更容易以獲得用戶的密碼，因爲多個密碼匹配相同的散列。但是，與訪問數據庫的人相比，這種情況發生的可能性要小得多。

Answer 14

希望你原諒我堵的解決方案我在這寫的，使用客戶端的JavaScript它的傳輸之前散列密碼：http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html