是否有不同的方式來執行已經構建和審計的ASP.Net表單身份驗證？

像許多人一樣，我已經使用ASP.Net Forms身份驗證，因爲它已經寫入並編寫我們自己的安全代碼，所以我們被告知通常是一個壞主意。是否有不同的方式來執行已經構建和審計的ASP.Net表單身份驗證？

隨着與ASP.Net目前的問題，我想這可能是一個很好的時間來看看替代品。

從我的理解微軟傾向於東西存儲在客戶端，因爲它可以更容易，而無需數據庫訪問調用運行在服務器羣。

雖然我並不十分關心服務器農場，但我只想簡單地使用一個不透明的cookie來證明我對調用者不信任。

是否有一個體面的解決方案已被證明是可靠的？

更新：澄清我的問題。我正在談論我想要替換的表單身份驗證的身份驗證令牌部分。後端很容易替換，你可以很容易地實現接口來存儲你的用戶和角色。您也可以使用現有的庫，如http://www.memberprotect.net/，這裏已經提到過。

我想將流程的前端部分更改爲使用不爲客戶端提供任何槓桿的令牌。堅持現有的後端基礎設施將是有用的，但不是必需的。

來源

2010-09-20 Colin Newell

你可以看看http://www.raboof.com/Projects/Madam/ – 2010-09-20 11:38:35

一般而言，我不要認爲任何其他身份驗證都可以更好地「開箱即用」 - 只需讓它不知道，以便爲什麼你不知道他是否有安全漏洞。它在你的手中使asp.net表單認證系統更安全。 – Aristos 2010-09-20 11:52:26

我同意Aristos--這個特殊的安全缺陷是針對AES加密算法的，如果使用了默認的錯誤頁面，那麼首先就不會有網站易受攻擊。 – IrishChieftain 2010-09-20 12:45:10

我只是推薦看看InetSolution的MemberProtect產品，它是一個爲銀行和金融服務行業設計的安全考慮的組件，但廣泛適用於任何設計於ASP.NET或基於ASP.NET .NET平臺。它提供了對加密用戶信息和一系列身份驗證方法從簡單到非常先進的支持，並且各種方法和功能都被設計爲在開發人員認爲合適時使用，因此它不是一個罐裝解決方案，而是非常靈活一，根據具體情況，這可能會也可能不會是一件好事。這也是建立新的基於成員的網站和應用程序的基礎。

你可以找到更多關於它在http://www.memberprotect.net

我爲MemberProtect開發商和我在InetSolution :)

來源

2010-09-20 13:00:15

這看起來像一些有趣的後端的東西。它是如何處理前端和登錄的瀏覽器會話的跟蹤？它看起來像使用教程中的會話ID。 – 2010-09-20 14:11:26

嗯，你不是MemberProtect的開發者嗎？你不應該在你的答案中提到嗎？ – 2010-09-20 14:13:06

一般來說，除非你使用自己的會話標識/標記，否則ASP.NET網站一般都需要將ASP.NET會話標識傳遞給MemberProtect對象，但沒有任何說明你擁有*，它只是對ASP.NET有意義。因此，本教程讓ASP.NET處理該會話ID並將其傳入以用於後續回發等（您是對的，更新了'答案';） – 2010-09-20 14:15:11

工作，這不是一個值少的問題，但我不得不說，我認爲你的邏輯是可疑的。考慮替代認證解決方案並不是什麼壞主意，但是新發布的ASP.NET漏洞不應該促使你放棄目前的（大概可行的）解決方案。我也不能完全肯定此評論的意義是什麼：

從我的理解微軟傾向於東西存儲在客戶端，因爲它可以更容易，而無需數據庫訪問調用運行在服務器羣。

這個漏洞是什麼讓你認爲ASP.NET表單認證不僅僅是另一種解決方案？

MS諮詢的細節似乎表明幾乎任何其他身份驗證系統都可能同樣容易受到攻擊。例如，假設攻擊成功，任何使用web.config文件存儲設置的解決方案仍將向全世界開放其設置。

這裏真正的解決方案不是更改安全性，而是將已發佈的解決方法應用於問題。您可能只會切換身份驗證提供程序以發現您仍然處於易受攻擊的狀態，並且您的努力一無所獲。

關於令牌/會話：你必須東西推送到客戶端進行身份驗證工作（不管你叫它令牌或沒有），而且它不是導致當前安全問題這一進程的一部分：它是服務器響應某些調用的方式使得這個祕密容易受到攻擊。

來源

2010-09-20 16:04:18

據我瞭解，當前表單身份驗證令牌包含用戶名。假設加密可以被破解，僞造的令牌可以讓攻擊者以他們想要的任何用戶身份登錄。擁有一個不透明的令牌不會允許。 ASP.Net不是唯一受影響的框架。我努力尋找可行的替代方案來使用現有的表單身份驗證，但我不知道該怎麼做，假設我確實想要做一些不同的事情。我不是一名安全專業人員，我懷疑自己可以輕鬆推出自己的產品，但我想嘗試一些工作方式不同的產品。 – 2010-09-20 16:15:07

我不是100％確定的，但我認爲用戶名不會保留在票證中的客戶端。我在閱讀Reflector代碼時並不擅長，但請查看FormsAuthentication.MakeTicketIntoBinaryBlob以瞭解您的想法。 – Greg 2010-09-20 17:35:20

那麼什麼是FormsAuthenticationTicket.Name？（http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket.name.aspx） – 2010-09-20 18:24:00

如果你在web.config中有你的密鑰並且攻擊者得到它，那麼他們已經完成了。

如果情況並非如此（它們沒有從您的.config中獲得密鑰），那麼afaik填充oracle應該不允許它們簽署新的auth ticket。本文解釋了利用cbc模式進行加密的能力，並以那裏的一點垃圾爲結束。它應該足以使其成爲無效簽名。

至於他們用這個工具獲得密鑰的視頻，它是針對一個dotnetnuke安裝的。默認的dotnetnuke在web.config中有這些鍵。

實施解決方法，如果您不使用webresource.axd和scriptresource.axd禁用這些處理程序，並在ms發佈它時立即應用此修補程序，請將您的密鑰從您的網站級別web.config中關閉。

來源

2010-09-22 08:08:13 eglasius

您是說這次攻擊通過利用.axd處理程序之一從web.config中獲取密鑰而不是通過加密側通道來計算機器密鑰？ – 2010-09-22 08:28:30

是的。儘管如此（在這一步中使用加密方通道），但在填充oracle之後，它們會變得非常接近，所以它們可以解密所有用機器密鑰加密的所有內容。他們沒有能力準確地加密他們想要的東西，他們通過利用加密中的CBC使用以及填充oracle來實現。與此相關的問題是，它們最終會在加密消息中產生塊大小的垃圾。我沒有檢查過，但有人會希望那些2個處理程序使用帶符號的值/我想它不是那樣的 – eglasius 2010-09-22 08:45:39

這很有趣。我沒有意識到這是他們攻擊的一部分。儘管如此，我仍然感到驚訝。我得到了a）有一個工作，b）他們將修復當前的錯誤，但我仍然想看看是否有一個替代品沒有任何僞造。 – 2010-09-22 09:24:24

我一直在努力HttpModule，基本上是你在找什麼。當生成FormsAuthenticationCookie和FormsAuthenticatedTicket時，在將響應發送到客戶端之前（即，在處理登錄頁面/操作的回發期間），關於曲奇餅乾&票證的所有細節都存儲在服務器上。此外，來自故障單的UserData被移動到服務器（如果存在），並用故障單中其他屬性的SHA-512哈希替換，並替換爲作爲故障單的服務器端存儲區中的密鑰的GUID 。

驗證曲奇&門票將客戶端提供的所有內容（可選地包括他們的IP地址）與他們發佈時已知的所有屬性進行比較。如果有任何內容不匹配，則在FormsAuthenticationModule甚至啓動之前將它們從請求中移除。如果所有內容都匹配，則服務器的UserData會被鎖在FormsAuthTicket中，以防您擁有任何依賴它的模塊或代碼。這都是透明的。另外，它可以檢測可疑和公然惡意的請求，並在處理中插入一個隨機延遲。那裏也有一些明確的填充oracle解決方法。

該演示應用程序實際上允許您在服務器上創建/修改您的Cookie票據值&，服務器使用機器密鑰爲您的票證加密。通過這種方式，您可以向自己證明，除非您向服務器寫入確切的數據集（在正常情況下這應該是不可能的），否則無法創建繞過服務器驗證的故障單/ cookie。

斯科特

來源

2010-09-26 15:32:47 scottt732

是否有不同的方式來執行已經構建和審計的ASP.Net表單身份驗證？

回答

相關問題