防止网站上的暴力登录

Question

作为对最近的Twitter劫持和Jeff关于字典攻击的帖子的回应,保护您的网站免受暴力登录攻击的最佳方法是什么？

杰夫的帖子建议每次尝试登录都会增加延迟,评论中的建议是在第二次尝试失败后添加验证码.

这两个看起来都是好主意,但你怎么知道它的"尝试数"是什么？您不能依赖会话ID(因为攻击者每次都可以更改它)或IP地址(更好,但易受僵尸网络攻击).只需根据用户名记录它就可以使用延迟方法锁定合法用户(或者至少使登录过程对他们来说非常慢).

思考？建议？

Answer 1

我认为给定帐户(1-5分钟)的数据库持久的短暂锁定期是处理此问题的唯一方法.userid数据库中的每个都包含一个timeOfLastFailedLogin和numberOfFailedAttempts.当numbeOfFailedAttempts > X你锁定对于一些分钟.

这意味着您将userid问题锁定一段时间,但不是永久性的.它还意味着您为每次登录尝试更新数据库(当然,除非它被锁定),这可能会导致其他问题.

在亚洲至少有一个国家是NAT,所以IP不能用于任何事情.

Answer 2

在我看来,有几种可能性,每种都有缺点和优点:

强制安全密码

• 亲:会阻止字典攻击
• Con:也会阻止流行,因为大多数用户都无法记住复杂的密码,即使你向他们解释,如何轻松记住它们.例如,通过记住句子:"我在购物中心买了1个Apple for 5 Cent"导致"Ib1Af5CitM".

几次尝试后锁定

• Pro:会减慢自动化测试速度
• Con:很容易锁定第三方用户
• Con:让它们在数据库中持久化可能会导致很多写入流程在Twitter或可比较等巨大的服务中.

验证码

• 亲:他们阻止自动化测试
• Con:他们正在消耗计算时间
• Con:将"减慢"用户体验
• 巨大的CON:它们不是无障碍的

简单的知识检查

• 亲:会阻止自动化测试
• 骗局:"简单"是旁观者的眼睛.
• Con:将"减慢"用户体验

不同的登录和用户名

• 亲:这是一种技术,很难看到,但在我看来,这是防止蛮力攻击的良好开端.
• Con:取决于用户对两个名称的选择.

使用整个句子作为密码

• Pro:增加可搜索空间的大小.
• 专业版:大多数用户都更容易记住.
• Con:取决于用户的选择.

正如您所看到的,"好"解决方案都取决于用户的选择,这再次将用户视为链中最薄弱的元素.

还有其他建议吗？

Answer 3

你可以做谷歌做的事情.经过一定数量的尝试,他们有一个captacha出现.与使用captacha几次之后,你将它们锁定几分钟.

Answer 4

我倾向于同意大多数其他评论:

• X密码尝试失败后锁定
• 计算对用户名的失败尝试
• 可选择使用CAPTCHA(例如,尝试1-2是正常的,尝试3-5是CAPTCHA,进一步尝试阻止15分钟).
• (可选)向帐户所有者发送电子邮件以删除该块

我想要指出的是,你应该非常小心强制使用"强"密码,因为这通常意味着它们只能写在桌面上的帖子上/连接到显示器上.此外,某些密码策略会导致更可预测的密码.例如:

如果密码不能是以前使用过的任何密码并且必须包含一个数字,那么它很可能是一个带有序号的常用密码.如果你必须每6个月更改一次密码,并且一个人已经在那里呆了两年,那么他们的密码很可能就像密码4.

假设您更加限制它:必须至少8个字符,不能有任何连续的字母,必须有一个字母,一个数字和一个特殊字符(这是许多人认为安全的真实密码策略).试图闯入John Quincy Smith的账户？知道他出生在3月6日吗？他的密码很可能像jqs0306!(或者也许是jqs0306~).

现在,我并不是说让用户拥有密码密码也不是一个好主意,只是不要自欺欺人地认为你的强制"安全"密码是安全的.

Answer 5

详细说明最佳做法:

krosenvold说的是:在用户表中记录num_failed_logins和last_failed_time(用户被暂停时除外),一旦登录失败次数达到阈值,您将暂停用户30秒或一分钟.这是最好的做法.

该方法有效地消除了单一帐户暴力破解和字典攻击.但是,它不会阻止攻击者在用户名之间切换 - 即.保持密码修复并尝试使用大量用户名.如果您的网站有足够的用户,那么这种类型的攻击可以持续很长时间,然后才能用完未被删除的帐户.希望他能从一个IP运行这种攻击(不太可能,因为僵尸网络现在真的成为交易的工具)所以你可以检测到并阻止IP,但如果他正在分发攻击......好吧,这是另一个问题(我刚刚在这里发布,所以如果你没有,请检查一下).

关于最初想法的另一个要记住的事情是,你当然应该试图让合法用户通过,即使在帐户遭到攻击和暂停时 - 也就是说,如果你可以告诉真实用户和机器人.

你可以,至少有两种方式.

1. 如果用户有持久登录("记住我")cookie,那就让他通过.

2. 当您显示"对不起,您的帐户由于大量不成功的登录尝试而被暂停"消息时,请包含一个链接,上面写着" 安全备份登录 - 仅限人们(机器人:没有说谎) ".除了笑话,当他们点击该链接时,给他们一个reCAPTCHA认证的登录表单,绕过帐户的暂停状态.这样,如果他们是人类并且知道正确的登录+密码(并且能够读取CAPTCHA),他们将永远不会受到延迟的困扰,并且您的站点将不受快速攻击的影响.

唯一的缺点:有些人(如视力受损者)无法读取CAPTCHA,如果他们没有使用自动登录功能,他们可能仍会受到烦人的僵尸制造延迟的影响.

什么不是缺点:自动登录cookie没有内置的类似安全措施.你问,为什么这不是一个缺点？因为只要你明智地实现它,你的登录cookie中的安全令牌(密码等效物)就是你的密码的两倍(哎呀,就是这个数量的十倍!),所以蛮力强迫它实际上是一个非问题.但是,如果你真的是偏执狂,那么在自动登录功能上设置一秒钟的延迟,只是为了好的措施.

Answer 6

为此，您应该在不与后端数据库关联的应用程序中实现缓存。

首先，最重要的是仅延迟合法的用户名会导致您“放弃”您的有效客户群，即使用户名不是受到严格保护的秘密，这本身也可能是一个问题。

其次，根据您的应用程序，使用特定于应用程序的延迟对策比将数据存储在DB中要聪明一些。

它可以抵抗将DOS条件泄漏到后端数据库中的高速尝试。

最后，基于IP做出一些决定是可以接受的...如果您看到一次IP尝试一次是一个诚实的错误，而来自IP的多个IP知道您可能想采取其他预防措施或通知最终用户有关的系统数量。阴暗活动。

它真正的大型代理联合会可以保留大量IP地址供其使用，但是大多数联合会确实做了合理的努力将源地址保留一段时间以用于传统目的，因为某些站点习惯将cookie数据绑定到IP。

Answer 7

这是一个旧帖子。然而，我想将我的发现放在这里，以便它可以帮助任何未来的开发人员。

我们需要防止暴力攻击，使攻击者无法获取网站登录的用户名和密码。在许多系统中，它们有一些开放式 URL，不需要身份验证令牌或 API 密钥进行授权。这些 API 中的大多数都很关键。例如; 注册、登录和忘记密码 API 通常是开放的（即不需要验证身份验证令牌）。我们需要确保服务不被滥用。如前所述，我只是将我的发现放在这里，同时研究如何有效地防止暴力攻击。

大多数常见的预防技术已经在这篇文章中讨论过。我想补充一下我对帐户锁定和 IP 地址锁定的担忧。我认为锁定帐户作为预防技术是一个坏主意。我在这里提出一些观点来支持我的事业。

帐户锁定不好

• 攻击者可以通过锁定大量帐户来导致拒绝服务 (DoS)。
• 由于您无法锁定不存在的帐户，因此只有有效的帐户名称才会被锁定。攻击者可以利用这一事实从站点获取用户名，具体取决于错误响应。
• 攻击者可以通过锁定许多帐户并向服务台拨打大量支持电话来造成转移。
• 攻击者可以连续锁定同一帐户，甚至在管理员解锁该帐户几秒钟后，有效地禁用该帐户。
• 帐户锁定对于每小时仅尝试几个密码的慢速攻击无效。
• 帐户锁定对于针对大量用户名尝试使用一个密码的攻击无效。
• 如果攻击者使用用户名/密码组合列表并在前几次尝试中猜测正确，则帐户锁定无效。
• 强大的帐户（例如管理员帐户）通常会绕过锁定策略，但这些帐户是最容易受到攻击的帐户。某些系统仅在基于网络的登录中锁定管理员帐户。
• 即使您锁定了帐户，攻击也可能会继续，消耗宝贵的人力和计算机资源。
• 例如，考虑一个拍卖网站，多个竞标者正在争夺同一件物品。如果拍卖网站强制执行帐户锁定，则一个投标人可以在拍卖的最后一分钟锁定其他人的帐户，从而阻止他们提交任何中标投标。攻击者可以使用相同的技术来阻止关键的金融交易或电子邮件通信。

锁定帐户的 IP 地址也是一个坏主意

另一种解决方案是锁定多次登录失败的 IP 地址。此解决方案的问题在于，您可能会通过阻止 ISP 或大公司使用的代理服务器而无意中阻止大量用户。另一个问题是，许多工具利用代理列表，并且在继续下一个 IP 地址之前仅从每个 IP 地址发送一些请求。使用http://tools.rosinstrument.com/proxy/等网站上广泛使用的开放代理列表，攻击者可以轻松绕过任何 IP 阻止机制。由于大多数站点在一次密码失败后不会阻止，因此攻击者可以对每个代理进行两次或三次尝试。拥有 1,000 个代理列表的攻击者可以尝试 2,000 或 3,000 个密码而不会被阻止。然而，尽管这种方法存在缺陷，但遭受大量攻击的网站（尤其是成人网站）确实会选择阻止代理 IP 地址。

我的建议

• 不锁定帐户。相反，我们可能会考虑在连续错误尝试的登录/注册尝试中从服务器端添加有意的延迟。
• 根据登录尝试中的 IP 地址跟踪用户位置，这是 Google 和 Facebook 使用的常用技术。谷歌发送 OTP，而 Facebook 提供其他安全挑战，例如从照片中检测用户的朋友。
• 用于 Web 应用程序的 Google 重新验证码、用于 Android 的 SafetyNet 以及用于 iOS 的正确移动应用程序认证技术 - 在登录或注册请求中。
• 设备cookie
• 构建API调用监控系统来检测某个API端点的异常调用。

命题解释

故意延迟响应

密码验证延迟会显着减慢攻击者的速度，因为攻击的成功取决于时间。一个简单的解决方案是在检查密码时注入随机暂停。即使添加几秒钟的暂停也不会打扰大多数合法用户登录其帐户。

请注意，虽然添加延迟可能会减慢单线程攻击的速度，但如果攻击者同时发送多个身份验证请求，效果就会降低。

安全挑战

该技术可以描述为基于用户之前使用系统时执行的操作的自适应安全挑战。对于新用户，此技术可能会引发默认的安全挑战。

我们可能会考虑何时提出安全挑战？有几点我们可以做到。

• 当用户尝试从他之前不在附近的位置登录时。
• 登录尝试错误。

用户可能面临什么样的安全挑战？

• 如果用户设置了安全问题，我们可能会考虑询问用户答案。
• 对于 Whatsapp、Viber 等应用程序，我们可能会考虑从电话簿中随机获取一些联系人姓名，并要求输入他们的号码，反之亦然。
• 对于交易系统，我们可能会考虑询问用户最新的交易和付款情况。

API监控面板

构建API调用监控面板。

• 在 API 监控面板中查找可能表明暴力攻击或其他帐户滥用的情况。
• 从同一 IP 地址多次登录失败。
• 从同一 IP 地址使用多个用户名登录。
• 来自多个不同 IP 地址的单个帐户登录。
• 单次使用造成的过度使用和带宽消耗。
• 按字母顺序排列的用户名或密码尝试登录失败。
• 黑客常用的可疑密码登录，例如 ownsyou (ownzyou)、washhere (wazhere)、zealots、hacksyou 等。

对于内部系统帐户，我们可能会考虑仅允许从某些 IP 地址登录。如果需要锁定帐户，不要完全锁定帐户，而是将其置于功能有限的锁定模式。

这里有一些不错的读物。

• https://en.wikipedia.org/wiki/Brute-force_attack#Reverse_brute-force_attack
• https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
• http://www.computerweekly.com/answer/Techniques-for-preventing-a-brute-force-login-attack