Documentation

Silverback Login docs.

Install, configure, and recover the plugin. If you're stuck or locked out, jump to Recovery — most support cases resolve there.

Installation

Three ways to install.

WordPress plugin directory (recommended, once published)

In your WordPress admin, go to Plugins → Add New. Search for Silverback Login. Click Install Now, then Activate.

Not yet listed in the WordPress plugin directory — submission is in progress. Until it lands there, use the zip upload method below. The zip on this page is always the current release.

Zip upload (available now)

  1. Download silverback-login.zip
  2. In your WordPress admin, go to Plugins → Add New → Upload Plugin.
  3. Choose the zip you just downloaded, click Install Now.
  4. Click Activate Plugin.

Manual FTP / SFTP

  1. Download the zip and unzip it locally. You'll get a folder called silverback-login/.
  2. Upload that folder to /wp-content/plugins/ on your web server via FTP/SFTP.
  3. In WordPress admin, go to Plugins. You'll see Silverback Login in the list. Click Activate.

Whichever method you use, activation is where the plugin does its setup — see the next section for exactly what happens.

First-time configuration

What happens on activation.

Silverback Login is designed to be correct by default. Activation does three things automatically so you don't have to think about them:

  1. Generates a random two-word slug (like cedar-river) and moves your login page to https://yoursite.com/<slug>. The default /wp-login.php and /wp-admin/ URLs are blocked for anonymous visitors.
  2. Shows a one-time green banner across the top of your admin with the new URL. Bookmark this before you navigate away.
  3. Emails every administrator on the site with the new URL. The email lives in your inbox permanently as a fallback if you lose the bookmark.

Do this next

  1. Log out and log back in via the new URL. Confirm it works from a browser you use daily.
  2. Enable email 2FA — Settings → Silverback Login → Login tab → check Require email verification on login.
  3. Log out, log in again, verify the 6-digit code arrives at your admin email and completes the login.
  4. Consider the Policy tab settings — forced password rotation and inactive-account lock are off by default. Turn on if you have a compliance or policy reason to; otherwise leave off.

Before enabling 2FA, make sure your site can send email. Try the WordPress password reset form (from a private browser window) and confirm the reset email arrives. If it doesn't, install an SMTP plugin like WP Mail SMTP first — otherwise you may not receive the 2FA code and could be locked out.

Login tab settings

Login settings, one by one.

Custom login URL

The slug is the path after your domain. If your slug is cedar-river and your domain is yoursite.com, your login URL is https://yoursite.com/cedar-river.

Letters, numbers, dashes, and underscores only. Leave the field empty to disable hide-login entirely (default /wp-login.php works again). Click Regenerate for a fresh random two-word slug. Nothing is saved until you click Save Changes.

Any time this slug changes, every administrator gets an email with the new URL. You can't accidentally lock your team out.

When someone visits the default URLs

Three options for what an anonymous visitor sees when they hit /wp-login.php or /wp-admin/:

  • Show a 404 page (recommended) — clean, uninformative, discourages further probing.
  • Redirect to the homepage — a bit friendlier for a legitimate user who typed the old URL. Also gives a bot a valid page to load, which is slightly noisier for your analytics.
  • Redirect to a custom URL — for the rare case you want to send them somewhere specific.

Email 2FA

When checked, users are asked for a 6-digit email code after their password is verified. A wrong password never triggers a code. The code expires 10 minutes after it was first issued, can be attempted up to 5 times, and can be resent up to 3 times (30 seconds apart) — resending never resets the attempt count or the expiry.

Code-request throttling is always on with 2FA: five challenges per 15 minutes per IP address and per account, then a 30-minute cool-down. A legitimate user never notices it. An attacker with a stolen password can't use it to flood the owner's inbox or to accumulate guesses across many fresh codes. Behind Cloudflare, the real visitor IP is used automatically.

XML-RPC, REST, and AJAX password logins are refused for any account 2FA applies to, since an email challenge can't be completed there. Anything that needs API access (the mobile app, Jetpack, deployment tools) should use an Application Password, which bypasses the 2FA gate by design.

Apply to roles lets you require 2FA only for specific roles (usually just Administrators). Leave all boxes unchecked to require it for every user regardless of role.

After first successful verification on a device, users can check Trust this device for 30 days on the code-entry form. Doing so drops an HMAC-signed cookie that skips the code prompt on that specific browser for 30 days. Not global to the user — per-device, so a phone and a laptop are trusted independently.

Force password reset

One-click button that requires every user (including you) to save a new password before continuing in the admin. Use it if you suspect a credential leak.

The Also immediately end every active session checkbox is the escalation: check it if you think existing browser cookies might be compromised and want to kick every signed-in user out at the next request. Your current session is preserved so you can finish your own password change.

Policy tab settings

Policy settings, one by one.

Forced password rotation

Choose an interval: Off, 3, 6, 9, or 12 months. Default is Off.

When on, any user whose most recent password change is older than the interval is held on the profile screen at their next admin page load and can't leave until they save a new password. Modern security guidance (NIST 800-63B) actually prefers reuse prevention and breach screening — both of which are always on regardless — over forced rotation. If you don't have a compliance rule requiring rotation, leave this Off.

Inactive account lock

A daily background job scans users. Any non-administrator account whose last login is older than the threshold you set (1–60 months) gets locked. Locked users see a generic error on login and can't complete authentication until an administrator unlocks them.

Every administrator receives one batch summary email per scan run with the list of affected users and unlock instructions. Administrators themselves are never auto-locked.

To unlock a user: via WP-CLI, run wp user meta delete <user_id> _silverback_locked. Or remove the _silverback_locked user meta row directly via phpMyAdmin.

Recovery paths

If you lose the URL or get locked out.

Try these in order. Most cases resolve in the first two.

  1. Check your inbox. The login URL is emailed to every administrator on activation and any time it changes. Search for "Login URL has changed" or "Silverback Login activated". This is the single most common answer.
  2. Use your host's WordPress admin bypass. Plesk (WordPress Toolkit), WP Engine, Kinsta, Cloudways, SpinupWP, and most managed WordPress hosts have a "Log in to WordPress" button in their control panel that bypasses the URL entirely. Once you're in, note your slug from Settings → Silverback Login.
  3. WP-CLI, if you have SSH access. Run wp option get silverback_options --format=json and read the login_slug field. That's your URL suffix.
  4. Direct database lookup. Open phpMyAdmin, go to the wp_options table, filter for silverback_options. The value is a serialized PHP array containing your slug.
  5. Emergency disable constant. See Escape-hatch constants below. Requires FTP/SSH access to your wp-config.php.
  6. Last resort: rename the plugin folder. Via FTP, rename /wp-content/plugins/silverback-login/ to something like silverback-login.disabled/. WordPress will treat the plugin as missing and disable it, restoring default /wp-login.php access. Your settings persist for when you rename it back.

Escape-hatch constants

Three lines you can add to wp-config.php.

All require FTP or SSH access to your server. They live at the top of wp-config.php, just below the <?php line, alongside the other define() statements. If you have WP-CLI, each one is a single command: wp config set SILVERBACK_DISABLE_2FA true --raw, and wp config delete SILVERBACK_DISABLE_2FA to remove it.

Disable hide-login entirely

define( 'SILVERBACK_DISABLE_HIDE_LOGIN', true );

When this constant is defined and truthy, the plugin's URL rewriting shuts off immediately. Default /wp-login.php and /wp-admin/ work again. Your custom slug still resolves too (both paths work), so you can log in via the default URL, note your slug from settings, remove the constant, and continue.

Disable 2FA

define( 'SILVERBACK_DISABLE_2FA', true );

When this constant is defined and truthy, the plugin's 2FA challenge is skipped entirely. Passwords still authenticate; the 6-digit code prompt is bypassed. Use this if outgoing email breaks on the site and you can't receive the code.

Disable code-request throttling

define( 'SILVERBACK_DISABLE_THROTTLE', true );

Lifts the per-IP / per-account cap on starting new 2FA challenges. You'd only want this if a large office or VPN is putting many legitimate users behind one address and they're tripping the 30-minute cool-down. 2FA itself stays on.

Remove the constants once you're back in and things are working normally. Leaving them defined defeats the security controls they gate.

Managing many sites

Everything is one WP-CLI command.

All of Silverback's settings live in a single silverback_options row, so anything you can click in the dashboard you can also script. If you run several client sites on one server, this is how you keep them consistent without opening several dashboards. Examples below assume sites at /var/www/<domain>/public_html — adjust to your layout.

Read a site's login URL

wp option get silverback_options --format=json | grep -o '"login_slug":"[^"]*"'

Turn on 2FA for every site

for s in site-one.com site-two.com site-three.com; do
  wp option patch update silverback_options twofa_enabled 1 --path=/var/www/$s/public_html
done

Other keys follow the same shape: twofa_for_roles (array of role slugs, empty = everyone), redirect_action (404, redirect_home, or redirect_url), rotation_interval_months (0, 3, 6, 9, 12), inactive_lock_enabled and inactive_lock_months.

Confirm every site is on the current version

for s in site-one.com site-two.com; do
  printf "%-30s " $s; wp plugin get silverback-login --field=version --path=/var/www/$s/public_html
done

Unlock an inactive-locked user

wp user meta delete <user_id> _silverback_locked

Check permissions after any file-level deploy. If you copy the plugin folder onto a server with rsync or scp, make sure the web server's user can read it: chmod -R u=rwX,go=rX wp-content/plugins/silverback-login. WordPress loads plugins with include_once, so an unreadable plugin is silently skipped — the site runs with no hide-login and no 2FA — while WP-CLI (which runs as your shell user) still reports it as "active." Verify from the browser, not just the CLI.

Updates

Keeping the plugin current.

If you're on 0.2.1 or earlier, update now. Versions before 0.2.2 did not verify the password before sending the 2FA code, so the password layer was not doing its job. Details on the security advisories page.

Once Silverback Login is in the WordPress plugin directory, updates work like any other plugin — WordPress will notify you in the admin, and one-click Update handles the swap. Your settings, password history, trusted devices, and all internal state persist through the update.

If you installed via zip upload, you can update by deactivating the current version, deleting it via the Plugins screen, downloading the new zip, and installing that. If you're on version 0.1.10 or later, deleting the plugin fires uninstall.php which wipes the database — so update by replacing files via FTP instead if you want to preserve your settings.

Uninstall behavior

What happens when you delete the plugin.

Deleting the plugin (Plugins → Delete after Deactivate) runs uninstall.php, which removes every piece of state the plugin created:

  • The silverback_options settings row.
  • The silverback_force_password_change_after option, if you triggered a force-reset.
  • All _silverback_* user meta records across every user — password history, trusted devices, last-login timestamps, locked flags.
  • The silverback_scan_inactive cron event.
  • Any in-flight 2FA challenge transients.

This is deliberate — security tools shouldn't leave hashed passwords or device tokens sitting in your database once you've said you want the plugin gone. Deactivation alone doesn't trigger the wipe; you have to explicitly delete for state to be removed.

FAQ

Common questions.

Will activating this plugin lock me out?

No. On activation the plugin generates a random slug, shows it to you in a green banner, and emails every administrator with the URL. Email 2FA is off by default — you turn it on once you've confirmed outgoing mail works. Forced rotation and inactive-lock are also off by default.

Does the plugin rewrite WordPress core files?

No. It intercepts requests via standard WordPress hooks. Deactivation cleanly restores default login behavior and stops the inactive-scan cron.

How does the breach-password check work?

It uses the Have I Been Pwned password API via k-anonymity. Your server SHA-1s the password locally, sends only the first 5 characters of that hash to HIBP, and receives back a list of hash suffixes to compare against. The full password — and even its full hash — never leaves your server.

What if HIBP is unreachable?

The check fails open — the password is allowed through. We'd rather let a weak password slip than block legitimate password resets when an external API is down. Reuse prevention is local so it always runs regardless.

Can an attacker flood my inbox with 2FA codes?

No. A code is only generated after a correct password, and even then the plugin caps new challenges at five per 15 minutes per IP address and per account, followed by a 30-minute cool-down. If you ever receive codes you didn't request, two things are true: someone has your password, and 2FA is the only thing keeping them out. Change the password and check the user list.

Does 2FA work with the WordPress mobile app, Jetpack, or XML-RPC?

Password logins over XML-RPC, the REST API, and AJAX are refused for 2FA-protected accounts — an email challenge can't be completed in those channels, and xmlrpc.php is the most-abused brute-force path in WordPress. Use an Application Password (Users → Profile → Application Passwords) for any app or integration; those authenticate separately and are unaffected.

Does the plugin work on multisite?

Single-site is fully supported. Multisite is not officially tested in this release and is on the roadmap.

Where do I report a bug or request a feature?

Use the contact form. Include your WordPress version, PHP version, and a description of what you were doing when the issue happened. If it's a security issue, please describe it in the contact form without publicly disclosing details.

Ready to install

Download Silverback Login.

Free. No account. No license key. No paid tier.

Download the plugin Compare features