拥有个人帐户的WEB资源前面出现的问题之一是蛮力攻击。 是的，一个特定帐户的所有密码选项的简单枚举。 笨吗 也许可以，但是这样的攻击可能会严重占用资源。 此外，如果在注册过程中无法控制用户密码的复杂性，也可能会成功。
通常，该问题相对简单地解决。 如果用户多次错误输入密码，则其帐户将被封锁一段时间。 另一种解决方案是显示验证码。 立即或多次尝试失败后。 好吧，我们不要忘记2F授权，这几乎是无懈可击的。 看来-利润！ 但是，并非所有事情都如此乐观……
让我们看一下描述解决方案的一些问题：
临时阻止 -用户帐户被临时阻止，他无法进入系统。 攻击期间的真实用户会感到心痛和折磨。 他无法进入系统。 而且很可能会得到您的支持。 最有趣的是，也许这就是攻击者的目标。
验证码是一个相对较好且有效的解决方案。 真相给用户带来不便，要求您在此处另外输入一些内容。 足以“令人不快”地嵌入设计中。 哦，是的。。。依实施情况而定，这可能会受到DoS攻击。
2F授权 -一切都很好。 是的...通常这是可选的。 打开它以抵抗攻击将无法进行。 她要么在那里，要么不在那里。 在某些资源上，输入2F授权，比方说，从水箱射麻雀。
我尝试创建方便可靠的服务。 因此，我决定有点紧张。 就是这样。
如果您使用mail（例如mail.ru）并且安装了2F授权，则您可能已经注意到，首次登录时仅要求为新的“设备”请求2F授权。 此外，该设备被认为是可信的。 您只需要输入您的登录名和密码。
方便的事情。 用户友好，可以这么说。 这是通过两个令牌实现的。 第一个标识符是“设备”（定义为devid），第二个是会话标识符（定义为会话）。 与会话不同，Devid即使在用户结束会话后也不会失去其相关性。 它将在下次登录尝试时传输，并且如果用户名/密码正确且受信任，则不再请求2F。 但是，如果下一次登录尝试失败，则分隔令牌将立即失效。 现在，您需要走完整的授权路径。
该范例作为基础。 即 输入devid令牌，该令牌将不断发出，并且来自WEB资源的任何响应（当然，如果请求中未包含）。
对于授权情况2F，实际上实现了上述算法。 随即每个人都感到高兴。 T.ch. 详细检查它没有意义。 但是对于“钟声和口哨声”，最好考虑一下图表，并附上解释：
即使未安装2F授权，但登录成功，该devid令牌仍被标记为受信任。 如果没有2F授权，这样做似乎没有什么意义。 但是，一切都有些棘手。 如果我们知道devid是受信任的，即 他已经成功登录，我们至少假设真实用户来自此设备。 这是描述的算法在攻击反射模式下的工作中使用的非常重要的信息。
采用了一种策略：只有存在有效的devid令牌，才能进行任何授权。 有效的设备与受信任的设备不同之处在于，它尚未受信任，即 没有成功的登录，但是系统已准备就绪，可以使用它来处理授权请求。 每个有效令牌的尝试次数限制为N次。 如果授权错误连续发生N次以上，则令牌被标记为“已损坏”。 它被转移到具有选择统计信息的单独日记帐中。 他参与的请求将继续得到处理，但是...无法再与他登录。 所有发生的都是活动统计信息的累积。
因此，最愚蠢的攻击反击了。 例如，如果攻击者无视devid尝试登录系统，或者如果他不了解devid的逻辑（他怎么知道用相同的devvid进行了多少次登录尝试？），则他的请求将被终止。
自己的战线知道，经过一个设备N次失败的登录尝试后，它已经“烂”了。 现在，您需要在下次登录之前获取一个新令牌。
看起来是什么样的愚蠢？ 前线完成了进入的企图……但是，正如我上面所说，一切都比较棘手。 如果用户通过标准前端工作，则他实际上试图攻击系统的可能性可以忽略不计。 在用户注册期间与密码复杂性控制系统配合使用，这完全是徒劳的。 实际用户最有可能真的想记住他的密码。
那么，诀窍是什么？ 事实上，在背面我们会在一定的时间限制内生成非常有效的分度。 例如，每分钟不超过1000个。 如果突然超过此限制，则会终止攻击模式。 在这里，您可以大胆地停止散布病毒一段时间，以降低攻击者的热情，或减少有效散布的产生。 您可以为所有有效但不受信任的设备启用相同的验证码。
因此，获得了用于控制和管理攻击的灵活系统。 生成可靠的指标，通过该指标可以触发监视并发出警报。 累积的统计信息可以转换为阻止规则等。
一个友好的系统是因为以前登录过的用户，即 有信任的戴维甚至没有注意到攻击。 它们将被系统跳过，不会出现任何问题。
现在赢利。 该算法在负载非常高的资源上非常完善。 除其他外，DoS尝试了算法本身，但即使在这里也证明是值得的。