Features

Every module, in detail.

Silverback Login has eight coordinated modules that address specific credential-lifecycle failure modes. This page walks through each one: what it does, why it matters, and how it holds up when something else in your stack breaks.

Access control

Hide the login URL.

Every WordPress site ships with the login page at /wp-login.php and the admin at /wp-admin/. Every bot on the internet knows this. A typical WordPress site catches hundreds of automated login attempts per day just because those two paths are predictable.

Silverback Login replaces both with a custom slug you choose (or one we generate). The default generator combines two words from a curated list of neutral English nouns (cedar-river, harbor-moss, aurora-falcon) giving about 14,400 unique combinations. The plugin name never appears in the URL, so a scanner can't fingerprint Silverback from the slug itself.

Anonymous visitors who hit the old /wp-login.php or /wp-admin/ URLs get a clean 404 (or a redirect to your homepage or a custom URL, your choice). The plugin never rewrites WordPress core files — it intercepts at the request layer using standard hooks, so deactivation restores the default behavior instantly.

A Regenerate button next to the slug field mints a fresh two-word slug via AJAX. You can keep clicking until you like one; the change isn't saved until you hit Save Changes. Any time the slug is set or updated, every administrator on the site gets an email with the new URL — no more losing the URL because you forgot to write it down.

Authentication

Email two-step verification.

A hidden URL cuts bot noise. It doesn't stop the real threat: someone who obtained a legitimate password (phishing, reused-elsewhere, dumped in a breach) trying to use it. For that you need a second factor.

Silverback Login sends a 6-digit code to the user's email after a correct password. The code is stored server-side as a hash, expires in 10 minutes, is rate-limited on resends, and can be attempted up to 5 times before the session is invalidated. Email as the default because every WordPress user already has an email address — no setup, no separate app to install.

A "trust this device for 30 days" checkbox on the verification form drops an HMAC-signed cookie, so the same browser doesn't re-prompt for 30 days. The cookie is bound per-user via wp_salt('auth'), revocable, and capped at 10 trusted devices per user to prevent accumulation.

Code-request throttling

Email 2FA has a failure mode most plugins ignore: an attacker who has the password can submit it over and over, and every submission triggers a fresh code — and a fresh email to the account owner. The inbox fills up, and each new code is a new set of guesses. Silverback caps how many challenges a single IP address or a single account can start: five per 15 minutes, then a 30-minute cool-down. Past that, the login screen says "try again later" and nothing is sent. The per-account limit is the one that matters — an attacker rotating IPs still runs into it.

The limits inside a challenge are tight too: five wrong codes ends it, resends are capped at three and spaced 30 seconds apart, and a challenge expires 10 minutes after it was created no matter how many times it's poked.

No side doors

xmlrpc.php is the oldest brute-force channel in WordPress, and most login plugins only guard the login form. Any account protected by Silverback 2FA simply cannot authenticate with a password over XML-RPC, the REST API, or AJAX — those channels get a clear error, not a code. Scripts and integrations that need API access use WordPress Application Passwords, which are designed for exactly that and don't pass through the 2FA gate.

Cloudflare-aware

If your site sits behind Cloudflare, the origin server only ever sees Cloudflare's edge addresses. A naive rate limiter would throttle every visitor who shares an edge. Silverback reads the real visitor IP from Cloudflare's header, so lockouts land on the attacker and nobody else. Not on Cloudflare? Nothing to configure — it falls back to the direct address.

Emergency exits

If outbound email breaks and you can't receive the code, add define( 'SILVERBACK_DISABLE_2FA', true ); to wp-config.php. 2FA disengages until you remove the line. The throttle has its own switch, SILVERBACK_DISABLE_THROTTLE, for the rare case a shared office IP trips it. Documented up front because SMTP outages are the number-one lockout scenario for any 2FA plugin.

Password lifecycle

Breach screening, reuse prevention, optional rotation.

Modern security guidance (NIST 800-63B) tells you the passwords themselves matter more than how often you rotate them. Silverback Login implements both the modern controls (breach screening, reuse prevention) and the traditional one (rotation) — so you can match either regime.

Breached-password screening (HIBP)

Every new password validation query runs against the Have I Been Pwned password database via the k-anonymity range API. The plugin SHA-1s the password locally, sends only the first 5 hash characters over the wire, and receives back a list of full-hash suffixes to compare against. The full password — and even its full hash — never leaves your server.

Always on. No setting. If the password has appeared in any known breach, the user is told to choose another. If HIBP is unreachable (rare, but happens), validation fails open — the password is allowed through. Blocking legitimate password resets because an external API had a bad afternoon isn't a security win.

Last-5 reuse prevention

The user's last five password hashes are kept in a per-user meta record and compared on every password change. If the new password matches any of the last five, it's rejected. Always on, no setting, local storage — never touches an external API, never stops working.

Forced rotation

Optional. Dropdown lets you pick 3, 6, 9, or 12 months. When a user's password reaches the interval, they're gated to the profile screen on their next admin page load and held there until they save a new password. The gate is O(1) — a single global timestamp check, no per-user loop, scales to any site size.

Account lifecycle

Inactive-account lock.

Forced rotation only affects users who come back to log in. It never touches the dormant accounts that just stopped visiting — the ones where a leaked credential would sit unnoticed for years. Silverback Login closes that gap with an optional inactive-account lock.

A daily WordPress cron scans users in batches of 500. Any non-administrator account whose last login is older than your configured threshold (default 6 months) gets flagged with a _silverback_locked meta record. Locked accounts see a generic error message on login and cannot complete authentication.

Administrators are never auto-locked. When one or more accounts are locked in a scan run, every administrator gets a single batch summary email listing the affected users and unlock instructions. One email per cron run, not per user — so a site with 50 stale accounts doesn't blast every admin with 50 messages.

Emergency response

Force-all password reset, with optional session kill.

Under normal operation, forced rotation is enough. But for breach response — you got a disclosure notice, a credential leaked, an attacker was in the system — you need a bigger hammer.

One button under Settings → Silverback Login → Login tab: Force all users to change password on next login. Click it, confirm the dialog, and every user (including you, the admin who clicked) is gated to the profile screen at their next admin page load until they pick a new password. Backed by a single global timestamp — no per-user database walk, scales to any user count.

For a suspected active breach, there's a checkbox next to the button: Also immediately end every active session. When ticked, the handler iterates every user and destroys every active session token via WordPress's built-in WP_Session_Tokens API. The clicking admin's current session is preserved so they can complete their own password change. Browser tabs of every other signed-in user lose their cookie at the next request.

Recovery

Multiple ways back in if things go wrong.

The biggest support risk for any login-security plugin is the site owner locking themselves out. We designed Silverback Login with a graduated recovery path so you always have at least one way back in.

  1. Email. The login URL is emailed to every administrator on activation and on every slug change. Search your inbox for "Login URL."
  2. Hosting panel. Plesk's WordPress Toolkit, WP Engine, Kinsta, Cloudways, SpinupWP, and most managed hosts have a one-click "Log in to WordPress" feature that bypasses the URL entirely using filesystem-level auth tokens.
  3. WP-CLI. If you have SSH access: wp option get silverback_options --format=json and look for the login_slug field.
  4. Direct database. phpMyAdmin → wp_options → search for silverback_options — the value is a serialized array containing your slug.
  5. Emergency constants. Add define( 'SILVERBACK_DISABLE_HIDE_LOGIN', true ); to wp-config.php and default wp-login.php access is restored until you remove the line. SILVERBACK_DISABLE_2FA and SILVERBACK_DISABLE_THROTTLE do the same for the other two gates. One line in a file you already have SSH or FTP access to — no database surgery.
  6. Rename the folder. Last resort — rename /wp-content/plugins/silverback-login/ via FTP or your hosting file manager. The plugin is disabled but your settings persist for when you rename it back.

Design philosophy

Correct by default, small settings surface.

Most security plugins bury critical behavior behind dozens of toggles nobody reads. Silverback Login has two settings screens. That's the whole admin UI.

Login screen: custom URL slug, redirect target, email 2FA toggle, per-role 2FA scope, force-all-users reset button.

Policy screen: forced password rotation interval, inactive account lock enable and threshold.

Breach screening, reuse prevention, trusted-device cookies, code-request throttling, batch admin notifications, force-reset gate — always on. Not toggleable. We picked the correct answer once and locked it in.

Built for fleets

One option key. Any number of sites.

A small settings surface has a side benefit: every setting lives in a single silverback_options row, which means every setting is one WP-CLI command away. If you manage a dozen client sites on one server, you don't click through a dozen dashboards — you write a loop.

Turn on 2FA everywhere, read back every site's login URL, or confirm every site is on the current version, all from one shell. The docs have the exact commands. The plugin was built by an agency running exactly that setup, and the CLI path is the one we use ourselves.

It also plays well with what you already run. Wordfence, Defender, and the other suites keep doing firewall and malware duty; Silverback handles the credential layer. The only thing to switch off is their overlapping hide-login or 2FA module, so the two don't argue over the same request.

How we compare

Silverback Login vs the alternatives.

Two adjacent categories of WordPress security plugins exist: the hide-login specialists and the big all-in-one suites. Silverback Login fills the gap between them — deeper on credential lifecycle than the specialists, more focused than the suites.

Feature Silverback Login WPS Hide Login Wordfence / iThemes
Hide login URL Yes, with regenerate Yes Some do (Defender, AIOS)
Email 2FA Built in No Yes (paid tier for some)
2FA code-request throttling Per IP and per account No Generic login limits
XML-RPC / REST password auth blocked for 2FA accounts Always No Separate toggle, if at all
Cloudflare real-IP aware Automatic N/A Manual configuration
HIBP breach screening Always on No No
Last-N password reuse prevention Always on No No
Forced password rotation Optional, configurable No Some do (paid)
Inactive account lock Optional, batch email alerts No No
Force-all password reset One click, optional session kill No Manual per-user
Firewall / malware scan No (out of scope) No Yes (that's their focus)
Setting screens to learn 2 1 Many (10+)

If you already run Wordfence or a similar suite for firewall and malware scanning, you can keep it — just turn off its 2FA and hide-login features so they don't collide with Silverback Login. Silverback focuses on the credential layer; the big suites focus on the request layer. They complement each other.

Ready to try it

Download Silverback Login.

Free. No account. No license key. No paid tier. Download the plugin, upload to WordPress, activate. The defaults do the rest.

Download the plugin Read the docs