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.
Your login page gets hit around the clock, not by someone specifically targeting you, but by bots working through lists of leaked credentials and common usernames against every WordPress site they can find. Most of that traffic never gets close to succeeding. The point of the settings below is making sure it never gets the chance to try often enough to matter.
| Setting | Recommended value | Watch out for |
|---|---|---|
| Limit Login Attempts | On | Start moderate and tighten from there. Going strict on day one just means real users mistyping their password end up in your support queue instead of back in their account. |
| Failed attempts per IP | 5 | Offices, schools, and shared networks all sit behind one IP. One person on that network having a bad login day can lock out everyone else sharing it. |
| Failed attempts per user | 5 to 10 | Set this a bit higher than the per-IP limit, so a user who's genuinely forgotten their password gets a little more room before they're locked out too. |
| Detection window | 15 minutes | Works well for most sites. Go shorter and bots effectively get a more forgiving threshold; go longer and you'll rack up more false lockouts on real users. |
| Lockout duration | 30 minutes | Long enough to break the rhythm of an automated attack without turning a forgotten password into an hours-long support ticket. |
| Bot Detection (CAPTCHA) | Enable when bot activity is confirmed | Once it's on, actually walk through the login page, registration page, and password reset page yourself. If you run WooCommerce, check My Account and checkout too, those are easy to forget and easy to break. |
| Restrict Login Identifier | Email only for most business sites | Allowing username logins alongside email gives bots a second door to try. Email-only works cleanly as long as each of your users has one registered email tied to their account. |
| Block Default Admin Username | On, if no real account uses "admin" | Rename that account first if it exists. This setting only blocks login attempts against the username "admin," it won't rename an account that's still using it. |
| Obfuscate Login Error Messages | On | Low risk, straightforward win. A generic error message tells an attacker nothing about whether the username they tried even exists. |
Custom Login URL
Go to SiteFort → Hardening → Login Security → Custom Login URL.
Moving your login page off the default /wp-login.php path doesn't make your site more secure by itself, worth being honest about that upfront. What it does is quiet things down considerably: most of the automated traffic hitting that page never finds your new one, which means less log noise, less server load spent on requests that were never going anywhere, and an easier time actually spotting the traffic that matters.
| Option | Recommended |
|---|---|
| Login slug | Private and non-obvious. Write it down somewhere safe before you save, not after. |
| Register slug | Only worth configuring if the site actually has public user registration turned on. |
| Default wp-login.php response | 403 or 404. Either one stops a bot from confirming the old path is still live. |
| Redirect | Skip this unless you have a specific reason for it. A redirect can accidentally point straight at your new login location if it's not set up 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
The slugs on the right defeat the whole point, they're exactly the kind of guessable variations automated scanners already try as a matter of routine. If the site runs WooCommerce, a membership plugin, an LMS, or any plugin with its own frontend login form, test those flows after enabling this. Plugins that hardcode a link straight to /wp-login.php may need a small update to point at the new path instead.
Password policies
Go to SiteFort → Hardening → Login Security → Password Policies.
Weak and reused passwords are how most WordPress accounts actually get taken over, not clever exploits, just a password that was already sitting in a breach dump somewhere. These settings aren't about forcing everyone to rotate passwords on a schedule nobody enjoys. They're aimed narrowly at the specific password behaviors that actually get accounts compromised.
| Policy | Recommended | Watch out for |
|---|---|---|
| Breached Password Detection | On | Anyone using a password that's shown up in a known breach gets prompted to reset it on next login. Worth having a short explanation ready for support, since a user will occasionally push back, insisting the password in question is "fine." |
| Enforce Strong Passwords | On | Only kicks in the moment someone sets a new password. An existing weak password stays in place unless Breached Password Detection separately flags it. |
| Prevent Password Reuse | On for business, ecommerce, and agency sites | Nothing to watch here for most sites. A user simply can't set their current password again when resetting it. |
| Require Password Change on Role Promotion | On | Anyone promoted to Administrator or Editor gets asked to set a fresh password on their next login. Barely any friction for a real security gain, an easy one to leave on. |
| Password Expiration Policy | Off for most sites | Forced periodic resets tend to backfire in practice, people cope by picking predictable variations on the same password rather than something genuinely new. Only turn this on if a compliance requirement or internal policy specifically calls for it. |
Two-factor authentication
Go to SiteFort → Hardening → Two-Factor (2FA).
Two-factor authentication is the one setting on this entire page that still protects you after a password has already been stolen, guessed, or phished. If you only have time to configure one thing from this guide today, this is the one worth prioritizing on any site with administrator or editor access.
Which roles to require first
| Role | Recommendation |
|---|---|
| Administrator | Required. No exceptions on a production site, full stop. |
| Editor | Required for business, publishing, ecommerce, and agency-managed sites. |
| Shop Manager | Required if WooCommerce is active. Shop Managers can see order data and customer information, which makes that account worth protecting the same way you'd protect an Editor. |
| Author | Optional on most sites. Worth requiring on high-volume publishing sites, where a single compromised author account is enough to push malicious content live. |
| Subscriber / Member | Optional, unless those accounts hold financial, medical, educational, or otherwise sensitive personal data. |
Recommended 2FA settings
| Setting | Recommended value | Watch out for |
|---|---|---|
| Allowed methods | Authenticator App and Email Code | Keep both on. Turning off Email Code leaves anyone who can't or won't install an authenticator app with no fallback at all during rollout. |
| Grace period | 3 to 7 days for teams | Gives existing users breathing room to actually set up 2FA before enforcement locks them out. Only drop this to 0 when you're enforcing it on a single administrator account you're setting up yourself. |
| Remember device | 7 to 30 days | Longer periods mean less friction on trusted devices people log in from regularly. Shorter periods buy you more security at the cost of more support requests, especially on membership and LMS sites with less technical users. |
Recovery codes: do this before enforcing
Every administrator needs to generate and actually save their recovery codes before enforcement goes live, not after. Recovery codes are single-use and don't expire. Skip this step, and an administrator who loses their authenticator app has exactly one option left: database-level account recovery, which is a far worse afternoon than saving a text file would have been.
Authenticator apps are the right default for administrators and developers. Email code is the practical fallback for non-technical team members or clients who won't reliably keep an authenticator app set up long-term.