将原始帖子中的方法 3 和 4 组合成一种“模糊”或动态白名单，然后 - 这就是技巧 -不阻止非白名单IP，只是将它们限制在地狱中并返回.
请注意，该措施是only旨在阻止这种非常特殊类型的攻击。当然，在实践中，它可以与其他最佳实践方法结合起来进行身份验证：固定用户名限制、每个 IP 限制、代码强制的强密码策略、不受限制的 cookie 登录、在保存之前对所有密码等效项进行哈希处理，从不使用安全问题等
关于攻击场景的假设
如果攻击者的目标是可变用户名，我们的用户名限制不会触发。如果攻击者使用僵尸网络或访问较大的IP范围，我们的IP限制就无能为力。如果攻击者预先抓取了我们的用户列表（通常可以在开放注册 Web 服务上实现），我们将无法根据“未找到用户”错误的数量来检测正在进行的攻击。如果我们强制执行限制性的系统范围（所有用户名、所有 IP）限制，则任何此类攻击都将在攻击持续时间加上限制期间对我们的整个网站进行 DoS。
所以我们需要做点别的事情。
对策第一部分：白名单
我们可以相当确定的是，攻击者无法检测并动态欺骗我们数千名用户的 IP 地址 (+)。这使得白名单可行的。换句话说：对于每个用户，我们存储该用户之前（最近）登录的（散列）IP 列表。
因此，我们的白名单方案将充当一扇上锁的“前门”，用户必须从其公认的“良好”IP 之一进行连接才能登录。对这个“前门”进行暴力攻击实际上是不可能的(+)。
(+) 除非攻击者“拥有”服务器、我们所有用户的盒子或连接本身——在这些情况下，我们不再有“身份验证”问题，我们有一个真正的特许经营规模的拉动-插头FUBAR情况
对策第二部分：全系统节流无法识别的 IP
为了使白名单适用于开放注册 Web 服务（其中用户经常切换计算机和/或从动态 IP 地址进行连接），我们需要为从无法识别的 IP 地址进行连接的用户保持“猫门”开放。诀窍是设计这扇门，让僵尸网络陷入困境，让合法用户受到困扰尽可能少.
在我的方案中，这是通过设置一个来实现的very限制未经批准的 IP 在 3 小时内尝试失败的最大次数（根据服务类型使用更短或更长的时间可能更明智），并进行该限制global， IE。对于所有用户帐户。
使用此方法，即使是缓慢的（两次尝试之间 1-2 分钟）的暴力破解也能快速有效地被检测到并阻止。当然，一个真的很慢暴力攻击仍然可能不被注意，但速度太慢就无法达到暴力攻击的目的。
我希望通过这种限制机制实现的是，如果达到最大限制，我们的“猫门”会关闭一段时间，但我们的前门仍然对通过常规方式连接的合法用户开放：
- 通过从其认可的 IP 之一进行连接
- 或者使用持久登录 cookie（从任何地方）
在攻击期间唯一会受到影响的合法用户 - 即。当限制被激活时 - 没有持久登录 cookie 的用户从未知位置或使用动态 IP 登录。这些用户将无法登录，直到限制消失（如果攻击者在限制下仍保持其僵尸网络运行，这可能需要一段时间）。
为了让这一小部分用户能够挤过原本密封的猫门，即使机器人仍在努力敲打它，我也会使用带有验证码的“备份”登录表单。这样，当您显示“抱歉，您目前无法从此 IP 地址登录”消息时，请包含一个链接，其中显示“安全备份登录 - 仅限人类（机器人：不说谎)“。开个玩笑，当他们点击该链接时，给他们一个经过 reCAPTCHA 验证的登录表单，绕过站点范围的限制。这样，如果他们是人类并且知道正确的登录名+密码（并且能够读取验证码），他们会never被拒绝服务，即使他们从未知主机连接并且不使用自动登录 cookie。
哦，只是为了澄清：因为我确实认为验证码通常是邪恶的，所以“备份”登录选项将only appear 当节流处于活动状态时.
不可否认，像这样的持续攻击仍然会构成一种形式的 DoS 攻击，但在所描述的系统到位的情况下，它只会影响我怀疑的一小部分用户，即不使用该服务的人。 “记住我”cookie 并且在攻击发生时恰好登录并且没有从任何常用 IP 登录并且无法读取验证码。只有那些能够对所有这些标准说不的人 - 特别是机器人和真不走运残疾人 - 在机器人攻击期间将被拒之门外。
EDIT:实际上，我想到了一种方法，即使是有验证码挑战的用户也可以在“锁定”期间通过：代替备份验证码登录或作为备份验证码登录的补充，为用户提供一个选项，让其拥有一次性用户- 将特定的锁定代码发送到他的电子邮件，然后他可以使用该代码来绕过限制。这绝对跨越了我的“烦恼”阈值，但由于它仅用作最后一招对于一小部分用户来说，由于它仍然比被锁定在您的帐户之外更好，所以这是可以接受的。
（另外，请注意none如果攻击没有我在这里描述的令人讨厌的分布式版本那么复杂，就会发生这种情况。如果攻击仅来自几个 IP 或仅攻击几个用户名，那么攻击将会更早地被阻止，并且no全站范围的后果）
因此，这就是我将在我的身份验证库中实施的对策，一旦我确信它是合理的并且没有我错过的更简单的解决方案。事实是，在安全方面有很多微妙的方法可以做错事情，而且我不会避免做出错误的假设或无可救药的有缺陷的逻辑。所以，任何和所有的反馈、批评和改进、微妙之处等都受到高度赞赏。
