Every module, in detail.

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.

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.

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.

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, rate limiting, batch admin notifications, force-reset gate — always on. Not toggleable. We picked the correct answer once and locked it in.