如何支持通過排隊作業通過外部API安全創建用戶帳戶？

Question

所以這個問題正在研究安全和加密問題，這個問題可能還沒有被很多人遇到。答案可能是理論上的。讓我概述這種情況...

1. 網站前端是通過後端API驅動的。後端有一個端點處理通用註冊表，其中username和password。它使用SSL。
2. 後端API通過異步作業隊列處理註冊。隊列不會返回API服務器的響應。這是一個設置和忘記操作來排隊註冊。
3. 排隊的工作是由工人拿起。工作人員負責創建用戶帳戶。這些工作人員需要訪問明文用戶密碼，以便他們可以使用密碼觸發第三方API註冊呼叫。

因此，問題的真正癥結在於密碼同步到第三方API，而沒有透露它窺探的目光。隊列中存在的問題是不能直接從全局POST數據中直接訪問明文密碼，這意味着它需要以某種方式存儲在隊列中。

該隊列可以輕鬆存儲散列的密碼並直接將其複製到用戶表中。但是，此解決方案不允許將密碼與第三方API同步，因爲它已經被加密。我玩弄雙向加密，但我全心全意地擔心密碼容易被攻擊者解密。

任何人都可以想到一個安全的方式來處理密碼同步這種情況？

隊列是一個需求，並且假定這是任何有權訪問服務器的人都可讀的。密碼不一定非要同步;第三方API的密碼可以是原創的衍生產品，只要有一種安全的方法可以通過登錄用戶解密而不需要提供密碼。這主要是爲了模擬單點登錄與不支持SSO的第三方API。

Answer 1

有同步密碼的幾種方法：

1. 兩個AUTH商店使用可逆加密，使每個系統都可以提取實值發送給其他系統;
2. 兩者都使用完全相同的加密方式，因此您可以發送加密文本並因此可以被兩者理解。
3. 一個系統是用戶始終通過身份驗證的「主」，而「從」系統只是接收用戶已登錄的確認。這可以採用由主服務器創建的用於帳戶的機器生成密碼的形式創造奴隸。
4. 一個系統是所有其他系統爲進行帳戶驗證而調用的「主」。類似於使用LDAP或MyOpenID。

確實存在一些問題，您可以使用多主密碼同步進行操作，例如確保在用戶更改密碼時密碼更改已正確複製。

就你而言，這聽起來像用戶永遠不會直接與第三方API接口。如果這是準確的，請讓用戶根據您的系統進行身份驗證。在需要時生成第三方API密碼，將其存儲在其帳戶中，並根據需要自動將其登錄到其他系統中。您的主密碼可以存儲在不可逆的加密中;但是第三方必須使用可逆加密。隊列永遠不必擁有初始密碼，只需生成一個新密碼並將其與本地帳戶一起存儲即可。