WordPress Login Security: Passwords, 2FA and Brute-Force Protection

Every WordPress site has a login page at a well-known address, and automated bots try it constantly with common passwords and credentials leaked from other breaches. You will probably see this in your logs. Most attempts fail, but all it takes is one weak or reused password on an administrator account. Locking the front door well is cheap and effective.

How attackers try to get in

• Brute force: trying many passwords against a username.
• Credential stuffing: using email and password pairs leaked from other services, hoping you reused yours.
• Username discovery: finding valid usernames from author archive pages, the REST API or login error messages.
• Phishing: fake messages that trick users into entering credentials on a lookalike page.
• Session theft: stealing login cookies from infected devices.

Passwords that hold up

Use long, unique passwords for every account. A password manager makes this practical: it generates and stores them, and fills them in for you. Length matters more than clever substitutions. Never reuse the password you use for email, hosting or banking. If a service you used suffered a breach, change the password immediately wherever you reused it.

Do not use admin as a username, and avoid usernames that match your public author name or the site's domain.

Two-factor authentication

Two-factor authentication (2FA) adds a second step after the password. Even if an attacker has the password, they cannot log in without the second factor. WordPress does not include 2FA in core, but several established plugins add it.

Types of second factor

• Authenticator app: generates short-lived codes on your phone. A good balance of security and convenience.
• Hardware security key or passkey: the strongest option, where supported by the plugin.
• Email codes: better than nothing, but only as strong as your email account and deliverability.
• SMS codes: weaker, since phone numbers can be hijacked; use only if nothing else fits.

Require 2FA for administrators and editors at least, and keep backup codes in your password manager so you are not locked out if you lose your phone.

Limiting attempts and hiding the login page

A plugin or firewall rule can lock out an IP address after several failed attempts, slowing brute-force tools to a crawl. Be careful with the thresholds so you do not lock out real users, and make sure you know how to unblock yourself, for example by editing the plugin's folder name through SFTP. Server-level protection and a web application firewall, such as Cloudflare's, can filter much of this traffic before it reaches WordPress.

Reducing exposure of the login page

Restrict by IP address

If only a few people log in from fixed locations, you can allow access to /wp-login.php and /wp-admin/ only from those addresses at the server level. This is very effective but impractical for travelling teams or people with changing addresses.

Change the login URL

Some plugins move the login page to a custom address. This cuts the noise from bots, but it is obscurity, not security. It can also confuse users and break integrations. Treat it as an optional extra and do not skip the real protections.

Add a challenge

A bot-check challenge on the login form reduces automated attempts. Choose privacy-conscious options and test that they work with your cache.

Other doors to close, and session hygiene

• XML-RPC: an older remote access interface that attackers use to try many passwords in one request. Disable or restrict it if you do not need it.
• REST API user enumeration: some setups expose usernames. Limit it if it is a concern.
• Login error messages: make them generic so they do not reveal whether the username exists.
• Application passwords: WordPress supports them for API access. Review and revoke ones you do not use.
• HTTPS: always use it for login pages; free certificates are available with our hosting, as described on the SSL page.

Session and device hygiene

Log out of shared computers. Keep browsers and operating systems updated, because malware on a device can steal session cookies even when 2FA is enabled. WordPress lets you log out all other sessions from a user profile, and changing the security keys in wp-config.php invalidates all sessions at once.

What to do after a suspicious login

1. Change the password of the affected account and any other account that shares it.
2. Review the user list for accounts you do not recognise.
3. Log out all sessions and regenerate the security keys.
4. Check recent changes to content, plugins and files.
5. Enable 2FA if it was not on, and review the logs to understand how the attempt succeeded.

Make it easy for staff to comply

Security measures fail when they are annoying. Provide a password manager for the team, explain in a few lines why two-factor authentication is required, and share backup codes safely. A short onboarding checklist for new users, and a clear process for lost devices, prevents people from creating workarounds that weaken the setup.

Protecting the whole stack

WordPress logins are one entry point among several. Hosting control panel, SFTP and email accounts need the same care. At Zebra Hosting, Plesk and our security guidance help you keep access tight, and our WordPress hosting plans work with Cloudflare, which can add another layer of filtering in front of your login page.