Kwistech Secure
| 开发者 | kwistech |
|---|---|
| 更新时间 | 2026年8月27日 02:06 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
Kwistech Secure hardens a WordPress site using only what WordPress already gives you. It is
not a firewall, not a malware scanner, and not a service — everything it does happens on your
own server, and it never contacts anybody.
Twelve controls, each independently switchable, each logged when it changes:
- Two-factor sign-in — RFC 6238 authenticator codes with one-time recovery codes. Detects an existing 2FA plugin and stays out of the way rather than fighting it.
- Login rate limiting — counts failures by IP address and by username, so a password sprayed across many accounts from one host and one account attacked from a botnet are both caught. Usernames are stored only as a salted hash.
- Non-enumerating login errors — one identical message for every failure, on the sign-in form and the password-reset form alike, so neither confirms which usernames exist.
- Custom sign-in address — moves
/wp-login.php. Tests the new address before saving it and provides a break-glass constant, because the obvious way to implement this is also the obvious way to lock yourself out. - File editor disabled — removes the most direct path from a stolen administrator session to arbitrary code execution.
- XML-RPC off — closes a long-standing brute-force amplifier that most sites never use.
- Application password inventory — reports how many exist per user, never their values. They bypass two-factor, and most people have forgotten the ones they created.
- Version fingerprints removed — generator tags, feed generators,
X-Powered-By. - Username discovery blocked —
?author=1scans, the REST user list, the user sitemap and oEmbed author fields all stop answering anonymous callers. Author archives at their own address keep working, and so does everything a signed-in editor needs. The control also reports when an account's display name is its username, because when that is true the byline gives the game away regardless. - Security response headers —
X-Content-Type-Options,X-Frame-Options,Referrer-PolicyandX-Permitted-Cross-Domain-Policies, and never overwriting one your server or CDN already sends. Deliberately no CSP: any policy that leaves wp-admin usable needsunsafe-inline, which does not stop the attack CSP exists to stop. - Enforced password policy — a minimum length, and a refusal of passwords containing the username or the site name, applied server-side when a password is set or reset. WordPress itself only shows a strength meter next to a "confirm use of weak password" checkbox.
unfiltered_htmlrestricted — via a capability filter rather than the all-or-nothing constant, so administrators keep the workflows they need.
- It does not scan for malware, and a clean install proves nothing about whether you are infected.
- It does not filter traffic. It is not a WAF and cannot stop an attack in progress.
- It does not patch anything. It reports on outdated core and plugins; updating is yours.
- It cannot protect against someone who already has your administrator password and your second factor.
安装:
- Upload the plugin through Plugins → Add New → Upload Plugin, or install it from the directory.
- Activate it. Ten of the twelve controls switch on immediately at safe defaults.
- Open Kwistech Secure → Hardening and decide on the two that need a decision from you: the custom sign-in address and two-factor enforcement. Both default to off, deliberately — enabling either without preparation can lock you out of your own site.
常见问题:
Will this lock me out?
Two controls can, and both are built to make that hard. The custom sign-in address makes a
real request to the new address before saving it, and refuses to save if it does not answer;
if the check cannot run, you must tick an acknowledgement, and that choice is recorded.
Two-factor enforcement cannot be switched on until at least one administrator has enrolled,
because requiring codes before anyone has an authenticator locks out everybody at once.
If you are locked out anyway, add define( 'KWISTECH_SECURE_DISABLE_LOGIN_SLUG', true ); to
wp-config.php and /wp-login.php works again immediately.
Does it conflict with my existing security plugin?
It detects other two-factor plugins and steps aside rather than running a second implementation. For firewall and scanning plugins there is no overlap — this one does neither. Switch off any individual control that duplicates something you already have.
Does it slow the site down?
The hardening controls are filters and capability checks with no database work on a normal page load. Nothing runs on the front end except the header changes.
Does it work on multisite?
The code paths exist and have never been run on a real network. Treat multisite as unsupported rather than broken.
What happens to my data if I uninstall it?
Deleting the plugin removes its options, both database tables, the scheduled job, and every
user meta key it set, including two-factor secrets and recovery codes. Deactivating changes
nothing. Constants you added to wp-config.php by hand are left alone, because this plugin
never edits that file.
Is the source readable?
Yes, deliberately. No minified files, no bundled dependencies, no build step, no obfuscation. A security plugin you cannot read is a security plugin you cannot check.
更新日志:
1.6.0
- Every option, user meta key, database table and scheduled job this plugin stores has moved
from the
kws_prefix tokwistech_secure_. Three characters is below the four-character minimum the plugin directory asks of a prefix, and it was the one part of the plugin still using the short form. Your data is migrated automatically the first time an administrator loads a wp-admin page after upgrading: settings, audit log, login history, two-factor enrolment and recovery codes all carry across. Tables are renamed rather than copied, so no audit entry is lost. - If you read this plugin's data directly -- a WP-CLI script, a dashboard widget, a database
query -- update it to the new names.
kws_settingsis nowkwistech_secure_settings, the audit table is now{prefix}kwistech_secure_audit_log, and the daily job is nowkwistech_secure_daily_maintenance. - The key used to encrypt two-factor secrets at rest is rotated as part of the same change. This is transparent: existing secrets are still read under the previous key, so your authenticator app keeps working and there is nothing to re-enrol.
- Removed the cleanup that deleted two retired database tables and a retired encrypted credential left over from a payment feature that was never released. No installation has ever held that data, so the code deleted something that could not exist.
- The add-on notice introduced in 1.5.0 is now four lines instead of twelve, and appears only on this plugin's dashboard rather than on all four of its screens.
- Reading a submitted form field now requires that the capability and nonce check has already passed, enforced in code rather than by convention. No behaviour changes for anyone using the plugin normally; it closes the gap where a handler added in future could forget the check.
- Requires the Insurance Evidence Pack add-on 1.2.0 or newer, if you use it. Older add-on versions keep working but will not have their own data migrated.
- Added a one-off notice on this plugin's own screens introducing the Insurance Evidence Pack
add-on. It appears nowhere else in wp-admin, never appears if the add-on is installed, is
dismissed permanently and per-user, is styled as information rather than as a warning, and
loads nothing from anywhere. Developers and agencies can switch it off with the
kwistech_secure_show_addon_noticefilter. - Fixed a test-isolation bug where the active-plugin cache leaked between unit tests.
- Three new hardening controls, taking the total to twelve. All three default to on; none of them can lock you out.
- Block username discovery. Closes
?author=Nscans,/wp-json/wp/v2/users, the user sitemap and oEmbed author fields to anonymous visitors. This was a known gap, recorded in the threat model as accepted residual R-5. Refusing to confirm usernames at the sign-in form while handing the list out over REST was never a coherent position. - Security response headers. Four of them, and it will not overwrite a header your server or CDN already sends.
- Enforced password policy. Minimum length, and no passwords containing the username or the site name. Separators and case are ignored on both sides of that comparison, so "Test-Site-2026" is caught for a site called "Test Site". Existing passwords are stored as hashes and cannot be assessed; the policy applies from the next time each one is set.
- Added a regression test that the hardening form and its save handler agree on the field list. An unchecked checkbox submits nothing, so a field rendered but not read back is silently switched off on every save — a bug that only surfaces as "this setting will not stay on", and precisely the mistake a three-control release invites.
- Renamed from "Kwistech WP Secure" to "Kwistech Secure". "WP" is a restricted term that
cannot appear in a plugin name or slug, so the old name could never have been published.
The plugin folder is now
kwistech-secure; if you installed 1.2.0 by hand, delete the oldkwistech-wp-securefolder after upgrading or WordPress will run both copies at once. Settings, audit log and login history are untouched -- they are keyed independently of the folder name and carry across. - Extension hooks renamed to match the new slug:
kws_dashboard_cards,kws_settings_panels,kws_admin_noticesandkws_admin_notice_messagesbecomekwistech_secure_*. The opt-out constantKWS_DISABLE_LOGIN_SLUGbecomesKWISTECH_SECURE_DISABLE_LOGIN_SLUG. Update the add-on to 1.1.0 at the same time. - Now requires WordPress 6.2, up from 6.0. Table names in the audit log and login-attempt
queries are passed through
$wpdb->prepare()as%iidentifier placeholders rather than interpolated into the SQL string. The old form was safe -- the names were built from$wpdb->prefixplus a literal -- but "safe because you can read the surrounding code" is weaker than "cannot be otherwise", and it needed a static-analysis suppression on every query to say so.%iarrived in WordPress 6.2.
- Split into two plugins. The evidence pack is now a separate paid add-on distributed from kwistech.ca; this plugin contains no locked functionality and never will.
- Added extension points so add-ons attach through documented hooks rather than patching.
- Settings screen now explains what is stored and for how long, instead of offering a retention control that governed data this plugin no longer owns.
- Renamed for clarity. The plugin folder and all settings are unchanged; nothing to migrate.
- Removed the payment layer entirely. No webhook, no outbound third-party request, no stored credential.
- Every entry point is now a capability-checked, nonce-protected wp-admin request.
- Fixed admin styles being served from cache after an update.
- Initial release.