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.

Currently in review with the WordPress plugin directory. Until it lands there, use the zip upload method below.

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. The code expires in 10 minutes and can be attempted up to 5 times.

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

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

Both 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.

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.

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

Updates

Keeping the plugin current.

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.

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