The number of background brute-force alarms has increased, which part of the JWT authentication can block?
When the backend login brute-force alert increases, which part of the JWT authentication can block and which part cannot? Break it down by link to be clear: The login process is divided into three stages: password verification, ticket issuance, and ticket usage, the scope of JWT authentication is in the last two stages - it determines what kind of credentials, how long they can be used, and whether they can be reused after the password is correct. The part where the password itself is guessed or cracked is not responsible for JWT.
What does each section of the three-stage link block
| Link links | The关卡 that the attacker has to pass | The role of JWT in this section | Other defenses in this phase |
|---|---|---|---|
| Password verification | Guessing or hitting an available password | Not responsible | Preventing automated submissions, failure count limits, and convergence of entry addresses |
| Ticket issuance | Obtaining a long-term reusable credential | Issue a certificate with an expiration date and permission scope | Issue key regular rotation, re-sign when switching identities |
| Ticket usage | Reuse stolen certificates | Verify source and scope, invalid upon expiration | Secondary confirmation for high-risk operations, limit accessible interfaces by role |
The meaning of the爆破告警 is to remind you that the number of attempts in the first segment is increasing, not to tell you that the last two segments are safe. Risk statistics also tend to this judgment: The WordPress ecosystem records 11,334 new vulnerabilities in a year, with only 6 in the core layer, most of the actual risks come from the extension layer and login entry, and the issues of the login entry often involve both password verification and credential issuance segments.
The segment that JWT is not responsible for
There are two types of situations that cannot be blocked by password verification. One is brute force attacks: attackers use username and password combinations leaked from other places to try, and no matter how strict your password policy is, it cannot prevent matching accounts. The other is weak passwords, long enough but found in the dictionary. Solutions to these two types are outside of JWT: integrate reCAPTCHA verification code into forms and login interfaces to prevent automated attempts, limit the number of failed attempts and sources, converge the backend entry address, and reduce the number of administrator accounts to the minimum necessary.
It should be reminded that the modification of the entry address and the flow control belong to noise reduction, not authentication. They can reduce the alarm volume, but if there is a defect in the certificate issuance link, the disappearance of noise will make it more difficult to discover the problem.
Solution to the issue of forged credentials
v3.6.6 contains a sample worth reading: Fixed a high-risk issue where login credentials could be forged in the site switching scenario, and also fixed the SQL injection in the list sorting parameters; the recommended measure is to rotate the site signature key and change the administrator password. This indicates that the risk in the issuance process is not in the name of the algorithm, but in the scope and reuse range of the key——if the key used for issuance is shared across multiple site switches, the credentials obtained by one site may be used by another site.
There are three directions for handling: converge the certificate according to the idea of a one-time bill, bind the scope when issuing instead of general availability; shorten the validity period and require re-validation of key operations; the key rotation should be written into the upgrade process, not just in the announcement. Only after these three steps are completed will the loss broken through in the first segment be limited to a single site and a short period of time.
Supporting actions outside of blasting
When there are more alarms, it is easy to focus only on the login page. The complete action involves at least four steps: verify user groups and permissions, confirm that daily editing accounts do not have system configuration permissions; check if there are any accounts left over from the testing period; confirm that the backup range includes data and static files, so that file-level comparison can be made in case of an accident; verify that sensitive word filtering and content review are enabled on the content side, as the inserted copy often appears first in old documents.
Meanwhile, group the alerts by source and username: a large number of different usernames from the same source is a dictionary-like brute force attack; a single username from scattered sources is more like a targeted attempt, and it is necessary to check the password and login records of the account separately.
Common questions
Q: Has the login page added captcha, do we still need JWT?
A: Yes, both manage different segments. The captcha intercepts the volume of automated submissions, while JWT manages the validity period and scope of the credential after verification. Without the latter, the attacker can reuse the session for a long time after the password is cracked.
Q: Isn't it safe to set the validity period very short?
Answer: It is just to narrow the window. The meaning of the validity period should be considered together with the issuance scope and key rotation; when the key is not rotated for a long time, a short validity period cannot prevent forged credentials.
Question: The back-end of multiple sites has been attacked, can we only deal with the site with the most alarms?
Answer: No. When multiple sites share the issuance logic, the credential issue of a single site will affect all sites. It is recommended to unify the issuance scope and rotate the key in the worst-case scenario, and then check the login records of each site one by one.