وەسف
InTouch Integrity Guard is not a malware scanner and does not try to be one. It does a few focused things, all designed to run in the background without adding weight to a single front-end page load:
- Incremental file integrity checking. Compares WordPress core, plugin and theme files against known-good checksums from WordPress.org, and tracks your own file hashes locally so unchanged files are never re-hashed. Everything heavy runs in small batches via WP-Cron — never synchronously on a visitor’s request.
- Optional hardening toggles. Disable XML-RPC, block the file editor, hide the WordPress version, stop user enumeration (both the classic ?author=N probe and the REST API users endpoint), disable directory listing, send basic security response headers, and reduce automated bot noise against the login page — each one an independent, reversible switch, never forced on.
- Brute-force login protection. Blocks an IP after repeated failed logins, with configurable thresholds, backoff and a whitelist — checked with a single indexed query, before WordPress even attempts to verify a password.
- Two-factor authentication. Opt-in per user: an authenticator app (TOTP), a one-time code emailed by your own site, or single-use backup codes. Administrators can require it for chosen roles with a grace period. Entirely local — the TOTP secret never leaves your database, and no third-party 2FA service is involved.
- Opt-in known-vulnerability alerts. Off by default. If you turn it on, a once-a-day check (never on a page load) compares your installed plugins, themes and core version against a public vulnerability database and emails you a digest if something needs attention. This is the plugin’s only feature that contacts a third-party service — see External services below.
InTouch Integrity Guard deliberately does not include a heuristic malware/YARA scanner, an always-on web application firewall, or automatic malware removal. If you need those, this is not the right tool — InTouch Integrity Guard is the lightweight layer that watches for unauthorized file changes and closes the easy doors, not a full security suite replacement.
Features:
- Incremental file integrity index (SHA-256, hash/mtime short-circuit so unchanged files are skipped)
- WordPress.org core and plugin checksum comparison, with orphan/unknown-file detection
- Batched, cron-driven scanning — never a blocking scan on page load
- Independent hardening toggles with automatic backup/restore of any file they touch
- Brute-force login protection with IP whitelist and reverse-proxy-aware IP detection
- Two-factor authentication: authenticator app (TOTP, RFC 6238), site-sent email codes, and ten single-use backup codes — the TOTP secret is stored encrypted and never transmitted
- Optional per-role two-factor enforcement with a configurable grace period; an administrator can reset a locked-out user’s second factor, and an
SS_2FA_DISABLEconstant is a site-wide escape hatch - A hidden honeypot field on the login form, feeding into the same brute-force protection
- Optional custom login URL, to cut down on automated bot traffic against wp-login.php/wp-admin
- REST API user-enumeration blocking, alongside the classic ?author=N block
- Optional security response headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy)
- Opt-in daily known-vulnerability check (off by default) with a single digest email
- Admin dashboard with an aggregate security score, last-scan status, known vulnerabilities and 24-hour brute-force block count — the score and file-integrity counts refresh live while a scan runs, no manual reload needed
- Flagged-files list — every non-
oktracked file (modified, missing or unrecognized) with a paginated view, a read-only file content viewer, a direct link to the official plugin/theme/core source for comparison, and a CSV export for checking the list with external tools - A commercial plugin sharing its free counterpart’s WordPress.org slug (a common pattern — e.g. a Pro edition installed under the free plugin’s folder name) is flagged as a likely different edition instead of flooding the list with unexplained “unrecognized” files, and doesn’t count against the security score
- Blocked IPs list — every IP currently blocked by brute-force protection, with a one-click unblock and a one-click “add to whitelist”
External services
Always active (core functionality):
- api.wordpress.org — used to retrieve the official checksum list for the installed WordPress core version, so the integrity scanner can tell an unmodified file from a genuinely changed one. The WordPress version and locale are sent when the checksum list is fetched (then cached locally for 24 hours). No personal or site-identifying data is sent. This host is operated by the WordPress project: terms / privacy.
- downloads.wordpress.org — used the same way, to retrieve checksums for installed plugins hosted on the WordPress.org Plugin Directory. Only the plugin slug and installed version are sent, and only for plugins that WordPress’s own update-check data already lists as wp.org-hosted; premium/custom plugins are never queried. This host is operated by the WordPress project: terms / privacy.
Opt-in, disabled by default:
- WPVulnerability API — used only to check your installed core, active plugins and active theme against a database of known vulnerabilities, and to email the site admin if a match is found.
- Endpoint contacted:
https://www.wpvulnerability.net/— the public, key-less REST API. The service (API and policies alike) is operated by ROBOTSTXT (Barcelona, Spain); its policy pages are published on the company sitewpvulnerability.com/robotstxt.esand cover this same API. - This is off by default. No request is made and nothing is scheduled until you explicitly enable it under InTouch Integrity Guard Settings Known-vulnerability check. You can disable it again at any time, which also clears any stored results.
- What is sent, and when: once every 24 hours, via WP-Cron (never on a front-end page load), the plugin sends the component type (
core,pluginortheme), the slug and the installed version number of each active component. No site URL, domain, IP address, admin email or other identifying data is sent, and no account or API key is required. Responses are cached locally for 12 hours. - Provider: ROBOTSTXT — privacy policy, terms / legal, FAQ.
- Endpoint contacted:
سکرین شۆتەکان
دامەزراندن
- Upload the plugin files to
/wp-content/plugins/intouch-integrity-guard, or install directly through the WordPress plugins screen. - Activate the plugin through the “Plugins” screen in WordPress.
- Go to InTouch Integrity Guard Settings to enable the hardening toggles and configure brute-force thresholds; nothing beyond the local integrity scan runs until you turn it on. The known-vulnerability check (the only feature that contacts a third-party service) is off until you opt in on that same screen.
پهد
-
Does InTouch Integrity Guard remove malware?
-
No. It tells you which files changed or don’t match the official WordPress.org checksums, and lets you decide what to do next. It does not scan file contents for malicious patterns and does not remove anything automatically.
-
Does the plugin send my site’s data anywhere?
-
By default it only contacts api.wordpress.org / downloads.wordpress.org to fetch official checksums (WordPress version and locale, plus wp.org-hosted plugin slugs/versions — no identifying data). The known-vulnerability check that contacts wpvulnerability.net is off by default and only runs if you enable it in Settings; see External services above for exactly what it sends.
-
Will this slow down my site?
-
The integrity scan and the optional vulnerability check both run exclusively via WP-Cron, in small batches, and never on a normal front-end page load. Hardening toggles and brute-force checks are lightweight, indexed operations.
-
How does the two-factor authentication work, and is anything sent to a third party?
-
Nothing is sent anywhere. Each user turns on their own second factor under Users Two-factor authentication: an authenticator app (standard TOTP — Google Authenticator, Aegis, 1Password, etc.), a 6-digit code emailed by your own site with
wp_mail(), or a set of ten single-use backup codes. The authenticator secret is generated on your server, stored encrypted in the database, and never transmitted. There is no external 2FA service, no API key, and no account to create. -
What if I lose my authenticator and my backup codes?
-
Any administrator can clear your second factor from Users (your account) Manage this user’s two-factor authentication Reset, after which you can sign in with just your password and set it up again. If every administrator is locked out, add
define( 'SS_2FA_DISABLE', true );towp-config.phpto switch off all 2FA prompts and enforcement site-wide, sign in, sort it out, then remove the line. As a last resort,wp user meta delete <user> _ss_2fa_enabled_methodsvia WP-CLI does the same for one account. -
Does two-factor also cover XML-RPC and the REST API?
-
Yes. Once a user has a second factor, logging in as that user with their password over
xmlrpc.phpor via HTTP Basic auth on the REST API is refused — those channels never present the second factor, so allowing them would defeat it. Application passwords (Users Profile Application Passwords) keep working: each is a separate, individually revocable token, which is the right way to give a script or app access to a 2FA-protected account. -
Can I force two-factor authentication on my team?
-
Yes. Under InTouch Integrity Guard Settings Two-factor authentication, enable it and tick the roles it should be mandatory for, with a grace period (in days) before it is enforced. Affected users who have not set up a second factor are sent to the setup page once their grace period ends and cannot reach the rest of wp-admin until they do; logging out always stays available. It is off, with no roles enforced, by default.
-
Does this work on WordPress Multisite?
-
Multisite is not supported in this version. The plugin will not fatal if activated network-wide, but its functionality is not adapted for a multisite context yet.
-
Does changing the login URL actually make my site more secure?
-
Be honest with yourself about what this does: it reduces automated bot noise against the standard wp-login.php/wp-admin paths — nothing more. It is not a real security boundary. Anyone who wants to find your actual login URL can, by other means, and this does not replace (and is not a substitute for) the brute-force protection above, which is what actually stops credential-guessing attacks. Think of it as cutting down on log noise and drive-by bot traffic, not as locking a door.
This feature is implemented purely as PHP code that runs while the plugin is active — it never writes a rewrite rule or any other change to
.htaccessor your server configuration. That means deactivating the plugin, or even just removing its files directly (FTP, your host’s file manager, without going through the WordPress admin at all), immediately restores the standard wp-login.php/wp-admin URLs on the very next request. There is no separate cleanup step, and no scenario where this feature can lock you out of your own site once the plugin itself is gone. -
My site gets very little traffic — will scans actually run?
-
WordPress’s built-in “WP-Cron” only fires when someone visits the site, so a low-traffic site can see scans lag behind schedule. The scan cycle is a self-resuming chain — a missed tick just means the next visit (or the next real cron trigger) picks up exactly where it left off, nothing is lost or duplicated — but if you want scans to run on a predictable schedule regardless of traffic, disable WordPress’s page-load-triggered cron and drive it with a real system cron job instead:
- Add
define( 'DISABLE_WP_CRON', true );towp-config.php. - Add a system cron job (via your host’s control panel, or crontab) that requests
wp-cron.phpon a schedule, e.g. every 5 minutes:
*/5 * * * * curl -s https://yoursite.example/wp-cron.php >/dev/null 2>&1
or, if WP-CLI is available on your server:
*/5 * * * * cd /path/to/wordpress && wp cron event run –due-now >/dev/null 2>&1
This is standard WordPress practice, not something specific to this plugin — any WP-Cron-dependent plugin benefits from it on a low-traffic site.
- Add
پێداچوونەوەکان
هیچ پێداچوونەوەیەک نەنووسراوە بۆ ئەم پێوەکراوە.
بەشداربووان و گەشەپێدەران
“InTouch Integrity Guard” نەرمەواڵەیەکی سەرچاوە کراوەیە. ئەم کەسانەی خوارەوە بەشدارییان تێدا کردووە.
بەشداربووان
“InTouch Integrity Guard” وەربگێڕە بۆ زمانەکەی خۆت.
دەتەوێت بەشداربیت لە گەشەپێدان؟
گەڕان لە کۆدەکەدا بکە، سەیری تەمارگەی (SVN) بکە، یان بەشداربە لە ڕووداوتۆماری گەشەپێدان لە ڕێگەی (RSS).
ڕووداوتۆمارگەریی گۆڕین
1.1.0
- New: two-factor authentication for wp-login.php. Per-user, opt-in, set up under Users Two-factor authentication.
- Authenticator app (TOTP, RFC 6238) with a scannable QR code; the secret is generated locally and stored encrypted (AES-256, keyed from the site salts).
- One-time codes emailed by the site itself (
wp_mail()), with expiry, an attempt cap and a resend throttle. - Ten single-use backup codes, shown once and stored only as hashes.
- New: optional per-role enforcement with a grace period. Users in an enforced role are guided to set up a second factor and held on the setup page once the grace period ends; logout always stays reachable. Off, with no roles enforced, by default.
- New: an administrator can reset (disable) another user’s second factor from their profile for lock-out recovery;
define( 'SS_2FA_DISABLE', true )is a site-wide escape hatch. - For a user with two-factor enabled, password login over XML-RPC and the REST API is refused (that path never sees the second factor); application passwords still work and are the supported way to give an API client access.
- A wrong second-factor code counts toward the existing brute-force IP blocking, and a brute-force-blocked IP is refused a two-factor challenge entirely. Nothing here contacts a third-party service.
- Admin UI: every plugin screen now has a contextual “Help” tab (an Overview panel plus a per-screen guide) reachable from the “Help” toggle at the top of the screen — no new menu item.
- Admin UI: filled in the missing inline descriptions on the Settings screen (disable file editor, hide WordPress version, brute-force max attempts and time window, notification summary frequency, full scan frequency).
1.0.2
- The known-vulnerability check (WPVulnerability API / wpvulnerability.net) is now strictly opt-in and disabled by default: no request is made and nothing is scheduled until it is enabled in Settings, and disabling it clears any stored results.
- Documented the WPVulnerability API as an external service, including exactly what is sent and links to its privacy policy and terms.
- Removed the redundant load_plugin_textdomain() call (WordPress loads translations for directory-hosted plugins automatically).
1.0.1
- Initial release: incremental file integrity checking, WordPress.org checksum comparison, hardening toggles (including security headers and REST/author-enumeration blocking), brute-force protection with login honeypot, optional custom login URL, known-vulnerability alerts, a flagged-files list with a read-only file viewer and CSV export, a blocked-IPs list with unblock/whitelist actions, live-updating dashboard stats during a scan, and a “different edition” heuristic so a commercial plugin sharing its free counterpart’s slug doesn’t flood the flagged-files list or lower the security score.
- Summary email: the periodic digest is an HTML report (with a plain-text alternative part for older clients) — a stat row for the file/vulnerability/brute-force counts, then the individual flagged files grouped by status and tagged with the WordPress core / plugin / theme they belong to (capped per status, with an “…and N more” line), each vulnerable component spelled out with its known-vulnerability titles and reference links, and a footer with a direct link to the dashboard.