限制（並記錄）登錄嘗試的最佳方式

Question

很顯然，限制登錄嘗試的某種機制是安全性必備條件。雖然我喜歡兩次嘗試之間呈指數級增長時間的概念，但我不確定如何存儲這些信息。我也對替代解決方案感興趣，最好不包括驗證碼。

我猜cookie不會工作，因爲阻止cookie或自動清除它們，但會話的工作？還是它必須存儲在數據庫中？不知道可以使用什麼方法，所以我根本不知道什麼是實用的。

Answer 1

在用戶表'failed_login_attempts'和'failed_login_time'中使用一些列。第一個失敗登錄時遞增，並在成功登錄時重置。第二個允許您將當前時間與上次失敗時間進行比較。

您的代碼可以在數據庫中使用這些數據，以確定它需要等待的時間允許登錄等之間鎖定的用戶，時間

Answer 2

假設谷歌已經做了必要的可用性測試（而不是一個不公平的假設）並決定使用驗證碼，我建議與他們一起去。

增加超時是令人沮喪的，當我真正的用戶忘記了密碼（有這麼多的網站及其相關的密碼出現這種情況很多，尤其是對我來說）

Answer 3

存儲嘗試在數據庫中是最好的解決方案恕我直言，因爲它給你的安全漏洞企圖的審計記錄。根據您的應用程序，這可能會或可能不是法定要求。

通過記錄所有不良嘗試，您還可以收集更高級別的信息，例如，如果請求來自一個IP地址（即某人/某事正試圖進行暴力攻擊），以便阻止IP地址。這可以是非常有用的信息。

一旦你確定了一個門檻，爲什麼不強迫他們要求把電子郵件發送到他們的電子郵件地址（即類似'我忘記了我的密碼'），或者你可以去CAPCHA方法。

Answer 4

你知道哪個用戶標識符正在被命中，保留一個標誌，當它達到閾值時，只需停止接受該用戶的任何內容。但這意味着您爲每個用戶存儲額外的數據值。

我喜歡嘗試之間的指數增加時間的概念，[...]

而不是使用成倍增加的時候，你實際上可以有連續嘗試之間的隨機滯後。

也許如果你解釋你在這裏使用的是什麼技術，將能夠幫助更具體的例子。

Answer 5

存儲信息服務器端。這將允許您也抵禦分佈式攻擊（來自多臺機器）。

Answer 6

你可能想說塊在一段時間內登錄比方說10分鐘例如3次失敗嘗試後。指數增長的時間對我來說聽起來不錯。是的，將信息存儲在服務器端會話或數據庫中。數據庫更好。由於用戶很容易操作，因此沒有Cookie業務。

您可能還希望將這種嘗試映射到客戶端IP地址上，因爲有可能有效的用戶會在別人試圖通過失敗嘗試猜測有效的用戶密碼時收到阻止的消息。

Answer 7

鎖定政策是一切都很好，但有一個平衡。

一個考慮因素是考慮用戶名的構造 - 可以猜測嗎？他們可以被枚舉嗎？

我是一個外部應用程序滲透測試與員工門戶在網絡公司投放的Outlook Web Access/Intranet的服務，某些應用程序。列舉用戶（網站本身的執行/管理團隊，以及Google，Facebook，LinkedIn等）很容易。一旦你得到了用戶名登錄的格式（姓氏，然後姓氏作爲一個字符串輸入），我有能力關閉100名用戶，因爲他們的3次罷工和出局政策。

Answer 8

答案在這篇文章中重點發展的中心數據庫解決方案，因爲它們提供的，使審計和閉鎖邏輯方便記錄的結構。

雖然這裏的答案，解決個人用戶猜測攻擊，這種方法的主要問題是，它讓開Denial of Service攻擊的系統。來自世界各地的任何請求應該不會觸發數據庫工作而不是。

的替代（或附加）的安全層應提前在REQ/RES循環實現，以保護應用程序和數據庫從執行閉鎖操作，可以是昂貴的，並且是不必要的。

Express-Brute是利用Redis的高速緩存過濾掉惡意請求，同時允許誠實的一個很好的例子。