防止蛮力login网站
作为对最近的Twitter劫持和杰夫的字典攻击的post的回应，什么是保护您的网站免受蛮力login攻击的最佳方式？
杰夫的postbuild议，对每个尝试login的延迟时间会有所增加，并且评论中的build议是在第二次失败尝试后添加validation码。
这两个看起来都是好主意，但你怎么知道它是什么“尝试数字”？ 您不能依靠会话ID（因为攻击者每次都可以更改）或IP地址（更好，但易受僵尸networking攻击）。 简单地logging用户名可以使用延迟方法locking一个合法用户（或者至less使他们的login过程非常缓慢）。
思考？ build议？
我认为数据库坚持给定账户（1-5分钟）的短暂locking期是处理这个问题的唯一方法。 数据库中的每个userid包含一个timeOfLastFailedLogin和numberOfFailedAttempts 。 当numbeOfFailedAttempts > X你locking几分钟。
这意味着你locking了一段时间的userid ，但不是永久的。 这也意味着你正在为每个login尝试更新数据库（当然，除非它被locking），这可能会导致其他问题。
亚洲至less有一个全国性的NAT，因此IP不能用于任何事情。
在我看来，有几种可能性，每种都有利弊：
强制安全密码
- 专业 ：将防止字典攻击
- 骗子 ：也会阻止stream行，因为大多数用户不能记住复杂的密码，即使你向他们解释，如何容易记住他们。 例如，通过记住句子：“我在Mall购买了一个5美分的苹果”导致“Ib1Af5CitM”。
多次尝试后locking
- 临 ：将减慢自动化testing
- Con ：为第三方locking用户很容易
- Con ：在数据库中使它们持久化可能会导致在诸如Twitter或可比较的大型服务中进行大量的写入过程。
validation码
- Pro ：他们阻止自动testing
- Con ：他们在计算时间
- Con ：会“减慢”用户体验
- 巨大的CON ：他们不是无障碍的
简单的知识检查
- 临 ：将阻止自动testing
- 骗子 ：“简单”是在旁观者的眼中。
- Con ：会“减慢”用户体验
不同的login名和用户名
- 临 ：这是一个技术，这是很难看到，但在我看来，一个相当不错的开始，以防止暴力攻击。
- Con ：取决于用户对这两个名字的select。
使用整个句子作为密码
- Pro ：增加可search空间的大小。
- Pro ：大多数用户更容易记住。
- 骗局 ：取决于用户的select。
正如你所看到的，“好”的解决scheme都取决于用户的select，这再次揭示了用户是最薄弱的环节。
还有其他build议吗？
你可以做Google做的事情。 经过一定次数之后，他们会出现一个captacha。 经过几次与captacha你locking了几分钟。
我倾向于同意大多数其他意见：
- X尝试密码失败后locking
- 计数失败的用户名尝试
- 可select使用CAPTCHA（例如，尝试1-2正常，尝试3-5被CAPTCHA'd，进一步尝试被阻止15分钟）。
- 可以select发送电子邮件给账户所有者以删除该块
我想指出的是，你应该非常小心地强制使用“强”的密码，因为这通常意味着他们只能写在桌子上的贴在显示器上的贴子上。 而且，一些密码策略导致更可预测的密码。 例如：
如果密码不能是任何以前使用过的密码，并且必须包含一个数字，那么很有可能它将是任何通用密码，后面是一个连续的数字。 如果你必须每6个月更换一次密码，而且有两年的时间，那么他们的密码可能就是password4 。
说你更加限制它：至less8个字符，不能有任何连续的字母，必须有一个字母，数字和特殊字符（这是一个真正的密码策略，许多人会认为是安全的）。 试图闯入约翰·昆西·史密斯的账户？ 知道他3月6日出生？ 有一个很好的机会，他的密码是像jqs0306！ （或者jqs0306〜 ）。
现在，我并不是说让用户拥有密码也是一个好主意，只要不要自欺欺人地认为强制的“安全”密码是安全的。
详细说明最佳实践：
krosenvold说：在用户表中loggingnum_failed_logins和last_failed_time（用户挂起时除外），一旦失败的login次数达到阈值，就会暂停用户30秒或一分钟。 这是最好的做法。
该方法有效地消除了单帐户暴力和字典攻击。 但是，这并不能防止攻击者在用户名之间切换， 保持密码不变，并尝试用大量的用户名。 如果您的网站有足够的用户，那么这种攻击可以持续很长一段时间，然后用完未中止的帐户。 希望他能从单一的IP上运行这个攻击（不太可能，因为僵尸networking真的成了这个行业的工具），所以你可以检测到并阻止IP，但是如果他分发攻击的话……好吧，这是另一个问题（我刚刚在这里发布，所以请检查出来，如果你没有） 。
关于最初的想法还有一点需要记住的是，即使帐户被攻击和暂停，也应该让合法用户通过，也就是说，如果你能告诉真实用户和机器人分开。
你至less可以用两种方法。
-
如果用户有一个持久的login（“记住我”）cookie，只要让他通过。
-
当您显示“我很抱歉，您的帐户由于login尝试失败次数很多而被暂停”的消息时，请提供一个链接，指出“ 安全备份login – 只限于人（机器人：不说谎） ”。 开玩笑，当他们点击链接时，给他们一个reCAPTCHAauthenticationlogin表单， 绕过帐户的暂停状态。 这样，如果他们是人类，并且知道正确的login名和密码（并且能够读取CAPTCHA），他们将永远不会被延迟所困扰，并且您的站点将不受快速攻击的影响。
唯一的缺点是：有些人（如视觉障碍者）无法读取CAPTCHA， 如果他们没有使用自动loginfunction，他们可能仍然受到恼人的bot延迟的影响。
什么不是缺点：自动loginCookie没有内置的类似安全措施。 为什么不是这个缺点，你问？ 因为只要你明智地实现了它，你logincookie中的安全令牌（等同于密码）就是你密码的两倍（骇人听闻，这个比特是你的密码的十倍！），所以蛮横的实际上是一个非问题 。 但是，如果你确实是偏执狂，那么在自动loginfunction上也要设置一秒钟的延迟时间，这是为了好的措施。
像大多数银行一样，在Xlogin失败后locking用户名/账户。 但是我不会像银行一样严格，因为你必须打电话来解锁你的账户。 我会在1-5分钟内暂时locking。 当然，除非networking应用程序像银行一样对数据敏感。 🙂
您应该在与您的后端数据库没有关联的应用程序中实现一个caching。
首先拖延只有合法的用户名，导致你“放弃”en-mass你有效的客户群，这本身可能是一个问题，即使用户名不是一个严密的保密。
其次，取决于您的应用程序，您可以使用特定于应用程序的延迟对策来实现一些智能，这些对策可能比您想要将数据存储在数据库中的对象要多得多。
它抵抗高速尝试将泄漏DOS条件到您的后端数据库。
最后可以根据IP做出一些决定……如果你看到一次IP的单次尝试，那么可能是一个诚实的错误，而来自上帝的多个IP知道有多less系统可能需要采取其他预防措施或通知最终用户阴暗的活动。
它的真正的大型代理联盟可以有大量的IP地址供他们使用，但是大多数人会做出合理的努力来维护你的源地址一段时间的遗留目的，因为一些站点有一些cookie数据绑定到IP。
我认为你应该logging用户名。 这是唯一的常数（任何其他可以被欺骗）。 是的，它可以locking合法用户一天。 但是，如果我必须select一个黑客帐户和一个closures的帐户（一天），我肯定select了锁。
顺便说一下，在第三次尝试失败（在一定时间内）之后，您可以locking帐户，并向所有者发送发行邮件。 该邮件包含解锁该帐户的链接。 这对用户来说是一个轻微的负担，但是破解者被阻止。 如果连邮件账号都被黑了，你可以设定每天解锁次数的限制。
我login到网上的很多在线留言板给了我五次login帐号的尝试，在这5次尝试之后帐号被locking了一个小时或十五分钟。 这可能不太好，但是这肯定会减缓一个账户上的字典攻击。 现在没有什么是在同一时间停止对多个帐户的字典攻击。 即尝试5次，切换到另一个帐户，尝试另外5次，然后圈回来。 但它确实减缓了这次袭击。
防止字典攻击的最好办法是确保密码不在字典中！ 基本上build立了一些密码策略来检查字典与字母，并要求在密码中的数字或符号。 这可能是防止字典攻击的最好防线。
你可以添加一些forms的CAPTCHAtesting。 但是要注意，大多数人都会让人更加难以接受，或者让人感到不适。 CAPTCHA的一个有趣的forms是提出一个问题，
2和2的总和是多less？
如果您logging最后一次login失败，则可以跳过validation码（如果足够长）。 如果最后一次失败是在过去的10分钟内，那么只做CAPTCHAtesting。
对于.NET环境
dynamicIP限制
IIS的dynamicIP限制扩展为IT专业人员和主机提供了一个可configuration的模块，通过暂时阻止HTTP客户端的Internet协议（IP）地址，帮助缓解或阻止拒绝服务攻击或破解密码。有利于这样的攻击之一。 可以对此模块进行configuration，以便可以在Web服务器或网站级别进行分析和阻止。
通过dynamic阻止来自恶意IP地址的请求，减less拒绝服务攻击的可能性
针对IIS的dynamicIP限制允许您通过检查请求的源IP并识别可能表示攻击的模式来降低受到拒绝服务攻击的Web服务器的概率。 当检测到攻击模式时，模块会将违规IP放置在临时拒绝列表中，并避免在预定时间内响应请求。
最大限度地减lessWeb服务器密码暴力破解的可能性
IIS的dynamicIP限制能够检测到指示尝试解码Web服务器的密码的请求模式。 该模块会将违规的IP放置在拒绝访问预定时间的服务器列表中。 在对Active Directory服务（ADS）进行身份validation的情况下，该模块能够通过避免向ADS发出身份validation挑战来维护Web服务器的可用性。
特征
-
无缝集成到IIS 7.0pipe理器中。
-
根据以下任一标准dynamic阻止来自IP地址的请求：
-
并发请求的数量。
-
一段时间内的请求数量。
-
-
支持允许绕过dynamicIP限制过滤的IP列表。
-
阻止请求可以在Web站点或Web服务器级别进行configuration。
-
可configuration的拒绝操作允许ITpipe理员指定将返回给客户端的响应。 该模块支持返回状态码403,404或closures连接。
-
支持IPv6地址。
-
支持可能修改客户端IP地址的代理或防火墙后面的Web服务器。
旧post，但让我发布我在2016年底这个。希望它仍然可以帮助。
这是一个简单的方法，但我认为它是强大的，以防止login攻击。 至less我总是把它用在我的每一个网页上。 我们不需要CAPTCHA或任何其他第三方插件。
当用户第一次login时。 我们创build一个会话
$_SESSION['loginFail'] = 10; // any number you prefer
如果login成功，那么我们将销毁它并让用户login。
unset($_SESSION['loginFail']); // put it after create login session
但是如果用户失败，就像我们通常向他们发送错误信息一样，同时我们把会话减less1：
$_SESSION['loginFail']-- ; // reduce 1 for every error
如果用户失败了10次，我们会将他们引导到其他网站或任何网页。
if (!isset($_SESSION['loginFail'])) { if ($_SESSION['login_fail'] < 1 ) { header('Location:https://google.com/'); // or any web page exit(); } }
这样，用户就不能打开或进入我们的login页面，导致它已被redirect到其他网站。
用户必须closures浏览器（以销毁我们创build的会话loginFail），再次打开它，再次看到我们的login页面。
有帮助吗？
