Login Security
Recommended settings for login protection, custom login URL, password policies, and two-factor authentication. Covers what to enable and how to tune it for your site type.
Login form protection
Go to SiteFort → Hardening → Login Security.
The WordPress login page is hit constantly by bots testing leaked credentials and common usernames. Login limits, locked-out error messages, and CAPTCHA stop most of this before it becomes a problem.
| Setting | Recommended value | Watch out for |
|---|---|---|
| Limit Login Attempts | On | Start with moderate thresholds before tightening. Too strict on day one creates support tickets from real users who mistype passwords. |
| Failed attempts per IP | 5 | Offices, schools, and shared networks share one IP. If multiple real users share an IP and one of them triggers a lockout, everyone on that IP is locked out. |
| Failed attempts per user | 5 to 10 | Set slightly higher than per-IP to reduce accidental lockouts for users who genuinely forgot their password. |
| Detection window | 15 minutes | Good balance for most sites. Shorter windows can make the threshold feel more forgiving to bots; longer windows increase false lockouts. |
| Lockout duration | 30 minutes | Long enough to stop most automated attacks without creating hours-long support issues for real users. |
| Bot Detection (CAPTCHA) | Enable when bot activity is confirmed | Test the login page, registration page, password reset page, and any custom login form after enabling. WooCommerce My Account and checkout pages also need testing. |
| Restrict Login Identifier | Email only for most business sites | Username-only or both-allowed gives bots a second way in. Email-only works well when your users have a single registered email per account. |
| Block Default Admin Username | On, if no real account uses "admin" | Rename the admin account first if one exists. This setting only blocks login attempts using that username; it does not rename existing accounts. |
| Obfuscate Login Error Messages | On | Nothing to watch. Generic error messages give attackers no signal about whether a username exists. |
Custom Login URL
Go to SiteFort → Hardening → Login Security → Custom Login URL.
Replacing the default /wp-login.php path with a private URL cuts the noise from bots that attack well-known WordPress login paths. It is not a security measure on its own, but it reduces log clutter and server load from automated attacks that never find the form.
| Option | Recommended |
|---|---|
| Login slug | Private and non-obvious. Write it down somewhere safe before saving. |
| Register slug | Only configure this if the site has public user registration enabled. |
| Default wp-login.php response | 403 or 404. Either stops bots from confirming the path exists. |
| Redirect | Avoid unless there is a specific reason. A redirect can hint at the new login location if not handled carefully. |
Good and bad login slug examples
/team-entry-472/client-access/private-dashboard-entry/staff-portal-9x
/login/admin/secure-login/wp-login-new/signin
If the site uses WooCommerce, a membership plugin, an LMS, or any plugin with a frontend login form, test those login flows after enabling. Plugins that redirect to /wp-login.php directly may need updating to use the new path.
Password policies
Go to SiteFort → Hardening → Login Security → Password Policies.
Weak and reused passwords are behind a large share of WordPress account compromises. These settings do not ask every user to rotate passwords constantly; they focus on blocking the most dangerous password behaviors at the moment they happen.
| Policy | Recommended | Watch out for |
|---|---|---|
| Breached Password Detection | On | Users with breached passwords are prompted to reset on next login. Prepare a short explanation in case they contact support asking why they are being asked to change a password they consider fine. |
| Enforce Strong Passwords | On | Only applies at the point of setting a new password. Existing weak passwords are not forced out immediately unless Breached Password Detection also flags them. |
| Prevent Password Reuse | On for business, ecommerce, and agency sites | Nothing to watch for most sites. Users cannot reuse their current password when resetting. |
| Require Password Change on Role Promotion | On | Affects users promoted to Administrator or Editor. They are asked to set a new password on next login. Low friction, high value. |
| Password Expiration Policy | Off for most sites | Forced periodic rotation tends to result in weaker passwords over time as users pick easier-to-remember variations. Enable only if an internal policy or compliance requirement specifically demands it. |
Two-factor authentication
Go to SiteFort → Hardening → Two-Factor (2FA).
Two-factor authentication stops account takeovers even when a password has been stolen, guessed, or phished. It is one of the highest-value settings in SiteFort for any site with administrator or editor access.
Which roles to require first
| Role | Recommendation |
|---|---|
| Administrator | Required. No exceptions on a production site. |
| Editor | Required for business, publishing, ecommerce, and agency-managed sites. |
| Shop Manager | Required if WooCommerce is active. Shop Managers have access to order data and customer information. |
| Author | Optional on most sites. Required on high-volume publishing sites where a compromised author account could push malicious content. |
| Subscriber / Member | Optional unless accounts hold financial, medical, educational, or other sensitive personal data. |
Recommended 2FA settings
| Setting | Recommended value | Watch out for |
|---|---|---|
| Allowed methods | Authenticator App and Email Code | Keep both enabled. Removing Email Code leaves users who cannot use an authenticator app with no fallback during the rollout period. |
| Grace period | 3 to 7 days for teams | Gives existing users time to set up 2FA before they are locked out. Set to 0 only when enforcing for a single administrator account where you control the setup. |
| Remember device | 7 to 30 days | Longer remember periods reduce friction for users logging in from trusted devices. Shorter periods increase security but generate more support requests on membership and LMS sites. |
Recovery codes: do this before enforcing
Every administrator must generate and save their recovery codes before 2FA enforcement begins. Recovery codes are single-use and do not expire. If an administrator loses access to their authenticator app and has no recovery codes, the only way back in is database-level account recovery.
Authenticator app is the best default method for administrators and developers. Email code is a practical fallback for non-technical team members or clients who will not reliably maintain an authenticator app.