防止暴力登录尝试 [英] Preventing brute-force login attempts

问题描述

我想防止黑客侵入我用户的帐户.人们常说:

I want to prevent hackers to break into my users' accounts. It is often said that:

锁定帐户的最佳方法在x 次登录尝试失败后暂时.

The best approach it to lockout an account temporarily after x failed login attempts.

我明白这一点，这似乎是个好主意.例如，使用 IP 是一个非常糟糕的主意 - 亚洲至少有一个完整的国家/地区进行了 NAT，因此 IP 不能用于任何事情.

I understand this and it seems like a good idea. Using IP for example is a very bad idea - there is at least one whole country NAT'ed in Asia, so IP's cannot be used for anything.

不幸的是，锁定是一个真正的问题.它会显示该帐户是否存在的信息.我们不想这样做，这就是为什么我们总是写电子邮件和密码不匹配"之类的.

Unfortunately there comes a real issue with lockout. It reveals the info whether the account exists or not. We don't want to do this, that is why we always write "email and password do not match" or something like this.

我无法锁定不存在的帐户 - 否则我将不得不存储有关登录尝试失败的不存在帐户的信息.然后，僵尸网络可能会导致我的数据库中出现数十亿条记录 - 不存在的帐户.

I can't lockout non-existing accounts - otherwise I would have to store info about non-existing accounts with failed login attempts. A botnet then could lead to billions of records in my database - of nonexisting accounts.

处理这个问题的可能性有哪些?防止暴力攻击，同时不泄露账户是否存在的信息?

What are the possibilities to handle this issue? To prevent brute force attacks and at the same time do not reveal the information whether an account does exist or not?

推荐答案

我的团队刚刚解决了这个完全相同的问题，考虑到我们的解决方案最终是多么简单，要实现这一目标还有很长的路要走.

My team just tackled this exact same problem and, given how ultimately simple our solution was, it was a long road to get there.

这里需要考虑的因素太多了，您已经涵盖了其中的大部分.对我们来说幸运的是，所有 DDoS/DoS 问题都由我们的 IaaS 提供商处理，因此我们不必担心任何这些.我的第一个建议是，如果您不使用我建议您使用的此类服务，那么正确实施这些内容并非易事.

There are so many factors that need to be taken into consideration here, most of which you have already covered. Luckily for us, all the DDoS/DoS stuff is handled by our IaaS provider so we didn't have to worry about any of that. My first recommendation would be if you aren't using such a service I recommend that you do, implementing this stuff correctly is not trivial.

为我们处理所有基础设施，这使我们能够专注于应用程序本身.我们的第一直觉是查看锁定方法，但是，经过一些讨论，甚至只是简单介绍了它的工作原理、实施等.我们发现其中有很多潜在的陷阱(您提到的 IP 就是其中之一)我们决定放弃它.

With all the infrastructure being handled for us, this allowed us to focus on the application itself. Our first instinct was to look at a lockout approach, however, after some discussions and even just a simple walk through of how it would work, implementation etc. we found so many potential pitfalls in it (the IP one you mentioned being one) we decided to abandon it.

然后我们问了一个问题我们到底想在这里做什么?"，最终我们希望防止两个机器人和机器人的蛮力攻击.黑客，但同时为真正的用户保持良好的用户体验......当一分钱掉下来时，我们实际上无法相信它是多么简单 - 使用 验证码.

We then asked the question "what exactly is it we are trying to do here?", ultimately we want to prevent brute force attacks by both bots & hackers but at the same time maintain a good UX for genuine users....when the penny dropped we actually couldn't believe how simple it was - use a Captcha.

实现非常简单，在 X 次尝试失败后，我们将验证码添加到表单中，并强制用户与他们的凭据一起验证这一点.我们认为这为我们提供了安全性和安全性之间的最佳平衡.可用性，因为:

The implementation is pretty simple, after X failed attempts we add a Captcha to the form and force the user to verify this along with their credentials. We felt this gave us the best balance between security & usability because:

• 我们不会通过锁定真正的用户并让他们等待更长时间来访问我们的服务来进一步挫败他们
• 我们很可能会阻止大多数自动化/机器人暴力尝试，例如字典攻击.
• 我们通过限制登录请求进一步降低了 DoS 的可能性
• 我们会降低恶意用户的速度，让他们认为真的值得花时间吗?"

• We don't further frustrate genuine users by locking them out and making them wait even longer to access our service
• We will most likely prevent the majority automated/bot brute-force attempts e.g. dictionary attacks.
• We further reduce the chances of DoS by throttling login requests
• We slow down malicious users to the point where they think "is it really worth the time?"

这篇关于防止暴力登录尝试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！