在一段时间内阻止多次登录不成功的请求 [英] Block request for multiple unsuccessful logins for a period of time

查看:21
本文介绍了在一段时间内阻止多次登录不成功的请求的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个网站,我想阻止来自 BOTs 的请求并尝试暴力登录我的网站.

I have a web site and I want to block request from BOTs and attempt brute force login to my web site.

现在我使用 Session 来存储登录尝试并在 3 次登录失败后显示验证码,但有问题.如果用户关闭浏览器,Session 将被删除.

Now I'm using Session for storing login attempt and show captcha after 3 unsuccessful login but there is a problem.Session will be removed, if user closes the browser.

我应该考虑什么样的解决方案来防止BOTs和暴力登录?我应该存储用户系统或浏览器的哪些属性来管理他/她的下次登录?

What kind of solution I should consider to prevent BOTs and brute force login? What property of user system or browser I should store to manage his/her next login?

编辑 1)

我不使用 ASP.NET 会员资格提供程序.我正在使用自己的身份验证和授权类

I don't use ASP.NET Membership provider. I'm using my own authentication and authorization classes

推荐答案

您不能使用 session,因为它需要客户端为您存储 cookie,而攻击者不会帮助您.您将需要一些全局状态.

You can't use session, as it requires the client to store a cookie for you, and an attacker is not going to help you out. You will need some global state.

您无需费心跟踪 IP 地址,因为坏人只会使用匿名代理.

You needn't bother tracking IP addresses, as a bad guy will just use an Anonymyzing Proxy.

不要使用帐户锁定,除非您必须(PCI 要求),因为这只会让攻击者拒绝您的用户.

Don't use account lock-out unless you have to (PCI requirement), as this just lets the attacker DoS your users.

您还希望通过让服务器做太多工作来避免 DoS 攻击.

You also want to avoid DoS-ing yourself by making your server do too much work.

这有效:

在认证失败时,将用户名和计数一起存储在全局状态中.如果使用该用户名进行更多不成功的身份验证,则同步 count++.我为此使用 redis.

Upon unsuccessful authentication, store username in global state, along with count. Synchronized count++ if more unsuccessful authentications with that username. I use redis for this.

如果count >= threshold,则在继续之前要求解决CAPTCHA值.在登录屏幕上显示验证码.

If count >= threshold, then demand solved CAPTCHA value before proceeding. Show CAPTCHA on login screen.

成功身份验证后,清除全局状态中存储的用户名.给用户受信任的用户代理"HMAC cookie,这样他们就不必该 UA 上该用户名的验证码.

Upon successful authentication, clear stored username in global state. Give user "trusted user agent" HMAC'd cookie, so they don't have to CAPTCHA in the future for that username on that UA.

您可以对密码执行相同的操作,但阈值可能更高.

如果您不喜欢 CAPTCHA,则需要工作量证明,例如让客户计算并提交一个非常大的数的质因数.

If you don't like CAPTCHA then demand Proof of Work, for example by making the client calculate and submit the prime factors of a very large number.

在此过程中,请确保使用 bcrypt 对密码进行哈希处理,并且成本因素足够高,需要 >= 250 毫秒来对密码进行哈希处理.这会减慢您的服务器速度,但也会减慢攻击者的速度.避免散列,除非他们通过了验证码(如果需要).

While you're at it, make sure you are using bcrypt to hash your passwords, and that the cost factor is high enough that it takes >= 250ms to hash a password. This slows down your server but also slows down an attacker. Avoid hashing unless they pass the CAPTCHA (if required).

鼓励用户使用长、复杂、难忘?密码,因此它们更难被暴力破解.

Encourage users to use long, complicated, memorable? passwords, so that they're harder to brute-force.

这篇关于在一段时间内阻止多次登录不成功的请求的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆