如何通過加密密碼避免先有雞還是先有蛋的情況？
我正在開發允許使用者上傳包含公司數據的文件，然後與在系統中具有特定角色的其他使用者列表共享這些文件的應用程序。
我想加密上傳的文件以保護靜態數據，同時允許不知道加密密碼的人共享文件。上傳的文件歸他們所屬的公司所有，而不是上傳文件的使用者。
當使用者在系統上創建帳戶時，會為使用者生成一個私鑰-公鑰對，私鑰儲存在數據庫中，並使用使用者明文密碼進行加密，在登錄過程中可以訪問該密碼。使用者密碼是加鹽的、拉伸的雜湊值，因此除了在登錄期間，應用程序不知道使用者密碼的明文。
當使用者成功登錄系統時，加密使用者的私鑰會從數據庫中提取、解密，並將解密後的私鑰儲存在 http 會話中。我假設雖然解密的私鑰在 RAM 中，但黑客很難從正在執行的程序的 RAM 中獲取私鑰，但並非不可能。
當使用者上傳文件時，會發生以下情況：
生成一個安全的隨機 UUID，並將其用作使用 AES 256 加密上傳文件的密碼
生成的 UUID 然後用使用者的公鑰加密並儲存在數據庫中。
系統確定可以訪問該文件的每個使用者的列表
- 對於可以訪問上傳文件的每個使用者，生成的 UUID 都使用該使用者的公鑰加密，並且加密的 UUID 儲存在數據庫中。
當一個文件在這裡被下載時，系統就是這樣做的。
- 它找到正在下載的文件的加密密碼
- 使用使用者的私鑰解密加密的密碼
- 使用文件密碼解密文件
- 將文件的明文返回給使用者
對我來說，這似乎比僅將文件儲存在未加密的伺服器上更安全，竊取數據副本的黑客將無法讀取文件，因為他們必須先弄清楚使用者的明文密碼他們可以獲得使用者的私鑰。
問題在於處理密碼休息，因為如果使用者忘記密碼並重置密碼，則使用者私鑰會使用使用者密碼加密，他們會失去他們的私鑰，從而訪問他們上傳的文件。由於我需要在應用程序中具有密碼休息功能，因此我陷入了先有雞還是先有蛋的場景，因為我如何安全地儲存使用者的私鑰，而最終結果卻不如什麼都不做？
有沒有辦法儲存使用使用者明文密碼加密的私鑰，並且在重置密碼時仍然有辦法保留對使用者數據的訪問權限？
我不是安全專家，更願意使用已知的解決方案/庫來解決這個問題，但我似乎找不到任何解決方案，所以我必須自己制定解決方案。
簡短的回答：您要解決的問題無法完全令人滿意地解決。
假設對手控制您的系統到能夠讀取包含密鑰的 RAM 的程度，您將無法定義安全系統。最接近真正實用的解決方案是引入可信的執行環境。HSM（不是標準的 PKCS#11 品種，可程式的）可以做到這一點，並且可以讓您免受系統其餘部分的損害（有一個需要修復的重要漏洞：您不應該“返回將文件的明文文本發送給使用者”，而是使用會話密鑰為該使用者加密它，所有這些都在受信任的執行環境中進行）。智能卡（同樣可程式，包括Java 卡) 理論上可行，但吞吐量方面的考慮很可能會阻止以這種方式進行大量數據加密。
請注意，無論如何，數據都無法避免任何可以訪問它的使用者的憑據洩露，這很可能是彌補伺服器漏洞的實際弱點。通過限制單個使用者可以獲得的數據量，或/和在使用者端使用智能卡，可以部分解決這個問題。
我認為這個問題在security.stackexchange.com上最合適。