The humble login page is where break-ins actually happen
Attack scripts do not hack your website in any cinematic sense. They point automated tools at the login form, around the clock, and wait for a weak combination or a careless setting. The good news is that a handful of small changes, most of them free and many of them copy-paste, turn that door into a wall. Here are five, each one a job you can finish today.
1. Make the error message say nothing
WordPress login errors are chatty by default. They will happily tell an attacker that the username exists and only the password was wrong, which halves the work for them. Close that information leak by making every failed login identical.
Where it goes: the functions.php file of your child theme, or a code snippets plugin you already run.
add_filter( 'login_errors', function() {
return 'Something is wrong. Try again.';
} );Check it worked: log in with a fake username and a real one with a wrong password. Both replies should look identical.
2. Put two steps in front of the door
A leaked password stops mattering much when a second check stands behind it. Enable two-step login for every admin account, using whatever you already have: many hosting panels and security plugins offer it, and most take minutes to switch on.
Copy-paste this into your team chat as the policy:
Two-step login is on for every account that can publish or edit. No exceptions, including me. If you lose your second factor, tell the team before you need it, not after.
Check it worked: log in to one admin account and confirm you cannot get in with the password alone.
3. Hand out application passwords, not your master password
Anything that connects to your site on a schedule, an editor tool, a publishing script, a reporting dashboard, should never hold your main password. Modern WordPress has application passwords built in. Visit Users, then Profile, and scroll to Application Passwords. Create one named after the job it does, give it to the tool, and revoke it the moment the tool is retired.
Copy-paste the naming rule:
One application password per tool, named after the tool, created by the person who owns that tool. Revoked the week it stops being used.
4. Close the account graveyard
Old stores accumulate ghosts: the contractor from three years ago, the account you made for a plugin demo, a colleague’s test login. Every one of those is a live door. Open Users once a quarter and be unsentimental.
Copy-paste this checklist:
- Every account belongs to a real, current person.
- Every account has the lowest role that does the job, editor rather than administrator wherever possible.
- No shared accounts. If two people need it, they each get their own.
- The generic “admin” or “info” username does not exist, because those are the usernames attack tools try first.
5. Slow the machine down with limits
The last piece is patience: automated guesses only work at speed. Limit login attempts, either through your security plugin or your host’s security tools, to something small like five tries before a lockout that lasts an hour. That single setting turns a brute-force run from a Tuesday afternoon into a years-long project the attacker will not finish.
Copy-paste the request to your host if you cannot find the setting:
Hi, two things please. Can you confirm rate limiting is active on our wp-login page, and can you let me know where I can review failed login alerts. Thanks.
One evening, five locks
None of this makes your site invulnerable, and that was never the promise. The promise is that the cheapest, most common automated attacks stop applying to you, because the easy targets are always someone else’s untouched login page. Do the five in order, start with the error message, and you will be a meaningfully harder target by dinner.
Want more like this? Join MOKU Club for free. Weekly resources, early access to new guides, and occasional templates you can actually use. Join below.
