Smart Protector is a WordPress plugin that hardens the way you log into your site’s dashboard. It’s built by BeeClear, the developer of WordPress plugins and mobile apps. Two-factor authentication means logging in with a password plus an extra, one-time code from your phone — 2FA for short. This article covers one mechanism in the plugin: a hard gateway that won’t let an account through without a code, by any side route. See how it works and how to turn it on without risking a lockout.
Table of contents
- Why isn’t 2FA in the login form alone enough?
- What is the hard dashboard gateway in Smart Protector?
- What happens to XML-RPC and application passwords when 2FA is on?
- What does logging in through the gateway look like, step by step?
- How does Smart Protector protect the TOTP codes themselves?
- Where can you check who has passed 2FA verification?
- Can the gateway get stuck in a loop or reject valid codes?
- What to do when a user loses their authenticator app?
- How do you turn on the 2FA gateway on your site?
Why isn’t 2FA in the login form alone enough?
2FA in the login form alone isn’t enough, because WordPress handles accounts through other routes too. Alongside the standard login screen, admin-ajax, the REST API, XML-RPC, and application passwords are all active. XML-RPC can’t ask for a code, so a username and password could bypass the second factor entirely. Application passwords, in turn, authenticate without a browser session.
Each of those routes is like a side gate in a fence that looks solid from the front. Why force the main gate when an open passage stands right next to it? A stolen password is then enough to act on the account. So the extra code only protects as well as the weakest entry point into the site. Protection has to cover every route, not just the most visible one.
What is the hard dashboard gateway in Smart Protector?
The hard dashboard gateway is a server-side checkpoint that Smart Protector places in front of the WordPress dashboard. Until a session passes verification, the dashboard, admin-ajax, and the REST API all refuse to serve the account. The block runs on the server side, not in the interface. So it stops automated attempts too, not just button clicks. The plugin doesn’t touch .htaccess, wp-config.php, or the theme in the process.
The checkpoint renders its own standalone page and ends the request before the dashboard gets a chance to load. The user sees a simple screen with a field for the code. They won’t see the menu, the post list, or settings. Only a correct verification opens the way forward for that session. Verification applies to that specific session, so every subsequent login requires the code again.
What happens to XML-RPC and application passwords when 2FA is on?
Smart Protector treats XML-RPC and application passwords firmly: it rejects them for accounts covered by 2FA. Since XML-RPC can’t ask for a code, an attempt through that route ends in denial. The REST API only accepts application passwords for an account whose session has passed the checkpoint. That includes the WordPress mobile app, which connects over XML-RPC.
Sometimes an integration genuinely needs that entry point. For that case, the plugin offers two developer filters, one each for XML-RPC and the REST API. Returning false in them lets the chosen account through. That’s a deliberate decision, since the second factor gets skipped in the process. By default, every side door stays closed.
Here’s how the plugin treats each route to an account with 2FA enabled:
| Route to the account | What Smart Protector does | Why |
|---|---|---|
| WordPress dashboard | opens it only after a correct code | the session must pass verification |
| admin-ajax | refuses to serve the account | background requests don’t bypass verification |
| REST API and application passwords | refuses until the session is verified | application passwords work without a browser |
| XML-RPC | rejects the login | this route can’t ask for a code |
What does logging in through the gateway look like, step by step?
Logging in through the gateway follows a fixed order: password first, then code. Here’s the user’s path from entering the password to reaching the dashboard:
- you enter your username and password, even at your own hidden login address,
- if the password rotation deadline has passed, the plugin first asks for a new one,
- then you enter the six-digit code from your authenticator app,
- once the code is correct, the session is verified and the dashboard opens.
An account that requires 2FA won’t get stuck in front of a code field with no code to give. When the secret is missing, the verification screen always shows a form to generate one. It doesn’t matter whether the administrator enforced 2FA or the user turned it on themselves. You generate a key, add it to your authenticator app, and confirm with the first code.
How does Smart Protector protect the TOTP codes themselves?
TOTP codes — one-time, time-based codes compliant with RFC 6238 — are protected by Smart Protector with several layers. The plugin accepts a ±1 time-step window, and a code that’s already been used won’t work a second time. Code entry attempts are counted by a separate counter, independent of the password counter. It counts them separately per IP address and per username, with a countdown visible on the login screen.
The keys themselves aren’t left in plain view either. The users table shows them masked, and the administrator has to deliberately click “Reveal secret” to see them. After the page reloads, the value disappears again. Generating QR codes via external services is disabled by default, because the image URL contains the secret key. Aside from that option, the plugin sends nothing outside your site.
Where can you check who has passed 2FA verification?
You can check who has passed 2FA verification in the security log, the “Smart Protector > Security log” screen. It records successful and failed 2FA verifications, as well as hitting the code attempt limit. The log also records generating, revealing, manually replacing, and resetting a TOTP key. Every entry has a timestamp, account name, detected IP address, and a short description of the event. The screen has server-side pagination, and you can clear the whole log with one button.
The log doesn’t balloon during a dictionary attack. Events reach the database as a single record per request. Once the attempt limit is already blocking an attacker, their further attempts stop being logged. The log size also has an upper limit, 200 entries by default.
Can the gateway get stuck in a loop or reject valid codes?
The gateway doesn’t fall into a redirect loop, even when a cache or proxy strips its marker from the URL. After two redirects it renders in place, instead of bouncing the browser back and forth forever. The rate-limit settings also have upper bounds: a limit window of up to 24 hours and at most 100 attempts. A typo when entering the values won’t lock you out for days, then. An attempt beyond the limit is rejected immediately, with no artificial delay.
If your phone shows correct codes and the plugin keeps rejecting them, check the server clock. TOTP tolerates a discrepancy of around 30 seconds, and anything larger invalidates every code. The “Current protection” panel shows the server time in UTC, so you can compare it against a trusted clock. Drift gets fixed by your host through NTP time sync, not a plugin setting.
What to do when a user loses their authenticator app?
When a user loses their authenticator app, the administrator resets their 2FA on the “Smart Protector > Global settings” screen. They find the account in the users table and choose “Reset 2FA,” then “New secret.” The new key invalidates the existing entry on the phone, so the button asks for confirmation. The user then adds the account again and logs in with a fresh code.
In case the administrator gets locked out, emergency routes remain. You can clear an account’s 2FA verification via WP-CLI by wiping its metadata. The last line of defense is deactivating the plugin, for example by renaming its directory over SFTP. Settings and secrets are preserved in that case, unless the data-deletion option was checked.
How do you turn on the 2FA gateway on your site?
You turn on the 2FA gateway in the Smart Protector settings, on the same “Global settings” screen. In the users table, you can enforce the second factor for chosen accounts, while everyone else can activate it themselves in their profile. It’s sensible to start with the accounts that have the broadest permissions. If you’re also hiding the login screen, bookmark the new address before you log out.
From that point on, the password stops being the only key to your WordPress site, and no side door can replace it. You’ll find a description of every module on the Smart Protector plugin page. Contact us, and we’ll help you roll out this protection with no risk of getting locked out.
