针对 Web 应用程序的密码列表攻击的最佳实践
我想防止机器人攻击弱密码保护的帐户。 （例如，这发生在 eBay 和其他大型网站上）
所以我将使用 ip、尝试次数和上次尝试的时间戳设置一个（mem-）缓存值（memcache-fall-out）。
但是如果机器人尝试仅使用一个密码开设任何帐户呢？ 例如，机器人尝试使用密码“password123”的所有 500.000 个用户帐户。 也许10个会开放。
所以我的尝试是用 attempts 缓存 ip 并将 max-tries 设置为 ~50。 成功登录后我会删除它。 因此，好机器人每 49 次尝试重置锁就会使用有效帐户登录。
有什么办法可以做到正确吗？ 大平台对此有何举措？ 我该怎么做才能防止白痴通过重试 50 次来阻止代理上的所有用户？
如果没有最佳实践——这是否意味着任何平台都可以暴力破解？ 至少提示一下计数器何时重置？
i'd like to prevent bots from hacking weak password-protected accounts. (e.g. this happend to ebay and other big sites)
So i'll set a (mem-) cached value with the ip, amount of tries and timestamp of last try (memcache-fall-out).
But what about bots trying to open any account with just one password. For example, the bot tries all 500.000 Useraccounts with the password "password123". Maybe 10 will open.
So my attempt was to just cache the ip with tries and set max-tries to ~50. The i would delete it after a successful login. So the good-bot would just login with a valid account every 49 tries to reset the lock.
Is there any way to do it right?
What do big platforms do about this?
What can i do to prevent idiots from blocking all users on a proxy with retrying 50 times?
If there is no best practice - does this mean any platform is brute-forceable? At least with a hint on when counters are resetted?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我认为您可以将您的解决方案与验证码混合使用：
I think you can mix your solution with captchas:
有些网站可能会尝试两到三次，然后才开始要求您输入验证码以及用户名/密码。 成功登录后，验证码就会消失。
Some sites give you maybe two or three tries before they start making you enter a captcha along with your username/password. The captcha goes away once you successfully log in.
前几天有一篇关于Coding Horror的比较好的文章。
There was a relatively good article on Coding Horror a few days ago.
虽然代码重点关注 Django，但对于最佳实践方法有一些非常好的讨论 Simon Willison 的博客。 他使用 memcached 来跟踪 IP 和登录失败。
While the code is focused on Django there is some really good discussion on the best practice methods on Simon Willison’s blog. He uses memcached to track IPs and login failures.
当用户将密码设置为确保他们没有使用容易被暴力破解的密码。
编辑：需要明确的是，这不应被视为您要解决的问题的完整解决方案，但应将其与其他一些答案结合起来考虑。
You could use a password strength checker when a user sets their password to make sure they're not using an easily brute-forced password.
EDIT: Just to be clear, this shouldn't be seen as a complete solution to the problem you're trying to solve, but it should be considered in conjunction with some of the other answers.
您永远无法阻止一群机器人从许多不同的 IP 地址尝试此操作。
来自同一 IP 地址：我想说，如果您看到“可疑”行为的示例（无效的用户名，或多个有效帐户尝试不正确的登录尝试），只需阻止登录几秒钟即可。 如果是合法用户，他们不会介意等待几秒钟。 如果是机器人，这会减慢它们的速度，达到不切实际的程度。 如果您继续看到该 IP 地址的行为，只需阻止它们即可，但为合法用户留下带外门（拨打电话 #x，或向此地址发送电子邮件）。
You're never going to be able to prevent a group of bots from trying this from lots of different IP addresses.
From the same IP address: I would say if you see an example of "suspicious" behavior (invalid username, or several valid accounts with incorrect login attempts), just block the login for a few seconds. If it's a legitimate user, they won't mind waiting a few seconds. If it's a bot this will slow them down to the point of being impractical. If you continue to see the behavior from the IP address, just block them -- but leave an out-of-band door for legitimate users (call phone #x, or email this address).
请注意：IP 地址可以在数千甚至数百万用户之间共享！ 例如，由于 AOL 的网络架构，大多数/所有 AOL 用户显示为非常小的 IP 地址集。 大多数 ISP 将其庞大的用户群映射到一小组公共 IP 地址。
您不能假设某个 IP 地址仅属于单个用户。
您不能假设单个用户仅使用单个 IP 地址。
PLEASE NOTE: IP addresses can be shared among THOUSANDS or even MILLIONS of users!!! For example, most/all AOL users appear as a very small set of IP addresses due to AOL's network architecture. Most ISPs map their large user bases to a small set of public IP addresses.
You cannot assume that an IP address belongs to only a single user.
You cannot assume that a single user will be using only a single IP address.
检查以下问题，讨论针对分布式暴力和字典攻击的最佳实践：
什么最好的分布式暴力对抗措施是什么？
Check the following question discussing best practices against distibuted brute force and dictionary attacks:
What is the best Distributed Brute Force countermeasure?