什么是最好的分布式蛮力对策？
首先，有一点背景：我为CodeIgniter实施auth + auth系统并不是什么秘密，到目前为止我赢了（可以这么说）。 但是我遇到了一个非常不平凡的挑战（大多数auth库完全错过了，但我坚持正确处理它）：如何智能处理大规模，分布式，可变用户名的暴力攻击 。
我知道所有常用的技巧：
现在，这些只是理论上可行的想法。 有大量的垃圾想法使网站全面开放（例如，微不足道的DoS攻击）。 我想要的是更好的东西。 更好的是，我的意思是：
它必须是安全的（+）反对DoS和暴力攻击，并且不会引入任何新的漏洞，可能会让稍微偷偷摸摸的机器人继续在雷达下工作
它必须是自动的。 如果它需要人工操作员验证每个登录或监视可疑活动，那么它不适用于真实世界的情况
它对于主流网站的使用必须是可行的（例如，高流量，高容量和可以由非程序员执行的开放注册）
它不能阻止用户体验到临时用户会感到恼火或沮丧（并可能放弃网站）
它不能涉及小猫，除非它们真的很安全的小猫
（+）'安全'，我的意思是至少和偏执狂用户保密密码的能力一样安全
所以 - 让我们听听它！ 你会怎么做？ 你知道我没有提到过的最佳做法吗（噢，请说你这么做）？ 我承认我确实有自己的想法（将3和4的想法结合起来），但我会让真正的专家在尴尬自己之前先说话;-)
好吧，足够拖延; 这是我到目前为止所提出的
（对不起，很久以后，勇敢，朋友，旅程将是值得的）
将原始文章中的方法3和方法4合并为一种“模糊”或动态白名单，然后 - 这就是诀窍 - 不会阻止未列入白名单的IP，只是将它们限制在地狱背后。
请注意，这一措施只是为了阻止这种非常特殊的攻击。 实际上，它可以与auth的其他最佳实践方法结合使用：固定用户名限制，每IP限制，代码强制强密码策略，未限制的cookie登录，在保存之前对所有密码进行散列处理，从不使用安全问题等。
有关攻击场景的假设
如果攻击者瞄准变量用户名，我们的用户名限制不会触发。 如果攻击者正在使用僵尸网络或有权访问大量的IP范围，我们的IP限制无能为力。 如果攻击者已经预先删除了我们的用户列表（通常可能在开放注册Web服务上），我们无法根据“找不到用户”错误的数量检测到持续的攻击。 如果我们强制执行限制性系统范围（所有用户名，所有IP）限制，则任何此类攻击都会在攻击期间加上限制期间阻止我们的整个站点。
所以我们需要做其他的事情。
第一部分对策：白名单
我们可以确信的是，攻击者无法检测并动态欺骗数千名用户（+）的IP地址。 这使得白名单变得可行。 换句话说：对于每个用户，我们存储用户以前（最近）登录过的（散列）IP列表。
因此，我们的白名单计划将作为一个锁定的“前门”，用户必须从他的一个公认的“好”IP中连接才能登录。 对这个“前门”的暴力攻击实际上是不可能的（+）。
（+），除非攻击者'拥有'服务器，所有用户的盒子或连接本身 - 在这种情况下，我们不再有'认证'问题，我们有一个真正的特许经营规模拉 - - 插头FUBAR的情况
第二部分对策：系统范围的无法识别的IP节流
为了使开放注册Web服务的白名单工作，用户频繁地切换计算机和/或连接动态IP地址，我们需要为从未识别的IP连接的用户开放“猫门”。 诀窍在于设计这个门让僵尸网络卡住，合法用户尽可能少地受到打扰。
在我的方案中，这是通过设置一个非常限制性的最大数量的未经批准的IP登录尝试，例如3小时（根据服务类型使用更短或更长的时间可能更明智），以及使这种限制是全球性的 ，即。 为所有用户帐户。
即使是一个缓慢的（每次尝试之间1-2分钟）暴力也会被使用这种方法快速有效地检测和阻止。 当然，一个非常缓慢的蛮力仍然可以不被人注意，但速度太慢击败暴力攻击的目的。
我希望通过这种节流机制实现的目标是，如果达到最大限度，我们的“猫门”会关闭一段时间，但我们的前门仍然对通过常规方式连接的合法用户开放：
在攻击过程中受到影响的唯一合法用户 - 即。 而节流被激活 - 将是没有持续登录cookie的用户从未知位置或动态IP登录。 这些用户将无法登录，直到限制消失（如果攻击者不顾限制地继续运行僵尸网络，这可能需要一段时间）。
为了让这一小部分用户能够通过另外密封的猫门，即使机器人仍在凿击它，我也会使用带有CAPTCHA的“备份”登录表单。 因此，当您显示“对不起，但您目前无法从此IP地址登录”消息时，请包含一个链接，其中显示“ 安全备份登录 - 只限人员（机器人：不说谎） ”。 开玩笑，当他们点击该链接时，给他们一个reCAPTCHA认证的登录表单，绕过整个网站的限制。 这样，如果他们是人类，并且知道正确的登录名+密码（并且能够读取CAPTCHA），即使他们从未知主机连接并且不使用自动登录cookie，他们也不会被拒绝服务。
哦，只是为了澄清：因为我确实认为CAPTCHA通常是邪恶的，所以'备份'登录选项只会在节流被激活时出现。
不可否认的是，像这样的持续攻击仍然会构成DoS攻击的一种形式，但是通过所描述的系统，它只会影响我认为只是一小部分用户的人群，也就是那些不使用“记住我”Cookie，恰巧在攻击发生时登录，并且不从任何通常的IP登录，也无法读取CAPTCHA。 只有那些能够拒绝所有这些标准的人 - 特别是机器人和真正不幸的残疾人 - 才会在机器人攻击期间被拒绝。
编辑：实际上，我想到了一种方法，即使在CAPTCHA挑战的用户在“锁定”期间也能通过：替代或作为备份CAPTCHA登录的补充，向用户提供一次性使用选项，发送到他的电子邮件的用户特定的锁定代码，然后他可以用来绕过限制。 这肯定会影响我的'烦恼'的门槛，但因为它只是用于一小部分用户的最后手段 ，并且由于它仍然被锁定在帐户之外，所以这是可以接受的。
（另外请注意，如果攻击比我在这里描述的令人讨厌的分布式版本稍微复杂一点，就不会发生这种情况，如果攻击来自少数几个IP或仅击中几个用户名，攻击将会早得多，而且没有全站的后果）
所以，一旦我确信它是健全的，并且没有我错过的更简单的解决方案，我将在我的auth库中实施这种对策。 事实上，在安全方面做错事情有很多微妙的方法，而且我并不是在做出错误的假设或无可救药的逻辑错误。 所以，请大家高度赞赏任何和所有的反馈，批评和改进，微妙之处等。
几个简单的步骤：
将某些常用用户名列入黑名单，并将它们用作蜜罐。 管理员，客人等等......不要让任何人用这些名字创建账户，所以如果有人确实尝试登录他们，你就知道这是某人在做他们不应该做的事情。
确保任何有实力的网站都有安全的密码。 要求管理员/管理员使用字母，数字和符号组合的较长密码。 解释普通用户拒绝简单密码。
你可以做的最简单的事情之一是告诉人们何时有人试图登录他们的账户，并给他们一个链接来报告事件，如果不是他们。 他们登录时出现一条简单的消息，如“有人在周三凌晨4点20分试图登录您的帐户，等等，如果这不是您，请点击此处。” 它可以让你保存一些攻击统计数据。 如果您发现欺诈访问突然增加，您可以加强监控和安全措施。
如果我正确理解暴力攻击的MO，则会连续尝试一个或多个用户名。
有两个建议，我不认为我在这里看过：
编辑 ：为了响应用户名油门的评论：这是一个用户名特定的油门，不考虑攻击的来源。
如果用户名受到限制，那么即使是协调的用户名攻击（多IP，单个猜测每个IP，相同的用户名）也会被捕获。 即使攻击者在超时期间可以自由尝试其他用户/密码，个别用户名也受到限制。
从攻击者的角度来看，在暂停期间，您可能会首次猜测100个密码，并快速发现每个帐户有一个错误的密码。 您可能只能在同一时间段内进行50秒的猜测。
从用户帐户的角度来看，即使猜测来自多个来源，仍然需要相同的平均猜测次数来破解密码。
对于攻击者来说，充其量也是同样的努力来打破100个帐户，但是由于您不是在站点范围内进行节流，所以您可以很快地加快节流。
额外的改进：
用户界面的想法（在这种情况下可能不适合），这也可以改进上述：
上一篇: What is the best Distributed Brute Force countermeasure?
下一篇: Does it make security sense to hash password on client end