訪問多個伺服器後，額外使用“秘密共享”來儲存密碼會增強安全性嗎？
我目前正在學習秘密共享，我開始想知道為什麼可以訪問整個伺服器網路的大公司（例如——例如——Google、Facebook 等）不使用“秘密共享”來儲存密碼，除了散列和加鹽。
我知道這些公司傾向於使用許多不同的階段來儲存密碼（散列、加鹽和各種組合的加密），但是通過使用“秘密共享”並將生成的共享儲存在獨立的伺服器上，不是更安全嗎？
我看到的優勢是，攻擊者必須至少有權訪問門檻值數量的伺服器才能檢索散列密碼。還是我錯過了什麼？
這樣的計劃將如何運作？你必須：
- 將密碼數據庫（或者是單獨的條目？）拆分為多個共享；
- 將這些共享分佈在許多伺服器上；
- 有一個系統讓這些伺服器對等以重建密碼條目；
- 支持實時添加和修改使用者密碼條目。當使用者更改密碼時，這是一個分佈式事務，必須以原子方式成功或失敗（否則使用者之後無法登錄！）。
- 確保重構的密碼條目永遠不會寫入磁碟，或者至少不會以明文形式寫入。
- 確保多個數據庫共享永遠不會聚合到相同的備份中。
- 其他問題我可能沒有考慮。
這聽起來像是一個非常複雜的解決方案。許多活動元件和許多可能出錯的事情。不僅在安全性方面，而且在基本功能方面。
我們應該從所有這些複雜性中獲得什麼？這個想法是，如果攻擊者竊取一個共享（或少於門檻值），他們就不能對數據庫進行暴力攻擊。但我認為，這將是一個由同質、合作、自動化的同行組成的系統，這一事實會使收益面臨風險：
- 如果攻擊者發現允許他們從一台伺服器竊取密碼共享的軟體漏洞，那麼由於系統的同質性，相同的漏洞很可能被用於從其他伺服器竊取共享。
- 如果攻擊者可以冒充一個對等點，他們難道不能只向真正的對等點詢問重建雜湊所需的密碼共享嗎？畢竟，同行之間可以自由合作以交出自己的股份。
也許有一種方法可以通過為每個密碼條目指定一個“擁有”它的對等方來減輕後者，這樣對等方將永遠不會與任何其他人共享其份額。但是現在這個想法變得相當複雜，當你提出可用性要求時更是如此——當一個對等點出現故障時，其條目由該對等點“擁有”的使用者可以再登錄嗎？如果每個條目都有一個“主”所有者和一個“備用”在主失敗時接管，我們是否可以欺騙備用認為主失敗，這是否允許我們繞過這些措施？
相比之下，秘密共享的許多應用涉及以下人員：
- 是試圖阻止至少其他一些人了解秘密的對手。
- 將他們的份額儲存在其他人無法控制的異構環境中。
- 將他們的共享儲存在需要非常措施來檢索它們的離線環境中。
- 一起在精心安排的儀式中手動重建秘密，以防止任何參與者或其他方了解秘密。
參見，例如：
- DNSSEC 根簽署儀式
- HashiCorp 的 Vault 工具的初始化過程有一個 PGP 集成，旨在用接收者的公鑰加密新生成的主密鑰在記憶體中的份額，這樣任何人都不會看到主密鑰份額的明文。
Dropbox 最近寫了一篇博文，詳細介紹了他們的密碼儲存策略。他們闡明了一種使用全域 AES 密鑰加密每個散列的策略，這看起來比您建議的要簡單得多，並且在實踐中可以說同樣安全。我會讓引號不言自明：
最後，生成的 bcrypt 雜湊使用 AES256 使用我們稱為辣椒的密鑰（所有雜湊通用）進行加密。胡椒是深度防禦措施。胡椒值以一種難以被攻擊者發現的方式單獨儲存（即不在數據庫表中）。因此，如果只有密碼儲存受到破壞，密碼雜湊就會被加密，並且對攻擊者沒有用處。
$$ … $$ 為什麼使用全域胡椒而不是散列進行加密？
回想一下，全域辣椒是一種縱深防禦措施，我們將其分開儲存。但是單獨儲存它也意味著我們必須包括辣椒（而不是密碼雜湊）被洩露的可能性。如果我們使用全域辣椒進行散列，我們不能輕易地旋轉它。相反，使用它進行加密為我們提供了類似的安全性，但增加了旋轉的能力。該加密函式的輸入是隨機的，但我們還包括一個隨機初始化向量 (IV)。
展望未來，我們正在考慮將全域胡椒儲存在硬體安全模組 (HSM) 中。在我們的規模下，這是一項相當複雜的工作，但會大大降低辣椒妥協的可能性。