選擇哈希或加密密碼的困境

Question

在閱讀了一些在線文章和文章之後，似乎大多數人（如果不是全部的話）建議使用某種哈希算法來保持用戶的密碼安全，因爲您無法解決它，這很好，但那是我開始對我的情況有問題的地方。

現在我正處於修改我們確保用戶密碼方式的初期階段。我們目前使用Sha512將密碼密碼存儲在我們的MySQL DB中。根據我目前的理解，雖然散列可能是安全的，因爲它們不能相反（或者至少不那麼容易），但它也是不安全的，因爲有可能發生衝突，因爲散列具有固定的長度，不管大小如何原始輸入，這限制了可能的散列數量，從而導致可能的Pidgeon Hole問題。

現在來了另一個我有問題的部分，特別是對於我的情況。

我想添加一些功能，我們的用戶的密碼，如果用戶不能輸入一個新的密碼，如果它是過於相似，他們的最後三個密碼。例如：如果他們的最後一個密碼是password1234而他們的新密碼是xxxpasswordxxx，那麼它會失敗。但是，從我的理解來看，我不可能添加此功能，因爲我無法解決他們以前的密碼，以檢查舊密碼中是否有子字符串在其新密碼中。這將我帶到整個加密/解密部分。

我一直在尋找AES 128使用CBC加密模式，它似乎是一個可靠的選擇，因爲我真的不在乎在加密部分的並行化。除此之外，通過使用加密路線而不是散列路線，我實際上可以檢查他們的最後三個密碼是否與他們當前的密碼相似！但是，首先可以看到用戶的純文本密碼的問題是存在的。

此外，我一直在想辦法爲每個單獨的密碼使用唯一密鑰，而不將它存儲在我們的數據庫中，因爲我覺得這太不安全了。我可以對所有密碼使用靜態隨機密鑰，但我不確定這是否是一個好主意，即使我爲所有密碼使用了獨特的IV。

因此，總結我的情況是這樣的： 我希望能夠防止用戶輸入類似於他們的舊密碼的密碼，除了實際上提高密碼存儲的安全性。根據我目前的知識，我可以繼續將密碼存儲爲散列，但我無法進行類似的密碼檢查，或者我可以對密碼進行加密，這是令人不悅的。

我顯然不是這方面的專家，而且我知道我需要做更多的研究，但我想確保自己是從正確的方向開始的。

Answer 1

關於第二段：散列衝突是絕對不是有問題。對於哪種攻擊情形，你認爲這是一個問題？你應該停止投入流行語，特別是在安全方面。

你的功能主意會失敗，這是你的部分權利。這是一個很好的想法，因爲這個想法很糟糕。爲什麼你想要這個「功能」 - 它只會讓用戶惱火，並導致人們試圖繞過使用數字的限制，包括月份或其他版本的增加。

加密密碼不好 - 期間。
只要你可以解密他們，攻擊可以作爲故事的結尾。

---

幾乎你所描述的情景的個人體驗：客戶端有一個工具，您被迫更改密碼每2個月，我目前是"password"10。當我每X個月強制更改密碼時，我正在做每個人都警告的事情 - 只需逐個更改相同的密碼即可。我有一個非常好的密碼（15個以上的字符，大寫和小寫，數字，特殊字符），以及爲我設置帳戶的任何網站選擇密碼的系統。強迫我改變密碼破壞了我的「系統」，因爲現在我不能再一次又一次地在頭上生成密碼，因爲結果將不符合網站在前兩個月後設置的密碼。如果網站開始引入一些密碼相似性限制，我可能會開始寫下來。

Answer 2

要保密的方式，你必須哈希密碼加鹽。

對於每個用戶，您隨機選擇一個鹽，您爲每個用戶保存數據庫中的salt。 您存儲在數據庫哈希（密碼+鹽）。

當您必須檢查用戶密碼時，只需添加鹽，散列兩者並檢查數據庫。 如果用戶更改密碼，您也可以更改鹽。

之後，您可以根據安全級別選擇算法或其他算法，SHA2似乎是一個好的開始。

Answer 3

爲什麼不繼續使用散列，但要求用戶在更改爲新密碼時輸入舊密碼，這樣您就可以驗證舊密碼以授權更改密碼，然後比較純文本版本在進行更改之前是否有相似之處？

Answer 4

當您保留散列密碼時，您無法檢查相似的密碼，但可以防止它們重複使用之前使用過的密碼。通過保留舊的（希望是鹹的！）密碼，可以將散列（new_password + old_salt [i]）與舊密碼的salted_hash [i]進行比較。如果它們相同，則用戶重新使用舊密碼。

我完全同意其他哈希碰撞不是問題。您正計劃使用SHA512，即攻擊者必須與之競爭的512位隨機性。唯一可以破解的方法是使用rainbow tables，並且使用醃過的哈希來保護自己免受攻擊（即，即使密碼相同，醃製的哈希將導致不同的哈希值;如果攻擊者得到知道鹽和散列，所以你可以在一個位置存儲salt + salted_hash）。

出於安全原因，我會拋棄「類似密碼」的東西。如果攻擊者獲得了一堆密碼，則更改是數據庫中存在許多錯誤的密碼。使用啓發式和字典式攻擊，他會很好地改變猜測你的加密密鑰 - >立即解鎖所有用戶的所有密碼。

密碼的唯一安全方式是如果存儲它們的系統的操作員也無法恢復它們。其他任何事情只是下一個0天的bug等待被利用。

Answer 5

目前使用SHA512

SHA-512是太快存儲在我們的MySQL數據庫的散列密碼。任何獲取密碼哈希的攻擊者都可以通過哈希快速運行密碼猜測。你需要一個緩慢的算法，所以每個猜測都需要數千倍的時間。但是，由於您也需要對這些密碼進行散列，因此您需要選擇一個不會使系統過載的值，或者更糟糕的是，測試用戶的耐心。使用bcrypt（單獨）或PBKDF2與SHA-512（儘管SHA-1 HMAC綽綽有餘）結合使用。

它也是在不安全的有可能碰撞

SHA-512的碰撞性是沒有問題的，直到你的系統內接近2個用戶。由於這個星球上的人數甚至沒有，我可以肯定地說你的系統會好的。

選擇要麼散列或加密密碼

如果你需要一個理由去與前者的困境有一個看看details of the Adobe breach。他們正在加密密碼而不是散列。 TLDR;災害。如果您的系統尺寸適中，則不需要媒體就您的系統提供任何類似的內容。做好事情 - 使用PBKDF2或bcrypt - 這樣您就可以使用行業認可的方法來關注用戶，並且不會因爲您的密碼存儲方案而受到批評。

通過使用加密航線，而不是一個散列路線，我可以 真的這樣做檢查，看看他們的最後三個密碼 相似，他們目前的一個

好，因爲用戶（希望）可以輸入他們以前的密碼作爲額外的身份驗證檢查以更改他們的密碼，您可以在此處比較他們的密碼，因爲您將以明文形式輸入密碼。例如

old password != new password 
lowercase'd letters in old password != lowercase'd letters in new password 
adding up all numbers in new password > adding up all numbers in old password + 2 || adding up all numbers in new password < adding up all numbers in old password - 2 

也許你想定義一些其他規則來防止密碼相似性。如果這些規則適用於從第一個密碼到第二個密碼，然後是第二個密碼到第三個密碼的更改，則用戶可能會習慣您的規則，並且可能不太可能使他們的第三個密碼與他們的第一個密碼過於相似。您還可以保留一個密碼歷史記錄表，用於存儲其以前的X密碼（例如四個）的bcrypt哈希，並進行絕對比較以確保它們不會切換回以前使用的密碼。我不會保留超過四個，以防萬一他們以前的任何密碼足夠弱，無法破解並在其他網站上重複使用，因爲系統上的任何破壞都可能暴露他們，並且如上所述，檢查這些密碼會很慢處理。但是，您可以繼續確保用戶不會選擇任何違反密碼的密碼，方法是將常用密碼加載到系統的黑名單中。

密碼的加密是一個壞主意，並且對所有以前的密碼進行模糊匹配的安全優勢並沒有超過雙向加密活躍的安全風險（在我看來）。