AuthDock

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

WordPress

Security

Hi Product Hunt 👋 I'm Rakib. I build WordPress tools at Degird, and AuthDock is the one I most needed myself. Here's the problem it came from. A WordPress site that wants proper authentication ends up with four or five plugins that don't know about each other: one for social login, one for 2FA, one for brute-force, one for logging. They duplicate settings, they disagree about who the visitor even is — each reads the client IP its own way, and behind Cloudflare at least one of them is wrong — and none of them can tell you whether the site is actually protected. AuthDock is all of it in one plugin, with one audit log, one idea of the visitor's address, and a score out of 100 that says how you're doing. Four decisions I'd defend, and would genuinely like to be argued with about: 🔸 Everything ships switched off. Activating changes nothing about how your site logs people in. Upgrading never turns anything on. Turning a feature on is your decision, every time. 🔸 Nothing phones home. No telemetry, no usage reporting, no licence check. With every feature off, the plugin makes no outbound request at all. Risk scoring, breach checking (by k-anonymity — five characters of a hash, never the password), geolocation and analytics all run on your own server. Ten features can contact a third party, each only when you switch it on and supply your own credentials, and all ten are listed by name in the readme. 🔸 Every control that can lock you out has a documented way back in — a wp-config.php constant, a `wp authdock` command, and a recovery route that needs no database access. AUTHDOCK_SAFE_MODE lifts hardening wholesale, and it fails open on hardening and never on authentication: it admits nobody who couldn't get in before, and a second factor somebody chose to set up still applies. The dashboard nags at you the whole time a control is lifted, because an emergency measure nobody removes is a permanent hole. 🔸 A protection that can't run fails open, and says so. A CAPTCHA provider outage, an unreachable breach service, a corrupt geolocation database — each lets the request through and writes the outage to the audit log. A login outage is worse than a missed check. (The audit log itself is tamper-evident, not tamper-proof: anyone holding the database *and* the salts can rebuild the chain. What it defeats is somebody deleting the row that names them.) The last release, 2.1.6, was a full pre-release audit of every module, and I'd rather show you the uncomfortable part than bury it: several controls reported themselves as protecting a site while doing nothing. Location rules and bot protection both refused *before* WordPress checks the password, and core discards an earlier refusal once it's handed a valid username and password — so a correct password beat both. The GeoLite2 reader resolved pointers sixteen bytes early, so every lookup said "no data", and a rule with no data allows everyone, which made the failure completely silent. It's all written up finding by finding in the changelog, alongside the internal audits in docs/fix-and-improve/ — including findings I decided not to fix, and why. It's free and GPLv2. Not freemium, not a free tier — there is no paid version and no upsell in the UI. I'll be here all day. The most useful thing you can leave me is the setup that breaks it: an odd reverse proxy, a page cache doing something clever with the login URL, a multisite network, an OIDC provider whose discovery document isn't quite to spec. Bug reports over compliments, please. 🙏 (One ask: if you find an actual vulnerability, please don't post it here — there's a private advisory route in the security policy, and I'll credit you in the release notes.)