您問題的真正答案是，如果無法正確保護密碼，則不要在此處存儲密碼。

“系統不支持正確的密碼哈希算法”不是妥協密碼的有效藉口用戶的安全性。要么找到一種使用功能強大且配置正確的算法正確散列密碼的方法，要么不存儲它們。

但是要直接回答您的問題：是的，總比沒有好。 SHA-1或SHA-2絕對是對純文本的改進。

要回答“那麼密碼應該放在哪裡？”問題-基於短語，我假設該軟件有一個新功能/要求，要求系統存儲密碼。

如果系統不能正確安全地存儲密碼（按照現代安全標準），那麼我（個人）將拒絕該請求。由於遺留系統的限製而故意實施較差的安全性或安撫業務用例是不良的安全性做法。我會告知提出要求的人，我有兩個可行的選擇：

是的，弱加密哈希總比沒有哈希好。

哈希密碼的原因是，如果您的密碼數據庫被盜：

1. 防止攻擊者輕易獲得純文本密碼。
2. 防止攻擊者知道哪些用戶具有相同的密碼（這是通過為每個用戶分配唯一的密碼來實現的。
ol>

1是一場軍備競賽：您想使用更大，更慢的哈希函數，以便使攻擊者花費更多的電力來執行暴力哈希破解。SHA-1/ 2的一次迭代比沒有哈希更好，因為攻擊者必須進行 some 破解。 saltted SHA-1 / 2的一次迭代將迫使他們進行某些破解，而無法使用預先計算的彩虹表。如果工作係數更高，則升級到更高級的密碼哈希（arg2，bcrypt或更舊的scrypt，pbkdf2）會進一步提高破解的電費。

使用任何鹽漬的隱秘不規則的哈希（即使不建議使用密碼的哈希，例如SHA-1，SHA-2）也會帶來2的好處。

---

PBKDF2的核心只是迭代並加鹽SHA-1 / 2，因此我將對PBKDF2實現進行一些谷歌搜索，並圍繞SHA-1 / 2對其進行仿真以構建包裝器（或者更好的是，一直進行並實際實現PBKDF2）。

就像其他人所說的那樣，請盡可能嘗試使用平台語言找到一個強大的獨立實現。

但是，如果您不能使用一個強大的哈希值，那麼您應該肯定仍會散列用戶密碼，即使是弱散列-因為即使是弱散列也會保護強密碼。

像hashcat這樣的工具可以猜測每秒數十億個密碼，弱哈希無法保護弱密碼。但是，如果您的一個注重安全性的用戶選擇了一個不可破解的密碼，例如“ SDXBZsRVBKVnXznpLTBMIKhTX”或“ afferently-imitatee-snowmelt-heirdom-leeching”……那麼即使是像SHA1這樣的弱哈希也仍然會將該密碼置於暴力破解範圍之外

即使使用弱哈希，您也可以至少使精明的用戶保護自己，即使您的系統很弱。 （而且，如果您有能力 stretch -連續使用數千次相同的算法-這也會降低攻擊者的速度。）

但是您精明的用戶不會重用密碼，因此，即使密碼價值有限（“半精明”的用戶選擇的密碼強度足以抵禦暴力破解，但可能會在其他地方重用該密碼或使用可人工解析的密碼選擇方案。） ..因此即使使用弱哈希也可以保護這些用戶）。

對所有用戶來說，最好的選擇是找到使用強哈希的方法。

[編輯：OP更新了問題以表明他們是系統的唯一用戶，並且可以設置任意隨機密碼（對我來說這很奇怪；我不知道知道一個系統具有“我是唯一的用戶”，“我只能從一些哈希算法中挑選”和“所有哈希算法都很弱”這樣奇怪的組合）。無論哪種方式，這都使我擔心與該特定問題無關的保護普通用戶的弱密碼。其他答案應在他們的答案開始時澄清它們在提供通常很差的建議，並且僅適用於這個非常具體的問題。]

[編輯2：請注意，“弱哈希”和“壞哈希”不是一回事。哈希錯誤的一個例子是解密（因為它會截斷8個字符的密碼）。因此，即使您的密碼很安全，也可以在生產級（6 GPU）破解系統上在10天或更短的時間內強行破解8個字符的解密哈希。]

在這種特殊情況下，SHA-2與PBKDF / scrypt / bcrypt一樣安全。迭代是不必要且浪費的。生成高熵（256位）密碼，而忘記了KDF甚至鹽。

實際上，使用SHA-2比使用PBKDF更有意義，因為沒有現成的平台實現算法和“滾動自己的加密貨幣”是不行的。

這是一個很強的說法。問題的本質在於，OP可以完全控制他在系統上存儲的密碼，並且知道他將是唯一在系統上存儲密碼的人。

信號在其雙重棘輪算法中使用了一種稱為HKDF的結構，該結構實際上僅將哈希算法應用於一次迭代。

為什麼這樣可以？

幾乎所有哈希函數（甚至是MD4，MD5和SHA-1） ，但是由於您說過平台上已裝有SHA-2，因此請放心）具有稱為原像抵抗的功能，該功能對於您的應用程序來說足夠好，因為您可以控制所有存儲的密碼在您的系統上。這意味著在給定哈希值的情況下，生成在相同哈希值中哈希的東西在計算上是不可行的。

簡化一點，為這些哈希函數之一生成原像的最實用方法是保持嘗試輸入。有一些示例的攻擊要比暴力破解略好一些，但完全是不可行的。現在，如果您選擇放入哈希函數中的密碼/密鑰僅具有16位熵，那麼此抵抗屬性將無濟於事，因為攻擊者將能夠嘗試所有您可以輸入的65536種不同輸入。

為什麼控制密碼很重要

請少輸入“密碼”，而多輸入加密密鑰。只要您對具有大於或等於您選擇的哈希函數輸出的位數（對於SHA-256，即256位）的熵的哈希鍵進行哈希處理，那麼只運行一次哈希迭代就可以了防止密鑰提取。散列的圖像前阻力加上密鑰的高熵意味著攻擊者無法猜測您輸入的值。無需進行數千次迭代，與業務方爭論或對抽象攻擊進行推理就可以了。 -善於接受的老闆。當您必須猜測哈希函數的256位輸入時，FPGA / ASIC的抵抗力是一個討論點。

建議

生成“密碼”使用硬件RNG或CSPRNG，並立即銷毀可用於恢復任何內部狀態的所有種子材料，從而恢復密碼。確保它們的長度為256位。如果您的系統不支持非字母數字或非ASCII密碼，則之後會生成256位，並根據需要將其編碼為base-64或base-26或​​二進制。 （這意味著您提交的實際密碼將超過32個字節，但這對熵的幫助不大。）

像加密密鑰一樣對待這些密碼-理想情況下，它們將存儲在硬件上令牌。為此，硬件密碼管理器非常有效。將SHA-256哈希存儲在您的系統中，並通過哈希和比較來驗證密碼。即使哈希匹配，您也應該拒絕所有與生成標準不匹配的嘗試密碼（例如，用戶選擇的256位<密碼），並且您不應該允許任何人設置不是來自密碼的密碼CSRNG。這應該是 記錄下來。更好的是，如果在生成的密碼末尾添加一些晦澀的校驗和字節，並在允許您設置密碼之前由平台進行驗證，則該字節會被平台驗證。這應該阻止除了最搞笑的無能的人之外的所有人都在您的平台上放置除加密密鑰以外的任何東西。

公共密鑰密碼學

您的用例是有點奇怪。大多數地方都保留密碼，因為設置PKI和與最終用戶打交道非常困難，尤其是在使用公鑰之類的地方。由於您似乎是唯一在系統中輸入密碼的人，因此將Ed25519或ECDSA公鑰存儲在系統上並在其中編寫實現挑戰響應協議的代碼（將這個256-比特價值-但請注意不要重複使用這些密鑰，因為有人可能會誘使您退出您的比特幣或刑事認罪。可以在此處與您的系統進行接口並維護私鑰的設備，可能會很好地實現公鑰加密，並且對自身進行身份驗證也不會有問題。就側通道攻擊而言（只要將其整個狀態都放在廣告牌或區塊鏈上），您的簽名驗證的“自己動手”實施可能是世界上最不安全的，只要它給出正確的答案，並且您會很好的，因為驗證算法根本無法訪問私鑰。

我同意Mike和Royce的回答，並且不認為需要重複他們所講的內容。但是，我想更直接地回答您的以下評論：

其他信息：我將是該系統上唯一存儲密碼的人，因此我可以1）確保不會輸入任何密碼使用兩次和2）確保密碼具有很高的熵。

這條信息既重要又不重要。原因如下：

密碼散列的情況

記住為什麼我們對密碼進行散列總是很重要的，這一切都沸騰了到密碼重用。密碼哈希如此重要的原因是，當您的系統遭到破壞並且密碼被盜時，不僅訪問受到破壞的網站，還訪問了用戶重複使用相同電子郵件/密碼的每個站點。 （眾所周知）這種組合經常發生。密碼散列是關於保護用戶免受自身攻擊。如果絕對每個人在每個站點上都使用強大而獨特的密碼，那麼密碼散列將不必要得多。它仍然具有一定的價值，因為在某些情況下，黑客可能會獲得對數據庫轉儲的只讀訪問權限，因此散列密碼可以為攻擊者提供一些保護，以防止攻擊者實際訪問您的系統。但是，如果人們使用強大而獨特的方法，到處都是密碼，那麼密碼散列將不再是當今的絕對必要，而將成為次要問題。

因此，如果您可以保證系統的每個用戶都只會使用強而唯一的密碼（即未在其他站點上使用過的密碼），那麼我認為，即使是否有更好的功能，即使是SHA2之類的簡單東西實際上也是完全合理的選擇。但是：不斷變化的業務需求

但是，我鼓勵您再次檢查您的假設（強唯一的密碼將是系統中唯一的密碼）。我已經看到業務需求在過去經常更改為依靠關鍵業務領域中的假設（這可能不是，顯然我不知道這是怎麼做的）。問題在於業務需求發生了變化。也許只有我一個人，但是根據我的經驗，那些本來是臨時的或僅限於幾個人的事情不可避免地變成了公司中每個人都使用的關鍵業務應用程序，突然之間，您的密碼機制很弱，無法保護關鍵業務基礎設施。這並非總是會發生，因為人們正在嘗試偷工減料，但是由於在接下來的12個月中，您忘記了自己並沒有使用強大的密碼哈希，或者您離開了，然後下一個傢伙沒有這麼做。不能研究它，或者您正面臨按時完成任務的壓力，而您忘記了or or or or ...

以我的經驗，企業最終會遇到安全漏洞，而不是因為安全性 ，但是因為他們不了解花時間（也就是花錢）在良好的安全做法上，並在不應有的地方偷工減料。當然，現在現在很好的密碼哈希方案並不重要，但是您真的可以保證將來不會改變嗎？如果您現在沒有時間進行適當的密碼哈希處理，是否可以保證當需求變化且突然變得很重要時，您將有時間這樣做嗎？

當然，在一天結束時，每家企業都需要賺錢，有時“讓我們暫時保持簡單，以便將其發佈出去”是一個完全合理的答案。不過請小心，因為頻繁做出此決定是公司最終如何使用充滿安全漏洞的系統。作為一家公司，您必須自己找到平衡。問題在於，當公司長期忽視安全性時，最終傷害最大的是客戶。

我必須將密碼存儲在一個系統中，該系統不提供推薦的用於散列密碼的任何算法（例如bcrypt，scrypt或PBKDF2）。在不使用任何算法之前（例如SHA-1或SHA-2系列）會更好嗎？

對您問題的嚴格答案是肯定的。原因是快速散列不會保護弱密碼，但它們會保護非常強的密碼，這絕對比純文本更好。

但是，如果您具有SHA-1或SHA-2，則有很少（如果有的話）不使用PBKDF2的藉口。是的，常見的建議是“不要自行加密”，但是如果您已經擁有SHA-1或SHA-2，這已經是PBKDF2的關鍵構建塊，並且用於密碼哈希寫入您的自己實現PBKDF2的情況總比沒有好。這是相關的RFC和部分：

• https://tools.ietf.org/html/rfc2898#section-5.2

當他們說“偽隨機函數”時，您應該使用一些HMAC變體（理想情況下為HMAC-SHA-512，但任何一個都可以）。您的庫可能已經具有HMAC實現，但是如果沒有，則再次使用密碼哈希可以實現自己的實現。

要回答您的問題：是的，請使用您有權使用的最佳算法。如果您有多個密碼，則可以將它們組合在一起（注意：密碼的串聯，例如sha1（password）+ md5sum（password），更容易被猜測，因為攻擊者可以選擇他們想要猜測的哈希，但是衝突要少得多

您可能會說，因為兩個密碼必須匹配。請為每個密碼使用不同的隨機鹽。

您說您的系統“不提供推薦的用於對密碼進行哈希處理的任何算法”。鼓勵您重新檢查該假設。

幾乎每種現代編程語言都具有安全哈希的實現。您不一定需要在預先創建的預先安裝的庫中實現它。如果您的程序是用C編寫的，那麼您應該能夠找到C中任何哈希的實現，作為一個獨立的函數，即使像Arduino這樣的微型處理器也可以使用bcrypt和PBKDF2，所涉及的額外工作量很小。甚至可以自己實現（但要非常小心，並要進行徹底的測試！）。

我毫不懷疑有例外，但是沒有很多。

是的，即使是低質量的哈希也比以純文本格式存儲密碼要好得多

如果我了解您進行了更新，則將由其他人進行身份驗證（與您和您的數據庫），您將僅使用密碼哈希數據庫進行重複密碼檢測嗎？確定密碼熵的要求將基於純文本，並且與存儲密碼散列無關，對嗎？

然後您可以將散列數據庫中僅存儲一小部分計算出的 sha2的 salt + plaintext 哈希（例如，僅存儲sha256返回的32字節的低8字節），足以檢測到帶有在現實生活中不會出現誤報，但仍不足以允許攻擊者使用Rainbow表來猜測原始密碼，以防您的數據庫被盜。

（免責聲明：如果您要進行身份驗證並且不僅要進行重複的密碼檢測，那麼比掉部分哈希顯然是個糟糕的主意！）

是，使用弱散列總比沒有好。

我認為您還應該考慮管理方式。如果您維護數據庫（但不允許更改結構，誰知道原因...），即使您是最整數的人，也不會看到純文本密碼，並且不會對該信息造成任何損害。就像諺語一樣：機會造就了小偷。

是的，使用簡單的哈希絕對比不使用哈希更好（儘管看到您顯然是如何實現該系統，但是我看不到是什麼阻礙了您正確執行操作）。

但是，鑑於您的“其他信息”編輯，一個人可能會大膽地說您甚至不需要鹽！但這並不意味著它是一個很好的設計，我不建議您這樣做，但是嚴格來講，如果您對保證很認真，那麼簡單的合理大小的安全哈希就足夠了。

為什麼要這樣做首先要對密碼存儲這麼大驚小怪？通常，密碼是低熵的，即使對哈希進行哈希運算，也很有可能會猜到密碼，而且哈希函數非常快，微不足道地可並行化，並且存在彩虹表可以提供廉價的快捷方式。因此，即使在散列後不可讀，也不一定意味著密碼是不可恢復的。
原則上，給定無限的時間，您可以在每個系統上恢復每個密碼（或至少可以使用的密碼）。這僅是由於散列函數的輸出數量有限的結果。因此，在準窮舉搜索中， some 輸入序列必須必須產生有效的輸出。
幸運的是，攻擊者沒有無限的時間，因此我們的工作是確保他們沒有時間。

現在...您...您說自己是唯一的用戶，並且可以保證

div>

em>表示密碼是隨機的且具有高熵。這排除了大多數關於猜測的擔憂。

給出一個“合理的”摘要大小，這意味著在彩虹表中找到散列的機會很小（零，或多或少），而通過蠻力找到散列的機會也差不多為零。不可能有人破壞SHA-256摘要暴力，更不用說SHA-512了。這個想法完全不符合我們對物理學原理的理解。
如果摘要足夠大，並且可以保證（如您所述）密碼是唯一的，隨機的，高熵的，那麼實際上您就是

現在當然，即使您不能提供該保證（或任何保證），通常系統也應該可以可靠地運行對於這個問題）。因此，這不是最好的設計。

是的，你應該沒事。 SHA1和2在存儲高熵密碼散列方面仍然非常強大，並且將提供足夠的保護以防止暴力破解。 SHA2比SHA1提供更好的保護。SHA2中的漏洞與這種情況無關，因為它們與在已知初始明文的情況下創建衝突有關。

為配合上述出色的回答，我想提供一個免費但相反的答案：

否。與完全不使用散列相比，使用弱散列更糟糕。

弱散列會給您帶來安全性的錯覺。

您和您的經理可能目前了解到哈希沒有提供真正的安全性，一線經理或開發人員可能認為哈希是安全的。這些人可能決定使用有問題的散列來存儲其他信息。

還有一種風險，就是管理層可能不能簡單地理解散列的開頭並不安全。面對投資安全性開發的決定時，他們可能會決定“當前系統足夠好”，因為該系統已經被哈希處理，哈希被認為是最佳實踐。