SiteFort security guide

WordPress Login Security

Recommended SiteFort settings for WordPress login protection, password policies, custom login URLs, and two-factor authentication, with guidance for WooCommerce and membership sites.

Security Guide Hardening Docs

Login form protection

Go to SiteFort → Hardening → Login Security.

WordPress login pages are continuously tested by automated bots using leaked passwords, common usernames, and credential-stuffing lists. The goal is to reduce how many attempts those systems can make without creating unnecessary friction for legitimate users.

Setting	Recommended value	Watch out for
Limit Login Attempts	On	Start with moderate limits and tighten them based on real traffic. Very low thresholds can create unnecessary lockouts for legitimate users.
Failed attempts per IP	5	Offices, schools, mobile networks, and other shared connections may place many users behind the same public IP address.
Failed attempts per user	5 to 10	Set this slightly higher than the per-IP threshold so a legitimate user who has forgotten a password has some room to recover access.
Detection window	15 minutes	A shorter window allows repeated attempts to reset sooner. A much longer window can increase false lockouts.
Lockout duration	30 minutes	This is usually long enough to interrupt automated attacks without creating excessive disruption for legitimate users.
Bot Detection (CAPTCHA)	Enable when bot activity is confirmed	After enabling CAPTCHA, test login, registration, and password reset. WooCommerce sites should also test My Account, registration, and checkout.
Restrict Login Identifier	Email only for most business sites	Confirm every user has a valid email address associated with the account before disabling username-based login.
Block Default Admin Username	On, if no real account uses "admin"	If an existing account still uses the username `admin`, change that account first. This setting blocks login attempts but does not rename existing users.
Obfuscate Login Error Messages	On	Generic login errors prevent an attacker from using the response to confirm whether a particular username or email address exists.

WooCommerce, LMS, and membership sites: use moderate lockout settings during rollout. Customers, students, and members typically log in less often than administrators and are more likely to mistype or forget credentials. Start with 5 attempts per IP and a 30-minute lockout, then review Lockouts and Recovery before making the policy stricter.

Custom login or registration forms: standard WordPress forms can use SiteFort's built-in CAPTCHA protection. If your site uses a custom frontend form from a membership plugin, page builder, or custom code, additional CAPTCHA integration may be required. See the Custom Form CAPTCHA documentation.

Custom Login URL

Go to SiteFort → Hardening → Login Security → Custom Login URL.

Changing the default /wp-login.php path is not a substitute for strong authentication. Its main benefit is reducing automated traffic against the standard WordPress login endpoint. That can lower unnecessary request volume, reduce repetitive login noise, and make unusual access patterns easier to identify.

Before enabling: confirm that you have another way to access the server, such as the hosting control panel, SFTP, SSH, or a file manager. Keep a secure record of the new login URL before changing the default path.

Option	Recommended
Login slug	Use a private, non-obvious value and record it securely before saving the setting.
Register slug	Configure this only if public WordPress registration is enabled.
Default wp-login.php response	403 or 404. Either response prevents the default endpoint from functioning as the public login location.
Redirect	Leave disabled unless you have a specific requirement. An incorrectly configured redirect can expose the replacement login URL.

Good and bad login slug examples

Good slugs

/team-entry-472
/client-access
/private-dashboard-entry
/staff-portal-9x

Avoid these

/login
/admin
/secure-login
/wp-login-new
/signin

Common variations such as /login and /signin are routinely checked by automated scanners, so they provide little value as replacement paths. If the site uses WooCommerce, a membership plugin, an LMS, or another frontend authentication system, test those login flows after changing the WordPress login URL. Plugins that link directly to /wp-login.php may need to be reconfigured.

Password policies

Go to SiteFort → Hardening → Login Security → Password Policies.

Weak and reused passwords remain one of the most common paths to WordPress account compromise. SiteFort password policies are designed to address the behaviors that create the most risk without forcing unnecessary password changes on users who are already using strong credentials.

Policy	Recommended	Watch out for
Breached Password Detection	On	Users whose passwords are found in known breach data are prompted to replace them. Make sure your support team understands why the reset is being required.
Enforce Strong Passwords	On	This applies when a password is created or changed. It does not automatically replace an existing weak password unless another policy requires a reset.
Prevent Password Reuse	On for business, ecommerce, and agency sites	Prevents users from immediately reusing their current password during a password change.
Require Password Change on Role Promotion	On	Users promoted to higher-privilege roles such as Administrator or Editor are required to establish a fresh password at their next login.
Password Expiration Policy	Off for most sites	Periodic password expiration can encourage predictable password variations. Enable it when required by compliance, contractual obligations, or an internal security policy.

Two-factor authentication

Go to SiteFort → Hardening → Two-Factor (2FA).

Two-factor authentication protects a WordPress account even when the password has been stolen, reused, guessed, or captured through phishing. It should be required for privileged accounts and strongly considered anywhere an account provides access to customer, business, membership, or order data.

Which roles to require first

Role	Recommendation
Administrator	Required on every production site. Administrator accounts have full control over WordPress, plugins, themes, users, and site configuration.
Editor	Required for business, publishing, ecommerce, and agency-managed sites where Editors can publish or modify public content.
Shop Manager	Required when WooCommerce is active. Shop Managers may have access to orders, customer data, products, and store operations.
Author	Optional for smaller sites. Consider enforcement on publishing platforms where an Author account can publish content without further review.
Subscriber / Member	Optional for ordinary accounts. Consider requiring 2FA when member accounts contain sensitive personal, billing, educational, or business information.

How the 2FA policy settings work

The 2FA settings control different parts of the policy. In particular, allowing a method is not the same as requiring a role to use 2FA.

Setting	What it controls	Recommended value
Allowed methods	Which 2FA methods users can choose when they enroll.	Enable Authenticator App and Email Code for most sites. Prefer authenticator apps for administrators and other privileged users.
Enforced roles	Which WordPress roles must configure and use 2FA.	Require Administrator first, then add Editor, Shop Manager, or other privileged roles based on the site.
Grace period	How long an enforced user has to configure 2FA before setup becomes mandatory.	3 to 7 days for existing teams. Use 0 only when immediate enrollment is appropriate and affected users are prepared.
Remember device	How long a verified browser remains trusted before another 2FA challenge is required.	7 to 30 days for most sites. Use shorter periods for higher-risk environments or shared devices.

Recovery codes

Every administrator should generate and securely store recovery codes before 2FA enforcement is enabled. Recovery codes provide an alternative way to verify an account when the normal authenticator or email method is unavailable.

Recovery codes are single-use credentials and should be stored separately from the WordPress account. Administrators should test one recovery code during rollout so the recovery process is understood before it is needed.

Authenticator apps are the recommended default for administrators, developers, and other privileged users. Email Code is a practical option for customers, members, clients, and users who may not maintain an authenticator application.

Agencies managing client sites: configure 2FA for administrator accounts before handoff and include recovery-code storage in the handoff process. Confirm that the client understands which roles are enforced and how account recovery will be handled.

WooCommerce and membership sites

Customer-facing sites need a clear way for users to manage their own 2FA without entering the WordPress administration area.

WooCommerce

When SiteFort two-factor authentication is enabled and WooCommerce is active, SiteFort automatically adds My Account → Account security. Customers can use that area to enroll in 2FA, change their method, generate recovery codes, or disable 2FA when the site's policy allows it.

The normal WooCommerce login page remains available. For enrolled users, SiteFort verifies the password first and then requires the second factor before authentication is completed.

No WooCommerce template changes are required. After enabling 2FA, sign in with a test customer account and confirm My Account → Account security is available and working as expected.

Membership and custom account pages

If your membership plugin, LMS, customer portal, or frontend dashboard uses its own account page, SiteFort can also make the user's 2FA controls available there.

Because custom account implementations vary, follow the 2FA integration documentation for the account-page setup and compatibility details.

Before enforcing 2FA

Test the complete login and recovery flow before requiring 2FA for production users.

Test Authenticator App and Email Code if both methods are enabled.
Generate and securely store recovery codes, then test one.
Confirm WooCommerce customers can access My Account → Account security.
Verify transactional email delivery before relying on Email Code.
Confirm enforced users can complete enrollment before the grace period expires.
Test any membership or custom frontend login flow before enforcing 2FA for those users.
Avoid enabling overlapping 2FA enforcement in another WordPress security or authentication plugin.