AuthDock — Login Security, 2FA, Social Login & Brute Force Protection

Changelog

2.1.6

The final pre-release audit. A full security, correctness and stability review of every module. Recommended for every site. Nothing is reset, no setting changes meaning, and upgrading turns nothing on — but several controls that reported themselves as protecting a site were not, and now do.

Security controls that were not running

• Location rules and bot protection did not stop a sign-in with a correct password. Both refused before WordPress checks the password, and core’s authenticators discard an earlier refusal when they are given a username and a password. A denied country, a filled honeypot and an unsolved challenge were each overwritten by a valid password. Both now run after core, where the login limiter has always sat. The “administrators only from these countries” rule could not fire at all.
• Suspending an account did not stop it signing in with its password — the same defect, one step earlier, so the check ran before there was an account to check.
• Location rules never applied on any site using a GeoLite2 database. The database reader resolved pointers sixteen bytes early, so every lookup reported “no data” — and a rule with no data allows everyone, which made the failure silent and indistinguishable from the rule working.
• A country header was believed from any client, so an allow-list of one country was open to anyone who put that country in a header. Forwarding headers are now honoured only from a configured proxy.
• Social sign-in, magic links and passkeys ignored the location rules, the address lockout and the risk engine, because none of them goes through the password path those controls hook. All three now ask the same question.

Account safety

• A social sign-in could be finished by a browser that did not start it — login CSRF, which signs a visitor into the attacker’s account. Each flow is now tied to the browser that began it.
• “Connect” on the profile page linked the wrong account, or registered a new one and signed the visitor into it, logging them out of their own. It now links to the account that asked and signs nobody in.
• A new account could be registered on an address the provider had not verified, which is the first half of an account takeover.
• The conditional-content block returned its gated content to anonymous REST callers.
• Frontend access control was bypassed by adding ?rest_route= to any URL, or by a percent-encoded spelling of a blocked path.
• The scheduled audit export was world-readable on nginx hosts; its directory name is now unguessable.
• The webhook signing secret was stored, exported and shown in the clear. The two-factor handoff record held the live challenge token in plain text.

Settings that destroyed what they saved

• Saving the Single Sign-On screen wiped the OIDC client secret, and a newly typed one was stored unencrypted. Every write path now protects every section’s secrets.
• “Permanent block after: 0 to disable” was clamped to 1, so switching auto-blacklisting off produced the strictest setting instead.
• A network policy or a wp-config.php setting could not actually switch a module on, and importing a configuration could not shrink or clear a list.

Features that did nothing

• The concurrent-session limit never ended a session, while logging that it had.
• The “new device” email to the account holder could never be sent.
• The audit-log chain verifier reported tampering on any site with retention enabled, and the scheduled export re-sent the same oldest rows every run while claiming to attach a file it did not attach.
• The dormancy sweep only ever examined the first two hundred accounts, and could suspend a network administrator.
• The risk engine’s impossible-travel signal was dead unless another module happened to be switched on, and an enforced block wrote no log entry and sent no email.
• The conditional bot challenge never appeared with the login limiter switched off.
• Apple and Twitch sign-in could not complete at all. A custom magic-link email body was ignored, the register form’s redirect did nothing, and OIDC accounts could not be disconnected.

Correctness and robustness

• Password resets were broken on sites using the passwordless preset — every reset link answered “invalid key”.
• Attempt limits counted after checking rather than before, so concurrent requests shared one increment; spray detection blacklisted shared office and mobile addresses permanently; IPv6 wildcards only matched when zero-padded; dashboard rules ignored wildcards the screen accepted.
• The generic login error replaced every message on every login-page form; the audit-log screen and its exports could not load on plain permalinks; a large JSON export exhausted memory; retention windows were off by the site’s UTC offset.
• Two-factor codes could be submitted twice, the login form could be submitted before the proof-of-work answer was ready, and the lost-password form said whether an address had an account.
• Uninstalling left a stored phone number behind and, on multisite, ignored one site’s “keep my data” choice while honouring another’s.
• On MySQL 5.6 and MariaDB before 10.2 the login-attempts table was never created; schema 8 shortens the index that prevented it.
• New extension point: authdock_passwordless_login_allowed.

2.1.5

Two-factor after social sign-in and magic links now works without cookies.

• The challenge screen could only identify a sign-in by a cookie set on a previous response. Where something in front of the site strips cookies — a CDN or proxy in front of /wp-json/ is the usual culprit, and social sign-in completes there — that cookie never arrived and the screen could only say the session was gone. The form now carries a single-use handle naming the challenge, and every path that completes a challenge accepts either. The cookie is still preferred; the password route is unchanged.
• The handle is not the challenge token, which stays out of the markup for good. It expires with the challenge, survives a mistyped code, and stops working the moment the sign-in completes.
• POST /2fa/verify was declaring token required, so it rejected the requests that correctly carry neither a token nor a handle.

2.1.4

Magic links and social sign-in, on sites with a persistent object cache. Required for every site running Redis or Memcached — which is most managed hosting.

• “Invalid or expired magic link” for a link minutes old. The handle connecting a magic link to its account was stored as a transient, which on a host with a persistent object cache means it lived nowhere but that cache. Any flush — a deploy, wp cache flush, a caching plugin’s Purge All — invalidated every link already sitting in an inbox. It is a database row now. Links sent before the upgrade still work.
• The same fault in every OAuth flow. The record of a social sign-in in progress, the OIDC nonce, and the name Apple sends only once were all transients too, so a flush mid-flow answered “This sign-in link has already been used or has expired” about a sign-in seconds old. All three moved to the database.
• 2.1.3’s cache purge was itself flushing the object cache, on any settings save. It is now page-caches only, and only for the settings that change which URLs must never be stored.
• “Session expired” after social sign-in. The cookie carrying the two-factor challenge is set by one response and read after a redirect; anything in front of the site that strips cookies from /wp-json/ responses broke that. The redirect now carries a single-use handle — not the challenge token — which the challenge screen exchanges for the cookie and then strips from the URL.
• A clearer error, and an audit trail. A missing cookie, an expired challenge and a spent one no longer share one sentence, and both failures are recorded in the audit log.

2.1.3

Sign-in bounced back to the login screen. Two defects, found together on a live site behind LiteSpeed Cache. Recommended for every site, and required for any site running a page cache.

• The idle timeout ended every session at the moment it began. The “last active” stamp was kept once per account and was never written at sign-in, so the first request after a fresh login read a timestamp from a session that had ended days earlier, decided the new session was idle, and logged it straight back out — before it could record that anything had happened. Nothing could break the loop: every sign-in, by every method, returned to wp-login.php?authdock_idle=1. Activity is now tracked against the session making the request, so a session that has just been created cannot be old, and one device’s activity no longer speaks for another’s. Upgrading clears the stale stamps.
• The login page could be cached. A page cache that had stored wp-login.php served it from disk without running PHP — so no cookies were set, the two-factor challenge token was never issued, and a correct code was answered with “Session expired”; nonces in the stored copy aged out; and a visitor who did sign in went on seeing the logged-out site. AuthDock now declares every authentication URL uncacheable on the first request that reaches it, so no copy is stored at all, registers its cookies with the caches that vary on them, keeps its scripts out of defer/delay optimisation, and purges the login screens on activation and upgrade.
• Site Health checks for it. A new diagnostic fetches the login page the way a visitor does and reports it if an edge cache is answering.
• AUTHDOCK_DISABLE_IDLE_TIMEOUT joins the break-glass constants.

2.1.0

Notification channels, and a pre-release audit. Alerts can now arrive by Telegram as well as by email, and a final audit before public release closed five defects that no automated test could have caught. Nothing is reset and no setting changes meaning; upgrading turns nothing on.

Notifications go somewhere other than email

• Delivery channels. Every alert used to end at wp_mail(). A handler now describes what happened and a dispatcher hands a copy to each channel the site has chosen. Email behaves exactly as it did.
• Telegram, in about four steps. Message @BotFather, paste the token, press Connect Bot; post in the chat you want alerts in, press Detect Chat. Then Send Test Message, which sends immediately so the answer on screen is what Telegram actually said.
• Chosen separately for administrators and for account holders — both, either or neither. An upgraded site has no such setting stored, and an absent setting means email.
• Account holders can connect their own, where a site allows it. Off by default: switching it on means storing a Telegram chat ID for each member who connects one.
• A third party adds a channel with one subclass and one filter.

Six providers that shipped and could not be reached

• Apple, Microsoft, LinkedIn, Discord, Twitch and Slack can now be configured at all. Their OAuth support arrived complete and correct, but four separate screens each carried a hand-written list of the original four providers — so there was no field to enter a client ID for any of the six, their sign-in buttons rendered as blank unlabelled rectangles with a broken image, the profile screen showed no sign an account was linked, and a link to one of them could not be removed. Every one of those screens is now built from the provider registry, and the six missing brand marks have been drawn.
• Connected accounts appear where the plugin said they would. The account centre’s connected-accounts list and the personal-data export both read a record that nothing had ever written, so the section was hidden on every install and a subject access request under-reported. It is written now.

Protection that was keyed on the CDN rather than the visitor

• Trusted Proxies has a settings field, on the Security screen where the documentation always said it was. It had no field anywhere, and the Site Health check that told you to set it read a different option than the code that used it — so following the advice exactly changed nothing.
• It accepts CIDR ranges and wildcards. It matched addresses exactly, which no site behind Cloudflare, Fastly or Akamai could ever satisfy, because they publish ranges.
• The visitor’s address is read from the correct end of X-Forwarded-For. Every CDN appends the address it saw to whatever the client sent, so the left-most entry — which is what was read — is a value the visitor chooses. Anyone behind a CDN could forge a fresh identity on every request and walk through lockouts, IP blocking and country rules. If you list a chain of your own proxies, name all of them; a single proxy is unaffected.
• CF-Connecting-IP and True-Client-IP are read, which Site Health had claimed since 1.1 and nothing did.
• The network-wide blocklist blocks. On multisite, an address a super admin blocked across the network was blocked on no site at all.
• A broken mailer no longer reveals which addresses have accounts. Every refusal on the magic-link form gave the same answer except a failed send, which only an existing account could produce. The failure is now recorded in the audit log instead.

Verification

• The proof-of-work check is now proven, not assumed. Bot protection defaults to proof-of-work, and the browser and the server carry independent SHA-256 implementations; if they ever disagreed by one bit, every visitor would be refused at the login form and no test would have noticed. The shipped solver is now run against the server’s verifier on every commit, and compared on tens of thousands of inputs.
• Passkeys are verified for every algorithm offered. RS256 — what a TPM-backed Windows Hello credential commonly produces — and EdDSA had accepted-but-unexercised code paths. Both now register and sign in under test with real keys.
• Two-factor codes are checked against RFC 6238’s own published vectors, so agreement with Google Authenticator, Authy and 1Password is anchored to the specification rather than assumed.

2.0.0

A major release. The admin is rebuilt, and three security fixes ship with it. Nothing about how people sign in changes and no setting is reset — upgrading moves screens around, it does not turn anything on or off.

The admin

• Twenty-four menu entries become seven. Related screens are grouped behind one entry with a rail down the side, and each panel keeps its own address — so the back button, a bookmark and a support link all still work. Old page=authdock-* links are redirected to wherever that screen lives now, with their query arguments intact.
• Setup is a stepper, one step at a time, reachable from the dashboard rather than only on first install — and it can be dismissed and brought back.
• A light and a dark theme, switched from the heading and remembered per person. Every colour on an AuthDock screen now comes from a token, so both themes stay consistent.
• The screens draw their own icons. Dashicons is an icon font drawn for the 2013 admin; all seventy-five icons are now inline stroke paths on the Lucide grid (ISC licensed), shipped with the plugin rather than fetched from anywhere. Six screens that had been sharing an icon with something unrelated get their own, and GitHub finally gets the GitHub logo.

Security

• Confirming your password is no longer something you can do all day. Turning off two-factor, regenerating backup codes, disconnecting a social account and removing a passkey all ask for your password first — precisely so that a stolen session is not enough to undo them. None of them counted the wrong answers, and none goes through the login limiter, so whoever held a hijacked cookie could guess at the password or the six-digit code as often as they liked. There is now a shared allowance across all of those screens; once it is spent the route stops answering, and every failure is logged.
• A suspended account can no longer finish a two-factor challenge it had already started. Suspension is checked when the password is submitted, which can be a quarter of an hour before the code is typed. Suspending somebody ended their sessions, and the challenge they had open handed them a new one.
• Saving every settings section at once no longer destroys your social login secrets. Reading the settings deliberately masks each OAuth client secret, and this one route wrote the mask back over the real value — so a save could silently break every configured provider. A new secret submitted there was also stored unencrypted, and a partial save erased the keys it did not mention. All three are fixed.

1.3.0

A large release. 1.1, 1.2 and 1.3 were milestones in the development plan and none of them shipped separately, so everything below arrives at once. Every new feature is off by default; upgrading changes nothing until you switch something on.

Passkeys

• Sign in with a passkey, or use one as a second factor. Passkeys are the only widely deployed factor that is phishing-resistant — the credential is bound to your site’s origin by the browser, so a proxy phishing kit that defeats app codes and SMS completely cannot relay one.
• No new dependencies: the CBOR parsing, key decoding and signature verification are all done on your own server with what PHP already has. Nothing is sent to any third party.
• Clone detection, credential-collision rejection, and a password required before adding or removing one.

Your account, on your own site

• A new account screen — [authdock_account] or the Account Dashboard block — showing where you are signed in, which devices skip the two-factor prompt, your passkeys, your connected accounts and your own recent security activity.
• End one session, not all of them. WordPress offers “log out everywhere else” and nothing finer, so somebody who left a session open on a shared machine had to end every session they had.
• Forget a remembered device, and the revocation is logged.

A block for every form

• Registration and password recovery finally have a block, a shortcode and a theme-overridable template, so a site that hides wp-login.php has somewhere to put them.
• Seven new blocks in all — registration, lost password, magic link, social buttons, account dashboard, log-out button, and conditional content that shows or hides what it contains by sign-in state, role or capability — plus patterns for a complete login page and a complete account page.
• jQuery is gone from the front end.

Bot protection

• Automated submissions are refused on the login, registration, password-reset and magic-link forms. Brute-force protection counts failures per address, which a distributed attack defeats by never repeating one; this raises the cost of each attempt instead.
• Three layers: a field no person can see, a floor on how fast a form can come back, and — only after an address has already failed — a challenge, so an ordinary visitor never meets one.
• The default challenge needs no third party and sends nothing anywhere. Cloudflare Turnstile, hCaptcha and reCAPTCHA are there for sites already using one.

Location and network rules

• Allow or refuse sign-ins by country, on the login form, registration or the dashboard, with a tighter rule per role.
• Refuse addresses on hosting networks, which stops a large share of automated attacks with almost no effect on ordinary visitors.
• Three guard rails against locking yourself out: your own address is exempted when you save, a rule that would block your own location is refused with the reason, and an address whose location is unknown is never blocked.

Passwords, scoring and mail

• Known-breached passwords are refused, checked with k-anonymity — the password never leaves your site and neither does its hash.
• A security score on the dashboard and a five-step hardening wizard, because the common failure is not misconfiguration: it is a site that installed a security plugin, switched nothing on, and believes it is protected.
• An optional weekly digest: the score, what changed, and the three things most worth doing next.
• Mail failures are no longer silent, and the plugin now tells you whether your domain publishes the SPF and DMARC records a receiving server checks — a message failing those is discarded with no bounce, which is how a magic link vanishes with nothing to see.

Recovery

• wp authdock on the command line: doctor, unblock, blocklist, recovery-link, 2fa, sessions, logs export, settings export|import, upgrade and bench.
• AUTHDOCK_SAFE_MODE and a constant for each control individually. Every control that can keep somebody out now has both a wp-config.php escape hatch and a CLI one.
• Site Health integration: twelve checks covering tables, lockout storage, secrets, outbound mail, sender authentication, cron and proxies.

Fixed

• Two-factor codes could be brute-forced, the attempt limit resetting on every login. It applies to the account now.
• The lockout screen and dashboard counters showed nothing on any site with a persistent object cache, while lockouts were actively blocking logins.
• Social login buttons and magic-link forms were invisible on WooCommerce and any other front-end login page — two headline features dark on a large share of installs.
• Application passwords, XML-RPC and REST authentication worked again with two-factor enabled; they had been receiving a chunk of the login page instead of a real response.
• Backup-code verification went from roughly a second of CPU to under a millisecond.
• Roughly eight database queries removed from every page load on a site with features switched off.
• Privacy: a personal-data exporter and eraser, an IP-anonymisation setting, and a documented record of every field stored.
• Accessibility: inline handlers and inline styles removed throughout, live regions that screen readers actually announce, and a notice that no longer removes itself after five seconds.
• Full details of all 75 findings, including the ones deliberately not fixed and why, are in the plugin’s docs/fix-and-improve directory.

1.0.3

Security release — everyone should update.

• Fixed: social login could take over an existing account. An OAuth identity was matched by email address alone, without checking whether the provider had verified it. A provider-verified address is now required, and accounts with elevated capabilities are never linked automatically — they must be connected from the profile screen.
• Fixed: OAuth login CSRF. The state parameter was identical for every logged-out visitor and was never consumed, so a captured callback could sign a victim into an attacker’s account. Each sign-in now gets its own single-use value.
• Fixed: “Restrict REST API to authenticated users” was bypassable by adding the plugin namespace to any query string. Matching is now done on the resolved route.
• Fixed: two-factor codes could be brute-forced, because the attempt limit reset every time the login form was re-submitted. The limit now applies to the account.
• Fixed: an IP-list entry with a missing range prefix, such as 10.0.0.0/, silently matched half the internet. Such entries are now rejected and named in an admin notice.
• Fixed: PKCE is now sent to every OAuth provider, not only X.
• Fixed: the two-factor challenge token no longer travels in the URL, where it leaked into browser history, Referer headers, and access logs.
• Fixed: a mistyped code during two-factor re-enrolment destroyed the working secret.
• Fixed: failed and successful two-factor attempts are now recorded in the audit log.
• Fixed: a blocked IP could grow the audit log without bound.
• Fixed: with two-factor enabled, application passwords now work. REST and XML-RPC authentication previously received a chunk of the login page instead of a real response, breaking the WordPress mobile apps, Jetpack, backup tools, and headless front-ends.
• Fixed: AUTHDOCK_VERSION was left at 1.0.0 through earlier releases, so browsers never re-fetched updated CSS or JavaScript.
• Note: users whose social provider reports an unverified email, and users with elevated roles, will need to log in with a password once and connect their social account from their profile.

1.0.2

• Documentation only. No plugin code changed.

1.0.0

• Initial release
• Social Login with Google, Facebook, GitHub, and X (Twitter) via OAuth 2.0
• Magic Link passwordless login with configurable expiry, rate limiting, and force-magic mode
• Two-Factor Authentication — TOTP (RFC 6238) and email-based 2FA with encrypted secret storage, backup codes, trusted devices, and per-role enforcement
• Brute force protection with configurable attempts, progressive lockout escalation, IP whitelist/blacklist with CIDR and wildcard support, and auto-blacklist
• Dynamic login/logout redirects with per-role configuration and first-login redirect
• Comprehensive audit logging to custom database table with retention, filters, CSV/JSON export, and auto-cleanup
• Security hardening — custom login URL with recovery key, XML-RPC control, REST API restriction, user enumeration prevention, password strength enforcement, and 6 security HTTP headers
• wp-admin access control with role-based and IP-based restrictions, admin bar hiding, emergency bypass key, and smart AJAX/cron exceptions
• Session management — concurrent session limiting, idle timeout, per-role session duration, admin session viewer, and remote termination
• Email notification system with 8 admin triggers, 6 user self-notification triggers, configurable throttling, custom recipients, and test email
• REST API namespace authdock/v1 with 15+ endpoints for all data operations
• 5 custom capabilities for granular permission control
• Full i18n support with .pot file
• WordPress.org compliance — GPL-2.0+, no tracking, no encoded code, third-party service disclosure