The background is tested for several dozen logins every day, which one to do first: change the address, limit traffic, or two-factor authentication?

When the back-end is attempted to be logged in several times a day, the order of changing the login address, implementing rate limiting, and two-factor authentication should be as follows: first use the changed entry address and rate limiting to reduce noise, so that the logs can reflect the real risk; then use the form captcha to intercept automated submissions; finally, tighten the issuance and use of login tickets. The three steps have different functions and cannot be substituted for each other. Changing the entry address does not mean that the authentication reinforcement has been completed.

Why do attacks concentrate on the login entry

The public protection guidelines give a scale of the amount: On average, each WordPress site will encounter 43 login brute force attempts per day, most of this traffic comes from brute force dictionaries and automated scripts, not from manual attempts one by one. The scripts run along a fixed entry path, with a very low cost of attack, so the login entry is the position where all sites are repeatedly pushed through. Understanding this, the reinforcement sequence is clear: first make the script not find the door, then prevent the machine from automatically submitting, and finally ensure that even if the credentials are guessed, it is not possible to obtain a usable login state.

Step 1: Reduce noise instead of replacing authentication

The purpose of changing the login entry address is to remove the accessibility of the default path of the script, and the role of throttling is to push high-frequency attempts back into a manageable range. The public guidelines also define these two as noise reduction methods: changing the login address and doing IP throttling at the edge, which can eliminate noise before the request reaches the site. When implementing, pay attention to two points: first, after adjusting the entry address, the access records of the old path should be kept separately for a period of time to observe whether there is targeted attack; second, the threshold of throttling should be set by source group to avoid mistakenly blocking the normal operating office exit IP.

Step 2: Use captcha to prevent machine submissions

AnQiCMS supports integrating reCAPTCHA verification code into forms to prevent robot batch submissions. Most login brute-force attempts come from automated scripts, and the captcha can directly disrupt the submission rhythm of the scripts. Here, we need to differentiate between two types of intercept points: the background login side focuses on credential guessing, and the front-end form side such as comments, posts, and password recovery focuses on spam submissions and database probing. Both sides need to be covered. The built-in content security capabilities also provide sensitive word filtering and anti-interference codes to prevent collection, and are used in conjunction with JWT authentication to defend against SQL injection and XSS attacks.

The third step: issuing and using vouchers

After logging in, the session is maintained depending on the ticket, and this link is often ignored. AnQiCMS fixed two high-risk issues in v3.6.6 (October 8, 2026): SQL injection in list sorting parameters, and the login credentials can be forged when switching sites.The latter is a typical issue with bill issuance, the correct practice is to use one-time tickets - issued for use and invalidated after use, rather than allowing a reusable voucher to be valid for a long time.When upgrading this version, the corresponding action is to rotate the site signature key and change the administrator password. The key is not changed, and the historical forged credentials are still usable.

How to arrange the sequence of the three steps

| Order | Measures | What is solved | What cannot be solved | | First | Change login entry address, limit traffic by source | Eliminate script noise, make logs readable | Target attacks known about the new entry | | Next | reCAPTCHA captcha | Block automated submissions and brute-force detection | Low-frequency manual attempts | | Simultaneously | Tighten ticket issuance and use | Prevent credentials from being forged or reused | Weak passwords themselves | | Final | Version upgrade encryption key rotation | Close known defects | High-risk capabilities enabled without authorization |

Common questions

Is changing the backend address enough

Not enough. Changing the address is just to reduce noise, attackers can scan the path or find the entry from historical leaks, and still need to coordinate with the verification code and ticketing process.

Should two-factor authentication be enabled for all roles

Administrators and accounts with publishing permissions should be enabled in full, while ordinary copywriting accounts can be executed according to the grouping requirements. The public guide states that after the administrator side is enabled, it can offset the collision database effect.

Will throttling affect normal editing

Set thresholds by source grouping, add office exits and common networks to the whitelist. The judgment standard is the number of failures from the same source in the log, not the total number of requests.