2010-08-19 30 views
3

我剛剛讀到一篇文章說7個字符的密碼不再安全。但是,如果服務器在每次登錄嘗試後都增加重試登錄嘗試的時間,那麼強力攻擊就毫無用處。你如何在asp.net中創建這樣的邏輯?不知何故,我猜服務器端代碼需要記住試圖登錄的IP地址,並應增加每次新嘗試的響應時間?暴力破解在asp.net登錄失敗保護

+1

7個字符?您至少需要9個字符,包括符號。 – erickson 2010-08-19 19:40:57

回答

4

IP地址確實不是一種識別用戶的安全方法。您可以嘗試將上次登錄嘗試的時間存儲在cookie中,但如果瀏覽器不接受它們,則它的使用將受到限制。會話變量也需要cookie,所以它們沒有了。

有些網站(雅虎想到)在第三次嘗試之後開始顯示驗證碼錶單。除了您的登錄信息外,您還必須正確回答驗證碼。

另一種選擇是在X失敗嘗試(可以在數據庫中跟蹤)後禁用帳戶,但我個人不喜歡這樣做,因爲它往往會迫使我在某人忘記密碼時強制重設密碼。

+0

嗯,我該怎麼把這個。想象一下,有人試圖使用登錄頁面登錄,但一些代碼嘗試每次登錄。然後我猜,在服務器端,您需要記住下次需要驗證碼時。很難解釋我的問題。 – 2010-08-19 19:30:34

+0

如果您擔心蠻力攻擊,您可以每次都顯示驗證碼。但是,在給定窗口中嘗試過多次後鎖定帳戶對於大多數網站來說是完全足夠的。如果您需要比普通網站更高的安全性,那麼比阻止對密碼的暴力攻擊還有很多。看看OWASP--還有很多其他類型的攻擊,比如CSRF和XSS,這些攻擊對每個Web應用程序都是嚴重的威脅。 – saille 2010-08-19 22:38:00

+0

當您的帳戶被鎖定時,您不一定需要聯繫某人。如何通過電子郵件向您發送鏈接以解鎖您的帳戶的系統? – saille 2010-08-19 22:56:20

2

許多蠻力攻擊都是離線發生的。這就是爲什麼失敗嘗試鎖定無法替代需要複雜的密碼,使用適當的「鹽」和加強鍵。

+0

也許一個愚蠢的問題:但是應該如何破解我的ASP.NET應用程序離線? 答案是,ASP.NET身份驗證在嘗試失敗後會查看您的帳戶。也可能是一個解決方案,不是嗎?假設沒有脫機破解:-) – Remy 2010-08-19 20:13:50

+3

假設一位員工拿着磁帶和用戶數據庫的備份。 – erickson 2010-08-19 20:30:04

2

ASP.NET有一個內置機制來防止對登錄密碼進行暴力攻擊。 請參閱maxInvalidPasswordAttempts Membership property

恕我直言7字符密碼完全適用於大多數Web應用程序(我的銀行允許7個字符密碼)提供安全最佳實踐,如安全地哈希密碼和阻止暴力攻擊。

一旦你超過了7或8個字符的密碼,你確實在說「我的應用程序需要超級安全」,在這種情況下,你應該考慮單獨的客戶端SSL證書。在密碼中需要更多字符的回報遞減。有多少用戶可以記住複雜的8或9個字符的密碼?他們最終寫下來。就我個人而言,任何需要我創建一些超複雜密碼的網站都會被拒絕。

ASP.NET成員資格會爲您執行大部分圍繞安全性的努力工作,只要它的設置正確即可。

然而,有一些事情ASP.NET成員不能爲你做什麼,如:

  • 確保使用HTTPS
  • 防止CSRF及類似襲擊
  • 確保所有的web請求路由到ASP.NET防止靜態內容被IIS提供並繞過ASP.NET身份驗證
  • 檢查用戶是否爲人(CAPTCHA)

更多關於安全的最佳做法我想看看OWASP

1

似乎有你可能要擔心至少三次攻擊:

  • 在一個特定的用戶有針對性的攻擊。對於攻擊者而言,您想讓的登錄更困難,但不會太困難。驗證碼已足夠(但如果用戶未在登錄頁面上顯示,則不要再次輸入密碼)。
  • 對許多用戶的大規模攻擊。鎖定個人用戶有點毫無意義,因爲攻擊者可以嘗試(說)3個密碼,然後轉到其他帳戶。每IP的CAPTCHA可能就足夠了,但您可能還想對每個IP進行速率限制(或者對於列入白名單的代理的X-Forwarded-For)。這取決於攻擊者的僵屍網絡的大小;一個足夠大的僵屍網絡可以在多個僵屍網絡/站點上分發攻擊,以便每個站點從每個IP獲得較低的速率。
  • 密碼數據庫的脫機攻擊。在這種情況下,即使使用一個好的散列,你也需要至少大約50比特的熵(NTLM使用MD4的單個呼叫,這個呼叫是而不是,這是一個很好的散列),你無法獲得相對正常的8個字符的密碼(8日只有52.4)。

您可以將每次嘗試IP存儲到樹中,在樹中將樹的密集部分分組在一起。然後將它分開(每隔10分鐘構建一棵新樹,將老樹保持10分鐘左右)。這可能是錯誤的假設,即相鄰的IP可能會表現出類似的行爲,但是會優雅地將其降級​​爲(比如說)/ 24。

如果您感覺特別慷慨,您可以在登錄時存儲單獨的cookie,並且在註銷時不會清除,並將副本保存到數據庫中(128位隨機值應該足夠好)。在登錄嘗試中,如果瀏覽器顯示正確的cookie(例如,允許對cookie進行3次嘗試而不計算每IP或每個用戶的失敗率),則對瀏覽器「更好」。這意味着即使用戶帳號被強制使用,用於訪問帳號的最後一臺機器也不會顯示驗證碼。

一般來說,談論密碼熵比密碼長度和「字符類型」更有用—我敢肯定,幾乎每個人都只是製作第一個字母大寫,並在結尾處貼一個1。我還沒有看到任何「人性化」的密碼生成器,它們也聲明密碼熵。