使用主密碼加密和解密使用者憑據
我需要一種儲存第三方憑據的方法，並且我想避免以純文字形式儲存密碼。我不能使用雜湊，因為我需要能夠獲取原始密碼才能登錄第三方服務。
我的想法是使用我在服務啟動時輸入的主密碼，該密碼將用作加密和解密使用者第三方資訊的密鑰。我在這種方法中看到的唯一缺陷是我（或任何能夠以某種方式獲得主密碼的人）將有權訪問第三方服務的使用者數據。
或者，使用者可以在訪問我的服務時輸入他們的第三方登錄憑據，我的服務可以訪問第三方站點。但是，該服務應該 24/7 全天候執行，這種方法將要求他們每 8 小時重新輸入一次登錄憑據，而不僅僅是一次。
這些方法中的任何一種是否存在任何重大缺陷，或者是否有更好的方法來解決問題？
確實，任何學習萬能鑰匙的人都有巨大的影響力。關鍵管理最佳實踐值得研究。我強烈建議您考慮使用由硬體安全模組 (HSM) 支持的密鑰管理服務 (KMS)。
基於雲的服務中有一些價格實惠的產品，例如亞馬遜的密鑰管理服務，允許您從他們的服務中檢索密鑰並在本地使用它。或者，您可以使用基於雲的 KMS 進行加密，方法是將明文數據傳輸到服務，並接收由密文和密鑰引用組成的回复（解密包括將密文連同密鑰引用一起發送回同一服務） .
當然，使用基於雲的服務需要您對服務進行身份驗證，這意味著在某些時候將憑據傳輸給它。您可以通過將 KMS 配置為接受來自一組有限 IP 地址的通信來使此過程更加安全。此外，您的 KMS 身份驗證憑據可以加密並以密文形式靜態儲存。未加密的 KMS 憑據可以在 RAM 中存在您確定的持續時間（您的原始文章說每 8 小時一次，這似乎足夠了）。解密 KMS 憑據的方法可能是您提供一個密碼，該密碼將轉換為可以執行解密的密鑰。然後讓 KMS 完成其餘的加密工作。
您的要求中是否存在阻止您使用 OAuth 的內容？您的問題聽起來與創建 OAuth 來解決的問題非常相似。
OAuth 2.0 授權框架使第三方應用程序能夠獲得對 HTTP 服務的有限訪問權限。
一般來說，共享密碼是一個非常糟糕的主意。您的使用者基本上完全信任您。您可以更改他們帳戶的密碼和聯繫電子郵件並將其鎖定。OAuth 更像是一把代客鑰匙，可以讓別人為你開車，但不能打開備份箱。