此實施SSO的潛在安全問題是什麼？

我目前正在研究跨域SSO實現，並且我可能無法使用第三方SSO提供程序。此實施SSO的潛在安全問題是什麼？

我在線發現了一個包含系列重定向和加密查詢字符串參數的自定義實現。

MrUser登錄到http://www.foo.com
MrUser點擊一個鏈接到http://www.bar.com/page.aspx
MrUser上bar.com沒有通過認證，但bar.com有重定向到http://www.foo.com/sso.aspx
sso.aspx頁面檢查cookie集合中的有效ASP.NET身份驗證Cookie。如果存在，sso.aspx將重定向到http://www.bar.com/page.aspx&ssoauth=[encryptedkey]（其中[encryptedkey]是foo.com和bar.com已同意的MrUser的加密標識）。如果沒有有效的ASP.NET身份驗證cookie，那麼它只是重定向而沒有ssoauth參數。
Bar.com執行檢查以避免無限重定向循環，然後解密ssoauth值。如果沒有ssoauth參數，那麼MrUser會被重定向到登錄頁面，否則Bar.com將使用解密後的id在將其發送到page.aspx之前對MrUser進行身份驗證。

這種方法的潛在安全問題（或其他類型的問題）是什麼？

編輯：爲響應答案援引加密ID是一樣的，每次和一個攻擊者可以使用它來訪問 - 如果有什麼bar.com檢查引用，以便它只接受來自foo.com的ssoauth參數？

我建議你看看基於聲明的安全性和代號「Velocity」 – 2010-02-05 01:12:14

引用者非常容易被欺騙。確保SSO加密密鑰是真實的唯一方法是讓生成服務器加密執行請求的系統的佔用空間。足跡是非常困難的，因爲足跡中沒有太多的東西不能被複制/欺騙。 – 2010-02-05 01:21:52

第一個問題是，任何加密/解密方案都可以清楚地看到。您應該更好地實施一些更加符合PKI加密/解密平臺的行，這些平臺的加密密鑰是公開的，但解密密鑰是私有的。加密需要適當複雜以增加「破解時間」，並且需要資源來執行密鑰的加密/解密。

事實上，你有一個非共同的域將創建需要提供加密的片頭（post或get），並傳遞它明文。雖然查詢字符串信息在請求的生命週期內保持安全（編輯：假設爲SSL），但瀏覽器歷史記錄並不安全（使其可供常用計算機訪問）。

最嚴重的安全問題是「破解一個/破解所有」的概念。如果其中一臺服務器受到攻擊並且其加密/解密算法，鹽等暴露出來，那麼攻擊者可以通過隨意和按需生成有效的加密SSO密鑰來危害所有系統。

這些問題都不是非常悲慘的。我不會在銀行或醫療機構執行此計劃，但對於像SO或Twitter這樣的低風險網站，這是完全可以接受的。這將全部歸結爲管理資源，風險和收益。

2010-02-05 01:08:14

你能評論我上面的修改嗎？ – 2010-02-05 01:19:06

任何人都可以使用encryptedKey作爲MrUser獲得訪問權限。需要一個簽名或消息認證服務，而不是加密。經過身份驗證的消息應包含具有用戶標識符的隨機數以防止重播。

像這樣的協議很難設計。即使是多年來廣泛使用和審查的TLS也存在安全漏洞。不要嘗試使用未經驗證的身份驗證機制。

2010-02-05 01:09:20 erickson

你能評論我上面的修改嗎？ – 2010-02-05 01:18:38

引用標題可以很容易僞造。這根本不是安全措施。 – erickson 2010-02-05 17:02:18

潛在的問題是，如果ssoauth加密密鑰只是用戶的加密ID。這樣的設置將導致每次提供相同的密鑰，因此可以由原始用戶重用，或者由第三方更壞。

避免這種情況的一種方法是保持foo.com和bar.com服務器的時鐘相對同步，併發出包含日期/時間（模5分鐘）的密鑰。

人們經常試圖使用Web客戶端的IP地址作爲此加密的一個要素，但這是一個壞主意，因爲一些代理和網關在其池中使用不同的公共IP來訪問不同的域/服務器。

的另一種方式每次以允許不同的密碼是有bar.com的重定向到

http://www.foo.com/sso.aspx

包括參數如

http://www.foo.com/sso.aspx?ParamForKey=some_random_number

和使用ParamForKey作爲加密部分過程

2010-02-05 01:10:20 mjv

如果'some_random_number'實際上是隨機的，那麼你仍然容易受到重播攻擊。 – 2010-02-05 01:24:17

@Anon。你是對的！這種參數應該是部分隨機的，但也包括一些基於時間的排序驗證（這會帶來同步時鐘的需求......） – mjv 2010-02-05 01:33:10

有幾個問題： 1）加密的令牌有效多久？它應該只對幾個秒有效。如果所有服務器都在ntp上，很容易。過期還可以保護用戶，以防他們擁有包含加密令牌的鏈接。驗證隨機數是很困難的，如果你有很多bar.com服務器 - 你可以說過了幾秒鐘應該減少重播。

2）SSO跨域的問題是單點標誌關閉。如果用戶簽署foo.com會怎麼樣？ bar.com上的會話必須失效。你可以將XSRF bar.com註銷爲黑客:)。您應該每隔15分鐘有bar.com beacon foo.com，以查看用戶是否仍然登錄。

3）如果用戶沒有簽名bar.com並且它是多用戶計算機和另一個用戶標誌到foo.com上？如果用戶標識不匹配先前用戶的數據，則必須確保不顯示。

4）正如別人提到的，你可能需要在userid上簽名或者使用HMAC而不是加密。如果你加密，請記住保護密文的完整性。您不希望用戶A在密文中翻轉位以查看他們是否可以訪問bar.com上的用戶B的數據。

我會通過https重定向。

最後，正如大家所說，推薦人可以被欺騙。不要相信他們。

2010-02-12 21:22:04 mar

回答