防止网站上的暴力登录

何以笙箫默 2024-07-17 15:59:39

我认为给定帐户的数据库持久锁定期（1-5 分钟）是处理此问题的唯一方法。数据库中的每个userid 都包含一个timeOfLastFailedLogin 和numberOfFailedAttempts。当 numbeOfFailedAttempts > 时 X 您锁定了几分钟。

这意味着您将锁定相关userid一段时间，但不是永久锁定。它还意味着您要为每次登录尝试更新数据库（当然，除非它被锁定），这可能会导致其他问题。

亚洲至少有一个国家/地区经过 NAT，因此 IP 不能用于任何用途。

回复收藏 0 原文

孤星 2024-07-17 15:59:39

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

强制使用安全密码

优点：将防止字典攻击
缺点：也会阻止流行，因为大多数用户无法记住复杂的密码，即使你向他们解释如何轻松记住它们。例如，通过记住句子：“我在商场用 5 美分买了 1 个苹果”会导致“Ib1Af5CitM”。

多次尝试后锁定

优点：会减慢自动化测试的速度
缺点：很容易为第三方锁定用户
缺点：让他们持久地使用数据库可能会导致 Twitter 或类似服务等大型服务产生大量写入进程。

验证码

优点：它们会阻止自动化测试
缺点：它们会消耗计算时间
缺点：会“减慢”用户体验
巨大缺点：它们不是无障碍的。

简单的知识检查

优点：会妨碍自动化测试
缺点：“简单”是仁者见仁智者见智。
缺点：会“减慢”用户体验

不同的登录名和用户名

优点：这是一项技术，几乎看不到，但在我看来，这是一个很好的开始，可以防止暴力攻击。
缺点：取决于用户对两个名称的选择。

使用整个句子作为密码

专业版：增加可搜索空间的大小。
专业版：对于大多数用户来说更容易记住。
缺点：取决于用户的选择。

正如您所看到的，“好的”解决方案都取决于用户的选择，这再次暴露了用户是链条中最薄弱的元素。

还有其他建议吗？

回复收藏 0 原文

薄荷港 2024-07-17 15:59:39

你可以做谷歌所做的事情。经过一定次数的尝试后，他们会显示验证码。经过几次验证码后，您将它们锁定几分钟。

回复收藏 0 原文

烧了回忆取暖 2024-07-17 15:59:39

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

在 X 次失败的密码尝试后锁定
根据用户名计算失败的尝试
可以选择使用验证码（例如，尝试 1-2 是正常的，尝试 3-5 是验证码的，进一步的尝试将被阻止 15 次）分钟）。
（可选）向帐户所有者发送电子邮件以删除阻止

我想指出的是，您应该非常小心地强制使用“强”密码，因为这通常意味着它们只会写在便利贴上在桌子上/连接到显示器上。此外，某些密码策略会导致密码更可预测。例如：

如果密码不能是任何以前使用过的密码并且必须包含数字，那么它很可能是任何常见密码，后面带有序列号。如果您必须每 6 个月更改一次密码，并且某人已经在那里工作了两年，那么他们的密码很可能类似于 password4。

假设您对其进行更多限制：必须至少为 8 个字符，不能包含任何连续字母，必须包含字母、数字和特殊字符（这是许多人认为安全的真正密码策略）。试图闯入约翰·昆西·史密斯的帐户？知道他出生3月6日吗？他的密码很可能类似于 jqs0306!（或者jqs0306~）。

现在，我并不是说让您的用户拥有密码 password 也是一个好主意，只是不要自欺欺人地认为您的强制“安全”密码是安全的。

回复收藏 0 原文

栖竹 2024-07-17 15:59:39

详细说明一下最佳实践：

krosenvold 所说的：在用户表中记录 num_failed_logins 和 last_failed_time（用户被挂起时除外），一旦登录失败次数达到阈值，就将用户挂起 30 秒或一分钟。这是最佳实践。

该方法有效地消除了单帐户暴力破解和字典攻击。但是，它并不能阻止攻击者在用户名之间切换 - 即。保持密码固定并尝试使用大量用户名。如果您的网站有足够的用户，这种攻击可以持续很长时间，直到耗尽未暂停的帐户来攻击。希望他会从单个 IP 运行此攻击（不过不太可能，因为僵尸网络如今确实成为了交易工具），这样您就可以检测到这一点并阻止该 IP，但是如果他正在分发攻击...好吧，这是另一个问题（我刚刚在这里发布，所以如果您还没有，请检查一下）。

关于最初的想法需要记住的另一件事是，即使帐户受到攻击和暂停，您当然仍然应该尝试让合法用户通过 - 也就是说，如果您可以区分真实用户和机器人。

你可以，至少有两种方式。

如果用户有持久登录（“记住我”）cookie，就让他通过。
当您显示“抱歉，您的帐户由于大量登录尝试失败而被暂停”消息时，请添加一个链接，其中显示“安全备份登录 - 仅限人类（机器人：没有说谎）”。开个玩笑，当他们点击该链接时，向他们提供经过 reCAPTCHA 验证的登录表单，该表单可以绕过帐户的暂停状态。这样，如果他们是人类并且知道正确的登录名+密码（并且能够读取验证码），他们将永远不会受到延迟的困扰，并且您的网站将不会受到快速攻击。

唯一的缺点：有些人（例如视力障碍者）无法阅读验证码，并且他们可能仍然会受到烦人的机器人产生的延迟的影响如果他们没有使用验证码自动登录功能。

什么不是缺点：自动登录 cookie 没有内置类似的安全措施。您可能会问，为什么这不是一个缺点？因为只要您明智地实现它，登录 cookie 中的安全令牌（相当于密码）的位数是您密码的两倍（哎呀，十倍！），所以暴力破解它是实际上不是问题。但如果你真的很偏执，也可以在自动登录功能上设置一秒的延迟，只是为了更好的措施。

To elaborate on the best practice:

What krosenvold said: log num_failed_logins and last_failed_time in the user table (except when the user is suspended), and once the number of failed logins reach a treshold, you suspend the user for 30 seconds or a minute. It is the best practice.

That method effectively eliminates single-account brute-force and dictionary attacks. However, it does not prevent an attacker from switching between user names - ie. keeping the password fixed and trying it with a large number of usernames. If your site has enough users, that kind of attack can be kept going for a long time before it runs out of unsuspended accounts to hit. Hopefully, he will be running this attack from a single IP (not likely though, as botnets are really becoming the tool of the trade these days) so you can detect that and block the IP, but if he is distributing the attack... well, that's another question (that I just posted here, so please check it out if you haven't).

One additional thing to remember about the original idea is that you should of course still try to let the legitimate user through, even while the account is being attacked and suspended -- that is, IF you can tell the real user and the bot apart.

And you CAN, in at least two ways.

If the user has a persistent login ("remember me") cookie, just let him pass through.
When you display the "I'm sorry, your account is suspended due to a large number of unsuccessful login attempts" message, include a link that says "secure backup login - HUMANS ONLY (bots: no lying)". Joke aside, when they click that link, give them a reCAPTCHA-authenticated login form that bypasses the account's suspend status. That way, IF they are human AND know the correct login+password (and are able to read CAPTCHAs), they will never be bothered by delays, and your site will be impervious to rapid-fire attacks.

Only drawback: some people (such as the vision-impaired) cannot read CAPTCHAs, and they MAY still be affected by annoying bot-produced delays IF they're not using the autologin feature.

What ISN'T a drawback: that the autologin cookie doesn't have a similar security measure built-in. Why isn't this a drawback, you ask? Because as long as you've implemented it wisely, the secure token (the password equivalent) in your login cookie is twice as many bits (heck, make that ten times as many bits!) as your password, so brute-forcing it is effectively a non-issue. But if you're really paranoid, set up a one-second delay on the autologin feature as well, just for good measure.

回复收藏 0 原文

哽咽笑 2024-07-17 15:59:39

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

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

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

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

最后，基于 IP 做出一些决定是可以接受的...如果您看到来自一个 IP 的单次尝试，那么这可能是一个无心的错误，而天知道有多少个系统，您可能需要采取其他预防措施或通知最终用户阴暗活动。

其真正的大型代理联盟可以保留大量 IP 地址供其使用，但大多数网站确实会尽合理努力在一段时间内维护您的源地址以用于遗留目的，因为某些网站有将 cookie 数据与 IP 绑定的习惯。

回复收藏 0 原文

江城子 2024-07-17 15:59:39

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

我们需要防止暴力攻击，使攻击者无法获取网站登录的用户名和密码。在许多系统中，它们有一些开放式 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 地址登录。如果需要锁定帐户，不要完全锁定帐户，而是将其置于功能有限的锁定模式。

这里有一些不错的读物。

This is an old post. However, I thought of putting my findings here so that it might help any future developer.

We need to prevent brute-force attack so that the attacker can not harvest the user name and password of a website login. In many systems, they have some open ended urls which does not require an authentication token or API key for authorization. Most of these APIs are critical. For example; Signup, Login and Forget Password APIs are often open (i.e. does not require a validation of the authentication token). We need to ensure that the services are not abused. As stated earlier, I am just putting my findings here while studying about how we can prevent a brute force attack efficiently.

Most of the common prevention techniques are already discussed in this post. I would like to add my concerns regarding account locking and IP address locking. I think locking accounts is a bad idea as a prevention technique. I am putting some points here to support my cause.

Account locking is bad

An attacker can cause a denial of service (DoS) by locking out large numbers of accounts.
Because you cannot lock out an account that does not exist, only valid account names will lock. An attacker could use this fact to harvest usernames from the site, depending on the error responses.
An attacker can cause a diversion by locking out many accounts and flooding the help desk with support calls.
An attacker can continuously lock out the same account, even seconds after an administrator unlocks it, effectively disabling the account.
Account lockout is ineffective against slow attacks that try only a few passwords every hour.
Account lockout is ineffective against attacks that try one password against a large list of usernames.
Account lockout is ineffective if the attacker is using a username/password combo list and guesses correctly on the first couple of attempts.
Powerful accounts such as administrator accounts often bypass lockout policy, but these are the most desirable accounts to attack. Some systems lock out administrator accounts only on network-based logins.
Even once you lock out an account, the attack may continue, consuming valuable human and computer resources.
Consider, for example, an auction site on which several bidders are fighting over the same item. If the auction web site enforced account lockouts, one bidder could simply lock the others' accounts in the last minute of the auction, preventing them from submitting any winning bids. An attacker could use the same technique to block critical financial transactions or e-mail communications.

IP address locking for a account is a bad idea too

Another solution is to lock out an IP address with multiple failed logins. The problem with this solution is that you could inadvertently block large groups of users by blocking a proxy server used by an ISP or large company. Another problem is that many tools utilize proxy lists and send only a few requests from each IP address before moving on to the next. Using widely available open proxy lists at websites such as http://tools.rosinstrument.com/proxy/, an attacker could easily circumvent any IP blocking mechanism. Because most sites do not block after just one failed password, an attacker can use two or three attempts per proxy. An attacker with a list of 1,000 proxies can attempt 2,000 or 3,000 passwords without being blocked. Nevertheless, despite this method's weaknesses, websites that experience high numbers of attacks, adult Web sites in particular, do choose to block proxy IP addresses.

My proposition

Not locking the account. Instead, we might consider adding intentional delay from server side in the login/signup attempts for consecutive wrong attempts.
Tracking user location based on IP address in login attempts, which is a common technique used by Google and Facebook. Google sends a OTP while Facebook provides other security challenges like detecting user's friends from the photos.
Google re-captcha for web application, SafetyNet for Android and proper mobile application attestation technique for iOS - in login or signup requests.
Device cookie
Building a API call monitoring system to detect unusual calls for a certain API endpoint.

Propositions Explained

Intentional delay in response

The password authentication delay significantly slows down the attacker, since the success of the attack is dependent on time. An easy solution is to inject random pauses when checking a password. Adding even a few seconds' pause will not bother most legitimate users as they log in to their accounts.

Note that although adding a delay could slow a single-threaded attack, it is less effective if the attacker sends multiple simultaneous authentication requests.

Security challenges

This technique can be described as adaptive security challenges based on the actions performed by the user in using the system earlier. In case of a new user, this technique might throw default security challenges.

We might consider putting in when we will throw security challenges? There are several points where we can.

When user is trying to login from a location where he was not located nearby before.
Wrong attempts on login.

What kind of security challenge user might face?

If user sets up the security questions, we might consider asking the user answers of those.
For the applications like Whatsapp, Viber etc. we might consider taking some random contact names from phonebook and ask to put the numbers of them or vice versa.
For transactional systems, we might consider asking the user about latest transactions and payments.

API monitoring panel

To build a monitoring panel for API calls.

Look for the conditions that could indicate a brute-force attack or other account abuse in the API monitoring panel.
Many failed logins from the same IP address.
Logins with multiple usernames from the same IP address.
Logins for a single account coming from many different IP addresses.
Excessive usage and bandwidth consumption from a single use.
Failed login attempts from alphabetically sequential usernames or passwords.
Logins with suspicious passwords hackers commonly use, such as ownsyou (ownzyou), washere (wazhere), zealots, hacksyou etc.

For internal system accounts we might consider allowing login only from certain IP addresses. If the account locking needs to be in place, instead of completely locking out an account, place it in a lockdown mode with limited capabilities.

Here are some good reads.

回复收藏 0 原文

昵称有卵用 2024-07-17 15:59:39

像大多数银行一样，在 X 次登录失败后锁定用户名/帐户。但我不会像银行那么严格，你必须打电话来解锁你的账户。我只会暂时锁定 1-5 分钟。当然，除非 Web 应用程序像银行一样对数据敏感。 :)

回复收藏 0 原文

小镇女孩 2024-07-17 15:59:39

我认为您应该重新登录用户名。这是唯一的常数（其他任何东西都可以被欺骗）。是的，它可以将合法用户锁定一天。但如果我必须在被黑帐户和关闭帐户（一天）之间做出选择，我肯定会选择锁。

顺便说一句，在第三次尝试失败后（在一定时间内），您可以锁定帐户并向所有者发送释放邮件。该邮件包含用于解锁帐户的链接。这对用户来说是一个轻微的负担，但是破解者被阻止了。即使邮件帐户被黑客入侵，您也可以设置每天的解锁次数限制。

回复收藏 0 原文

穿透光 2024-07-17 15:59:39

我在线登录的许多在线留言板都会让我尝试登录帐户 5 次，在这 5 次尝试之后，帐户将被锁定一小时或十五分钟。它可能不太漂亮，但这肯定会减慢对一个帐户的字典攻击。现在没有什么可以阻止同时针对多个帐户的字典攻击。即尝试 5 次，切换到不同的帐户，再尝试 5 次，然后返回。但它确实会减慢攻击速度。

抵御字典攻击的最佳防御方法是确保密码不在字典中！基本上设置某种密码策略，根据字母检查字典，并要求密码中包含数字或符号。这可能是针对字典攻击的最佳防御。

回复收藏 0 原文

撩动你心 2024-07-17 15:59:39

您可以添加某种形式的验证码测试。但请注意，它们中的大多数都会使眼睛或听力受损的人更难以接触。验证码的一种有趣形式是提出问题，

2 和 2 的和是多少？

如果您记录了上次登录失败的情况，如果验证码足够旧，则可以跳过验证码。仅当最后一次失败是在过去 10 分钟内时才进行验证码测试。

回复收藏 0 原文

似梦非梦 2024-07-17 15:59:39

对于 .NET 环境

动态 IP 限制

IIS 的动态 IP 限制扩展为 IT 专业人员和托管商提供了可配置的该模块可暂时阻止遵循可能有助于此类攻击之一的模式的 HTTP 客户端的 Internet 协议 (IP) 地址，从而帮助减轻或阻止拒绝服务攻击或通过暴力破解密码。可以配置该模块，以便可以在 Web 服务器或网站级别完成分析和阻止。

通过动态阻止来自恶意 IP 地址的请求来减少拒绝服务攻击的可能性

IIS 的动态 IP 限制允许您通过检查请求的源 IP 并识别请求的源 IP 来降低 Web 服务器遭受拒绝服务攻击的可能性可能发出攻击信号的模式。当检测到攻击模式时，该模块会将违规 IP 放入临时拒绝列表中，并在预定时间内避免响应请求。

最大限度地减少 Web 服务器密码被暴力破解的可能性

IIS 的动态 IP 限制能够检测表明试图对 Web 服务器密码进行解码的请求模式。该模块会将违规 IP 放入服务器列表中，在预定时间内拒绝访问这些服务器。在针对 Active Directory 服务 (ADS) 进行身份验证的情况下，模块能够通过避免向 ADS 发出身份验证质询来维护 Web 服务器的可用性。

功能

无缝集成到 IIS 7.0 管理器。
根据以下任一条件动态阻止来自 IP 地址的请求：
- 并发请求数。
- 一段时间内的请求数量。
支持允许绕过动态 IP 限制过滤的 IP 列表。
可以在网站或 Web 服务器级别配置请求阻止。
可配置的拒绝操作允许 IT 管理员指定将返回给客户端的响应。该模块支持返回状态代码 403、404 或关闭连接。
支持 IPv6 地址。
支持代理或防火墙后面的 Web 服务器可能会修改客户端 IP 地址。
支持代理

http://www.iis.net/download/DynamicIPRestrictions

For .NET Environment

Dynamic IP Restrictions

The Dynamic IP Restrictions Extension for IIS provides IT Professionals and Hosters a configurable module that helps mitigate or block Denial of Service Attacks or cracking of passwords through Brute-force by temporarily blocking Internet Protocol (IP) addresses of HTTP clients who follow a pattern that could be conducive to one of such attacks. This module can be configured such that the analysis and blocking could be done at the Web Server or the Web Site level.

Reduce the chances of a Denial of Service attack by dynamically blocking requests from malicious IP addresses

Dynamic IP Restrictions for IIS allows you to reduce the probabilities of your Web Server being subject to a Denial of Service attack by inspecting the source IP of the requests and identifying patterns that could signal an attack. When an attack pattern is detected, the module will place the offending IP in a temporary deny list and will avoid responding to the requests for a predetermined amount of time.

Minimize the possibilities of Brute-force-cracking of the passwords of your Web Server

Dynamic IP Restrictions for IIS is able to detect requests patterns that indicate the passwords of the Web Server are attempted to be decoded. The module will place the offending IP on a list of servers that are denied access for a predetermined amount of time. In situations where the authentication is done against an Active Directory Services (ADS) the module is able to maintain the availability of the Web Server by avoiding having to issue authentication challenges to ADS.

Features

Seamless integration into IIS 7.0 Manager.
Dynamically blocking of requests from IP address based on either of the following criteria:
- The number of concurrent requests.
- The number of requests over a period of time.
Support for list of IPs that are allowed to bypass Dynamic IP Restriction filtering.
Blocking of requests can be configurable at the Web Site or Web Server level.
Configurable deny actions allows IT Administrators to specify what response would be returned to the client. The module support return status codes 403, 404 or closing the connection.
Support for IPv6 addresses.
Support for web servers behind a proxy or firewall that may modify the client IP address.

http://www.iis.net/download/DynamicIPRestrictions

回复收藏 0 原文

旧人九事 2024-07-17 15:59:39

旧帖子，但让我在 2016 年底发布我的内容。希望它仍然能有所帮助。

这是一种简单的方法，但我认为它对于防止登录攻击很有效。至少我总是在我的每个网站上使用它。我们不需要验证码或任何其他第三方插件。

当用户第一次登录时。我们创建一个会话，例如

$_SESSION['loginFail'] = 10; // any number you prefer

如果登录成功，那么我们将销毁它并让用户登录。

unset($_SESSION['loginFail']); // put it after create login session

但是，如果用户失败，就像我们通常向他们发送错误消息一样，同时我们将会话减少 1：

$_SESSION['loginFail']-- ; // reduce 1 for every error

如果用户失败 10 次，那么我们会将他们引导到其他网站或任何网页。

if (!isset($_SESSION['loginFail'])) { 

     if ($_SESSION['login_fail'] < 1 ) {

     header('Location:https://google.com/'); // or any web page

     exit();

}
}

这样，用户就无法再打开或进入我们的登录页面，因为它已重定向到其他网站。

用户必须关闭浏览器（以销毁我们创建的会话loginFail），“再次”打开它才能“再次”看到我们的登录页面。

有帮助吗？

Old post but let me post what I have in this the end 2016. Hope it still could help.

It's a simple way but I think it's powerful to prevent login attack. At least I always use it on every web of mine. We don't need CAPTCHA or any other third party plugins.

When user login for the first time. We create a session like

$_SESSION['loginFail'] = 10; // any number you prefer

If login success, then we will destroy it and let user login.

unset($_SESSION['loginFail']); // put it after create login session

But if user fail, as we usually sent error message to them, at the same time we reduce the session by 1 :

$_SESSION['loginFail']-- ; // reduce 1 for every error

and if user fail 10 times, then we will direct them to other website or any web pages.

if (!isset($_SESSION['loginFail'])) { 

     if ($_SESSION['login_fail'] < 1 ) {

     header('Location:https://google.com/'); // or any web page

     exit();

}
}

By this way, user can not open or go to our login page anymore, cause it has redirected to other website.

Users has to close the browser ( to destroy session loginFail that we created), open it 'again' to see our login page 'again'.

Is it helpful?

回复收藏 0 原文

染柒℉ 2024-07-17 15:59:39

为了防止暴力破解，需要考虑几个方面。考虑给定的方面。

密码强度
强制用户创建密码以满足特定条件
- 密码应至少包含一个大写字母、小写字母、数字和符号（特殊字符）。
- 密码应具有根据您的标准定义的最小长度。
- 密码不应包含用户名或公共用户 ID。
通过创建最小密码强度策略，暴力破解将需要时间来猜测密码。同时，您的应用程序可以识别此类内容并迁移它。
验证码
您可以使用reCaptcha来防止机器人脚本具有暴力破解功能。在 Web 应用程序中实现 reCaptcha 相当容易。您可以使用 Google reCaptcha。它有多种版本的 reCaptcha，例如 Invisible reCaptcha 和 reCaptcha v3。
动态IP过滤策略
您可以动态识别请求模式，并在该模式与攻击向量标准匹配时阻止 IP。过滤登录尝试的最流行的技术之一是限制。阅读使用 php 的节流技术了解更多信息。良好的动态 IP 过滤策略还可以保护您免受 DoS 和 DDos 等攻击。但是，它无助于防止 DRDos。
CSRF防范机制
csrf 被称为跨站点请求伪造。意味着其他站点正在您的 PHP 脚本/控制器上提交表单。 Laravel 有一个非常明确的方法来防止 csrf。但是，如果您不使用这样的框架，则必须设计自己的基于JWT的csrf预防机制。如果您的网站受 CSRF 保护，那么就没有机会对您网站上的任何表单发起暴力破解。就像你关闭的大门一样。

回复收藏 0 原文

防止网站上的暴力登录

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（14）

强制使用安全密码

多次尝试后锁定

验证码

简单的知识检查

不同的登录名和用户名

使用整个句子作为密码

Forcing secure passwords

Lockouts after several attempts

Captchas

Simple knowledge checks

Different login and username

Use whole sentences as passwords

详细说明一下最佳实践：

To elaborate on the best practice:

动态 IP 限制

通过动态阻止来自恶意 IP 地址的请求来减少拒绝服务攻击的可能性

最大限度地减少 Web 服务器密码被暴力破解的可能性

功能

Dynamic IP Restrictions

Reduce the chances of a Denial of Service attack by dynamically blocking requests from malicious IP addresses

Minimize the possibilities of Brute-force-cracking of the passwords of your Web Server

Features

关于作者

相关话题

热门标签

推荐作者

花开柳相依

zyhello

故友

对风讲故事

Oo萌小芽oO

梦明

友情链接

防止网站上的暴力登录

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（14）

强制使用安全密码

多次尝试后锁定

验证码

简单的知识检查

不同的登录名和用户名

使用整个句子作为密码

Forcing secure passwords

Lockouts after several attempts

Captchas

Simple knowledge checks

Different login and username

Use whole sentences as passwords

详细说明一下最佳实践：

To elaborate on the best practice:

通过动态阻止来自恶意 IP 地址的请求来减少拒绝服务攻击的可能性

最大限度地减少 Web 服务器密码被暴力破解的可能性

功能

Reduce the chances of a Denial of Service attack by dynamically blocking requests from malicious IP addresses

Minimize the possibilities of Brute-force-cracking of the passwords of your Web Server

Features

关于作者

相关话题

热门标签

推荐作者

友情链接

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。