ETBS Account Guard

Description

WordPress shows the login names of your users, or names made from them, in several places that anyone can reach without logging in: the REST API, oEmbed, the user sitemap, the ?author= redirect and the messages of the login screen. Once a login name is known, only the password is left to guess.

ETBS Account Guard closes these places. Each one can be turned on or off from Settings > ETBS Account Guard.

What it covers

• REST API – The user endpoints (/wp/v2/users and everything below it) are removed for visitors who are not logged in, including the author data embedded with _embed. An existing user ID and a missing one give the same response. Logged-in users, including the block editor, are not affected.
• oEmbed – The author name and author URL of embedded posts are replaced with the site name and the home page URL.
• Sitemap – The user sitemap (wp-sitemap-users-1.xml) is removed.
• Class names – comment-author-{name} on comments by registered users and author-{name} on author pages are removed. Class names that contain the user ID are kept.
• Author ID links – /?author=1 goes to the home page instead of the author page. The admin screens are not affected.
• Login errors – An unknown username and a wrong password show the same message. Failed application password (Basic authentication) requests to the REST API get the same error. On the lost password screen, an unknown username or email address shows the same screen as a registered one. Registered users receive the password reset email as before. Errors from other plugins, such as CAPTCHA or login lockout, are shown as they are.
• Author pages (off by default) – Author pages (/author/{name}/) return 404 for visitors who are not logged in. Before turning this on, open a post on your site and click the author name. If a page whose address contains /author/ opens, your theme links to author pages, and those links will lead to “Page not found”. Logged-in users still see author pages, so check the result in a private window of your browser.
• Public names – The settings screen lists users whose display name or nickname is the same as their login name, so that you can change them. Nothing is changed automatically.

Access Restriction (IP restriction)

On the Access Restriction tab of Settings > ETBS Account Guard, you can require an IP address check for a role, for a specific user, or both. The administrator role itself is always unrestricted; a specific administrator can still be restricted from their own user edit screen. A user’s own setting always wins over their role’s setting, and a user held to more than one requirement (through more than one role) must satisfy all of them.

• At login (wp-login.php, XML-RPC, and anything that authenticates a username and password) – a restricted account connecting from an address not on its allowed list is refused with the same message as a wrong password; the reason is never revealed. This is judged after any CAPTCHA plugin (such as SiteGuard WP Plugin) has already run, so a CAPTCHA failure and an IP restriction never look different from each other.
• On every later request (the admin screens, admin-ajax.php, admin-post.php, the front end and the REST API) – a restricted account connecting from a disallowed address has only that one session discarded; the request continues as if signed out. Nothing is blocked with an error page, so public pages and forms that do not require sign-in keep working normally.
• Application passwords are turned off for a restricted user, checked again on every REST API request.
• The IP list combines one site-wide list with any addresses added just for one user. Each line is a single IPv4 or IPv6 address or a range in CIDR notation; text after # is a note. Only the address the server itself sees for the connection (REMOTE_ADDR) is used; headers such as X-Forwarded-For are never read, since a visitor can set those themselves.
• Saving the Access Restriction tab, or a user’s own restriction on their user edit screen, is refused (with an explanation) if it would leave no unrestricted administrator (or other user who can manage options), if it would lock out the very access you are saving from, or (for BASIC authentication, see below) if a user who would end up in that mode has not set their own credentials yet.
• The last 100 denials are listed on the Denial Log tab.
• If Access Restriction ever malfunctions, it turns itself off and shows a warning on the Access Restriction tab and, on other admin screens, as an admin notice, rather than locking anyone out by mistake.

Access Restriction (BASIC authentication)

BASIC authentication is a third mode, alongside “no restriction” and “IP restriction”, for a role or a specific user. It asks for a separate username and password (not the WordPress login) with a native browser sign-in prompt, on top of your normal WordPress login.

• Credentials – Each user has their own BASIC authentication ID and password, set on their user edit screen. The ID must be unique on the site; the password is never shown again once saved.
• Confirmation screen – Once signed in, a BASIC-mode user who has not yet supplied the BASIC credentials for this browser session is sent to a screen that triggers the browser’s own username/password prompt (not a custom login form). Answering it correctly returns them to the admin page they were trying to reach.
• The WordPress session is kept – Unlike IP restriction, a missing or wrong BASIC credential only makes that one request anonymous; it does not sign the user out.
• Setting up your own account – Open your own Profile screen (also reachable from the toolbar or the admin menu). The same Access Restriction section shown here for other users appears there too, for anyone who can manage options. Before saving BASIC authentication mode for yourself, click “Verify” to confirm your new ID and password through a real sign-in prompt.
• Receive diagnosis – Some server setups do not pass the BASIC authentication header through to WordPress, or already use BASIC authentication for the whole site at the server level. The Access Restriction tab has a diagnosis to check this; BASIC authentication mode cannot be turned on until it succeeds. A .htaccess snippet is shown for servers that need it, for you to review and add yourself — this plugin never edits .htaccess automatically.
• HTTPS is recommended – BASIC authentication sends the username and password with every request. A warning is shown when the site is not using HTTPS, but saving is still allowed.

Two-Step Verification (verification code by email)

On the Two-Step Verification tab of Settings > ETBS Account Guard, you can require a verification code, sent to the user’s registered email address, after the password has been accepted. It is off by default (see the FAQ).

• Who needs a code – Choose “None” or “Verification code (email)” for each role, including administrator, and override it per user on the user edit screen. A user’s own setting wins; with several roles, any one requiring a code is enough. Only users who can manage options can change this.
• Separate from Access Restriction – A user held to both goes through both: the password and IP restriction first, then the verification code, then BASIC authentication on the next screen.
• The code – Six digits, valid for 10 minutes, stored only as a hash. 5 wrong entries restart the sign-in from the password. At most 5 emails per user per hour, 60 seconds apart; a new code replaces the previous one. Accounts are never locked. Full-width digits, spaces and hyphens are accepted.
• Where it applies – Any login form that goes through WordPress’s wp_signon(), including WooCommerce My Account. No login cookie is issued before the code. Sign-ins that cannot show the code screen (XML-RPC with the ordinary password, AJAX sign-ins and similar; except from a trusted device, never for XML-RPC) get the same message as a wrong password, and the user is emailed (not for XML-RPC).
• Application passwords keep working for the REST API and XML-RPC without a code (they can only be created while signed in). The settings tab and the user edit screen show how many each user has.
• Trusted devices – A user can choose on the code screen to skip the code on that browser for 7 or 30 days (set on the tab, or turned off). Only the code is skipped: the password is needed every time. Changing the password revokes every trusted device of that user. See the FAQ for details.
• Sessions – Sessions from before the feature was turned on, and sessions created by other plugins’ sign-in methods, are signed out on their next request (see the FAQ).
• Turning it on for yourself requires confirming first that your own email address receives codes (see the FAQ). Turning it on for someone else requires a valid email address.
• Emails are plain text, without links, in the user’s own language, and the code is never in the subject. They are sent from your site’s usual sender address.
• Denial log – Wrong or expired codes, limits, refused sign-ins, failed emails and discarded sessions are added to the Denial Log tab.
• If its settings are broken, it still asks users set to a code and users who can manage options for a code (others can sign in) and shows a warning. Unlike Access Restriction, it never turns itself off.

Emergency switch

If Access Restriction ever locks everyone out, add define( 'ACGD_DISABLE_RESTRICTION', true ); to wp-config.php. This stops Access Restriction only; Login Name Protection keeps working.

If nobody can sign in because verification codes do not arrive, add define( 'ACGD_DISABLE_TWO_STEP', true ); to wp-config.php. This stops Two-Step Verification only; Access Restriction and Login Name Protection keep working. Define it also on a copy of your site whose email sending is turned off. When the switch is taken off again, users who need a code and signed in while it was on are signed out once on their next request. The two switches are independent. While a switch is on, a warning is shown on the admin screens.

What it does not do

Authenticator apps (TOTP), login attempt limits, CAPTCHA and firewalls are not included. Two-Step Verification is limited to a code sent by email. Use a dedicated security plugin for the others. The ?author= redirect and the login messages overlap with some of those plugins; having both does no harm.

Known limitations

• The lost password form of WooCommerce My Account shows its own messages and is not covered. The WooCommerce login form is covered.
• Links to author pages that your theme prints still contain the name used in the author page URL.
• If you also use SiteGuard WP Plugin, keep its “Same Login Error Message” setting turned on (it is on by default on a single site). When it is off, the CAPTCHA error message of SiteGuard appears only for existing accounts, and separately, only for a restricted account’s own IP restriction. This is how SiteGuard itself behaves, and this plugin cannot change it.
• On the lost password screen, when the email to an existing account cannot be sent, that error is shown as it is, so that problems with sending email on your site are noticed. This error, and the difference in response time between sending an email and not sending one, remain.
• On the login screen, WordPress checks the password only when the account exists, so the response time can differ between an existing account and an unknown one. Like the difference in response time on the lost password screen, this is not addressed yet.
• Whether the BASIC authentication confirmation screen (the browser’s native sign-in prompt) can be shown on a device that goes through a corporate remote browser isolation service is untested; check this yourself before relying on it at such a site.
• Two-Step Verification is only as strong as the user’s email account. Password reset emails go to the same inbox, so anyone who controls the inbox can get past both the password and the code. Use it for users whose email account is protected with multi-factor authentication. Password reset is not blocked, to avoid adding another way to be locked out.
• Two-Step Verification does not protect against relay (adversary-in-the-middle) phishing sites, or against someone who persuades the user to read out the code. The email says never to share it.
• Someone who knows a user’s password can use up that user’s hourly sending limit and keep them out for up to an hour. Changing the password releases the limit. A trusted device can still sign in.
• Anyone who has both a user’s password and the trusted device cookie of that user’s browser can sign in without a code until the trust ends or the password is changed. A browser remembers one trusted device per site.
• Repeated attacks can push older entries, including IP restriction and BASIC authentication denials, out of the Denial Log (the latest 100 are kept).
• Application passwords do not go through Two-Step Verification.
• Users who need a code cannot use sign-in methods of other plugins (magic links, social login and so on).
• Two-Step Verification is not available on multisite.
• The save-time checks of Two-Step Verification (your own receive check, a valid email address for others) run only on the Two-Step Verification tab and the user edit screen. A role or email address changed elsewhere (bulk role changes on the Users screen, the REST API, WP-CLI, imports) is not checked, and a user who needs a code but has no working email address can then no longer sign in.
• Two-Step Verification is not meant for roles with many users, such as the WooCommerce customer role: the save-time checks read every user of the chosen roles.
• Do not combine it with another two-factor plugin for the same user. Plugins that recreate the session during sign-in (such as Two Factor) create a session without this plugin’s mark, which is then signed out.