使用Cookie將加密的第三方密碼安全存儲在數據庫中

Question

顯然，存儲任何種類的第三方憑據都是一個主要風險，我想盡可能避免這種情況。 但是，我對如何相對安全有一個想法，我希望對此策略發表一些意見：

1. MySite允許用戶使用用戶名和密碼（或Facebook，無論如何）進行注冊！

2. 如果該用戶還使用用戶名和密碼在AllTheData.com網站（此處稱為ATD）上注冊，則他們可以通過HTTPS給我這些用戶名和密碼。

3. MySite接收ATD的第三方憑據，並做兩件事：創建一個新的加密密鑰，將其存儲在用戶的cookie中，並使用該密鑰對用戶名和密碼進行加密，並將這些加密的值存儲在數據庫中。

AllTheData.com的數據庫可能如下所示：

| User               | Password              
| JohnDoe@gmail.com  | p4ssw0rd_hashed

MySite的數據庫現在看起來像這樣：

| User               | Password               | ATD_username         |ATD_pass
| JohnDoe@gmail.com  | another_p4ssw0rd_hashed| ct5lHMGymedITfElVA...|BHJCS38DkG7Zg0...

用戶的瀏覽器具有一個帶有密鑰的cookie：

MySite_key: E3iKZxk2ZDD4EUb*fH$X6Mz5BO^iQeOM&V$lB0WAk4&WAB#A4QB8Yn7

現在，當我需要訪問服務時，我從數據庫中提取了加密的值，並從他們的請求中提取了cookie，然后就可以訪問服務器了！ 當然，如果他們的cookie過期了，或者他們已經清除了它們或更換了計算機或其他任何東西，那么我不得不再次問：（但是，如果這意味着我不必將憑據存儲在純文本中，那是值得的！

我在這里做錯什么了嗎？ 這個計划有什么明顯的問題嗎？

謝謝！

Answer 1

我同意CBroe的評論。 與第三者進行交互的方法要比強迫您的用戶放棄其寶貴的憑據要好得多。 我建議研究類似OAuth的東西。 它為您的用戶提供了許多很棒的功能：

• 他們只向ATD出示其ATD憑證
• ATD可以讓他們控制系統可以為他們執行的數據或操作。 用戶可以隨時撤消系統訪問權限。
• 您想要與之集成的大多數第三方都是OAuth提供者

---

既然您已經說過不能使用OAuth，那么在使用您提出的解決方案之前，我會嘗試另一種攻擊計划。 您已經承認您的解決方案非常短暫。 一旦用戶清除了他們的cookie，您就要求他們再次登錄。 如果您要調用的服務在登錄時創建了會話，則只需將用戶憑據轉發給第三方，然后臨時緩存該服務通常返回給用戶的任何令牌或會話ID（我認為沒有理由將其存儲在數據庫中）。 一旦用戶注銷系統，您就可以刪除該令牌。 這樣可以避免直接存儲其憑據。 這不是很大的進步，但這是我首先要追求的。

如果將此與cookie加密想法結合起來，我認為您將獲得很好的分離。 您已經在服務器上緩存了加密的身份驗證令牌，但是只有將加密密鑰存儲為cookie的用戶才能訪問它。 就像您說的那樣，如果您受到感染，這將阻止您的服務器授予第三方訪問權限。 如果您的客戶受到損害，您實際上並沒有得到任何保護，但是我認為這是不可避免的。

如果系統為每個請求都要求憑據，那么我真的看不到更好的方法。 您已完成作業，但沒有更好的解決方案。

Answer 2

雖然不是允許訪問第三方系統的最佳方法，但這也不錯。

確保MySite_key是由加密安全算法生成的，以便攻擊者無法預測到它，並盡最大可能保護此cookie。 如果您的網站上存在任何違規行為，則Cookie對於攻擊者而言將變得非常有價值。 當然，是否有價值取決於用戶在ATD中可以訪問哪些數據。

這意味着在您的站點上實施SSL / TLS，在cookie上實施Secure Flag和HTTP Only Flag並設置HSTS策略 。 還要確保您的站點沒有任何會話固定漏洞-如果存在，則攻擊者可能能夠為另一個用戶的帳戶設置自己的加密密鑰。

確保加密算法也足夠安全，可以滿足您的需求，例如AES-128 。

還要確保您與ATD的通信僅通過SSL / TLS。 同樣，使用被認為是安全的並且不易受到任何降級攻擊（例如FREAK ）攻擊的協議和密碼套件版本。