我不確定你來自哪裡。首先，他的觀點與 NIST所定義的公認的行業最佳實踐相反。此外，您的經理是錯誤的危險人。用戶越多，為多個用戶獲得相同密碼的可能性就越大。另外，以下公司也這樣做，我非常相信他們的全球用戶群比您的網站還大：

• Facebook
• Gmail
• Linkedin

另外，您可以從商業角度解釋的另一個原因是，在負面宣傳中，圖像/品牌受損的風險強>。舉一個例子，Adobe使用了錯誤的密碼存儲實現，這導致了與您現在同樣的問題：散列（如果使用Adobe而不是散列，則使用散列進行加密）產生的值對於多個密碼是相同的用戶是否使用了相同的密碼（在這種情況下，是因為在執行對稱加密時未使用IV，但這無關緊要）。畢竟，互聯網公司應該堅持像密碼哈希這樣簡單的方法，對嗎？這種負面宣傳所造成的財務成本可能是巨大的。

此外，根據您所居住的國家和所採用的法律，如今，如果確定管理層在保護數據方面存在疏忽大意，則可以對他們負責個人責任隱私（例如，如果使用破解的密碼來獲取用戶的個人數據）。同樣，根據存儲的信息類型，金融，醫療，信用卡，可能會適用不同的規則，這也可能導致其他類型的罰款。

這可能與密碼哈希不直接相關，但是如果您的經理做出進一步的錯誤決定，可能會派上用場。因此，請確保在電子郵件副本中清楚地說明問題所在，並保存經理的答复。 （只是為了掩蓋自己的屁股）

您沒有使用鹽的事實也可能意味著您沒有使用正確的哈希算法，因為這些算法通常會負責生成鹽並執行大量迭代。三種公認的算法是：

• PBKDF2
• bcrypt
• scrypt

salt的主要目的是通過將單個計算出的哈希值與所有存儲的哈希值進行比較來防止攻擊者節省工作。此問題與密碼是否唯一無關。

不加鹽，攻擊者可以簡單瀏覽其可能的密碼列表，計算出每個密碼的哈希值，然後檢查結果是否與以下任何一項匹配存儲的哈希。因此，每個猜測只需要進行一次計算。

使用鹽，攻擊者必須遍歷每個用戶的列表，因為他無法重複使用結果。這迫使他對每個用戶和進行一次計算。

但是，正如盧卡斯已經說過的那樣，真正的問題是您沒有使用適當的算法。鹽只是密碼哈希的一個方面。

“最佳”抗辯取決於您要達到的目標。

如果您只是想做到科學正確，那麼只要說鹽不是，而且從來沒有，就可以了。一種應對兩個不同用戶選擇相同密碼的方法。特別是因為碰巧選擇相同密碼的兩個用戶一開始就沒有問題，所以沒有什麼可修復的。鹽用於避免並行攻擊，包括使用預先計算的表。缺乏鹽分是 LinkedIn的主要罪過。

現在正確對只有準備好承認自己可能是錯誤的或至少是不完全了解的人有影響。您從經理那裡得到的報價往往表明他既不完全擅長該主題，又確信他完全掌握了該主題。如果您想說服該經理他錯了，那就加油。人們最害怕的是甚至隱含地承認他們說了些愚蠢的話。

如果您希望組織實際切換到正確的密碼哈希（請閱讀 this），那麼您可能所能做的就是說服其他人經理剛剛說的話簡直是胡言亂語，甚至沒有足夠的道理可以說是錯誤的。如果管理者變得孤立，那麼他可能對正確的密碼散列的實現視而不見，當然也從來沒有承認它。再有，科學上正確的論據不一定是最有效的論據。在北美地區（尤其是新英格蘭等受英國影響的地區），商務會議旨在避免衝突和稀釋責任，因此您應該散佈一些恐懼，不確定性和疑問：請務必指出您的競爭對手正在轉向鹽醃哈希，如果不這樣做，則可能會失去一些市場份額的風險。在南歐，開會是建立等級制度的儀式性戰鬥，所以大聲喊叫，咆哮，威脅和使用諷刺來贏得群眾的支持：您不會因正確而獲勝，而不會因自信而獲勝。

一般而言，最有效的爭論類型之一是對權威的吸引力。在 NIST特殊出版物SP800-118（當前正在草稿中）中，可以看到：

哈希算法弱點的另一個示例是某些算法不使用鹽化。

“無鹽” =“弱點”。 NIST這樣說。這位經理誰認為他比NIST聰明？

從某種意義上說，如果您正在爭論鹽問題，那麼您已經錯過了船。 關於密碼存儲安全性的最新技術已經遠遠超出了“加鹽還是不加鹽”的問題，並且此後一直用於計數迭代。

但是讓我們從基礎開始。這是我不久前寫的一個答案，它非常受歡迎。它解釋了鹽為什麼更好的原因，很多人說它使其他解釋變得平淡無奇。它或多或少是您的要求-如果您認為這樣做會有所幫助，請告訴老闆：

為什麼加鹽散列更安全？

但是重要的一點是最後一個。也就是說，不再將存儲鹽分的SHA1散列並稱其為好不再是負責任的。計算能力已經達到了每秒不再有數十億個哈希值的地步，這使您能夠以比解釋您的操作更快的速度穿透暴力攻擊的整個32位空間。現在，重點是迫使攻擊者無數次地解決問題，只為猜測一次。這就是 PBKDF2 （穿著其NIST發行的西裝和領帶）以及 scrypt 和朋友（看上去sc而有力）出現的地方。

您選擇的哪種算法並不是真正的關鍵。它們都以不同的方式，以不同的重點來解決大致相同的問題。但是您必須使用 something （某種算法），該算法使得即使是單個密碼也難以暴力破解。原因很簡單：這是行業標準，可測量且可證明更安全，並且使用它沒有大量成本。將這些因素放在一起，很快就會發現，如果您不這樣做，那麼在發生漏洞的情況下您會被視為疏忽大意。

最好的說法是提取最常用的密碼列表，並顯示大約1％的用戶會選擇“ 123456”。第二好的方法是對大型網站進行密碼洩漏分析，並表明只有大約一半的用戶可以設法提供唯一的密碼。

您應該提出兩點：

• 使用鹽會減少包含哈希密碼的被盜文件的值。無論系統用戶使用哪種語言，都是如此，因為擁有針對您的哈希算法的彩虹表的攻擊者可以使用它來反轉哈希密碼，而與選擇該密碼的人的母語無關。密碼。

• 使用鹽幾乎是免費的。排除它幾乎不會給您帶來任何好處，即使在您經理的當前估計中，排除它也不可能造成嚴重的安全問題。因此，請使用它。

您的經理可能會對第一點提出異議，但我希望不會：“我們正在使用我們自己的自定義哈希算法，因此沒有存在彩虹桌的危險”。在這種情況下，您還必須 使用標準的密碼哈希算法。

我還發現：

[用戶]都具有不同的本地語言

，對於系統而言，這是一個奇怪的假設。如果您依賴假設進行安全性分析，則一旦破壞該假設，系統就會變得不安全（或至少不評估安全性）。因此，出於安全性的考慮，您需要強制該產品的兩個用戶都不能使用相同的母語。到底為什麼有人會想以這種方式限制他們的系統，特別是與使用鹽相比，執行此限制會變得更容易？

但是，在這種情況下，這種假設甚至無法導致可以得出結論，您的經理認為鹽是不必要的（出於上述原因）。因此，面對假設無濟於事的事實，是否可以維持假設的問題就無關緊要了！

最後，僅供參考，我的第一點與您的經理的分析相矛盾是有特定原因的：

不太可能使用相同的密碼

是對salt解決的弱點的有缺陷的分析。對於攻擊者而言，系統的兩個用戶是否具有相同的密碼無關緊要，除非攻擊者恰好是這兩個用戶之一，並且因此知道他們共享的密碼。鹽不僅可以防禦這種攻擊，還可以防禦彩虹表攻擊。因此，即使在您的系統上不可能發生您的用戶進行這種罕見的相同密碼攻擊，您仍然需要使用鹽。

我想這更多是人員問題，而不是技術問題。因此，您需要使用軟技能而不是技術說明來做出回應。如果您的經理對技術說明的反應是積極的，請選擇以前的答案之一。

如果您想從事軟技能方面的工作，可以嘗試一些嘗試：

• 最重要的要記住：老闆就是老闆。不要生他的氣，否則你會倒霉的。
• 盡量不要問他無法回答的問題。而是以簡單的句子形式提出間接問題。
• 嘗試理解他的立場和論點。
• 應用釋義。
• 從不笑。
• 切勿輕描淡寫。
• 閱讀Dale Carnegie的書“如何贏得朋友並影響人”。

示例對話框可能如下所示（請注意，我我不是母語為英語的人）：

老闆：“我們不需要鹽。”
您：“我們不需要額外的保護。”
老闆：“是的，我們的用戶不會重複使用相同的密碼。”
您：“強密碼已經安全。”
老闆：“是的。”
您：“好的，我知道。我們的用戶確保密碼安全，我們生活在無鹽狀態。”
老闆：“是的，也許不是所有用戶……”
您：微笑

還是這樣：

老闆：“我們不需要鹽。”
您：“使用鹽的好處不值得付出努力。”
老闆：“是的。”
您：“因此，我們從任務列表中刪除了鹽，然後繼續其餘的工作。”
老闆：“對，我們已經落後於時間表了。”
您：“如果我們能以另一種方式滿足時間表，我們可以實施鹽分嗎？”
老闆：“不，我不明白那個鹽的概念。”
您：“這些密碼知識總是很難理解的。”
老闆：“即使我讀了一篇文章，也沒有得到任何線索。”
您：“這讓您覺得這很費力。”
老闆：“是的，我們會損失兩天左右。”
您：“在框架的幫助下，我可以在2個小時內完成。”
老闆：“真的嗎？”
您：微笑

請注意，根本沒有問號。老闆從來沒有承受回答他可能不知道答案的問題的壓力。

不幸的是，如果您以前從未嘗試過，很難應用這種技術。

如果採用這種方法也不能很好地工作，還有一個選擇：

只需實現它即可。不應做太多的工作，您的老闆可能不會注意到它，除非他正在執行代碼檢查或查看數據庫表。

只需將一些哈希（也許是他自己的密碼）丟入Google。很可能它將返回密碼。他的弱哈希就像根本沒有哈希。

https://www.google.de/search?q=a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

如果沒有說服他尋找新工作...