The Login Page That Gets Guessed at All Night

The same page on every site

Add /wp-login.php to the address of a WordPress site and the same login box appears. Unless somebody has moved it, every WordPress site has one in the same place.

Automated tools know that too. Tonight a program will work through usernames and common passwords against that box on your site, and it will not stop when the office closes.

Nobody picked your business. The tools try the same guesses on millions of sites, because a few always have an account that opens.

Whether yours is one of them comes down to four things most owners never check.

What the guessing looks like

A security plugin's log on a typical small business site shows failed attempts scrolling for pages: admin, administrator, the business name, the domain name, each with a different password.

The passwords come from lists of common ones and from passwords leaked by other websites, such as the enormous compilation publicised in January.

They arrive from a great many addresses, often hijacked computers, each trying only a few times, so no single source looks busy.

Each guess also costs your server something. Checking a password takes effort by design, so a heavy night of guessing can slow a site on shared hosting.

Why admin gives away half the answer

The guessing tools treat the username as the easy half of a login, because sites so often hand it over.

• An account called admin, created by default on older installs and by some installers.
• The byline on blog posts, which shows the login name unless somebody changed it.
• The address of the author page, which usually contains the login name.
• The login screen itself, which says whether a username exists before judging the password.
• The business name, which every guessing tool tries soon after admin.

The fourth surprises most owners. Type a real username with the wrong password and WordPress says the password is wrong for that username, which confirms the first half is right.

A username nobody can guess

WordPress will not let you rename an account, so the fix is a new one: an administrator whose username is not admin, not the business name, and not anything shown on the site.

Log in as the new account and delete the old one. WordPress asks what to do with the old account's posts and pages: attribute them to the new user, because the other option deletes them.

In its profile, set the name shown publicly to something other than the login name, so the next blog post does not give it away.

Pair it with a long password used nowhere else, kept in a password manager rather than changed to something memorable.

Limits on failed attempts

Out of the box, WordPress lets anyone try as many passwords as they like.

A limit changes that. After a handful of failures from one address, that address is shut out for a while, and further guesses are refused before reaching the password check.

Security plugins can do this, and so can rules on the server, which turn guesses away before WordPress does any work.

One detail matters more than it sounds. An older file called xmlrpc.php, which lets some apps post to the site remotely, also accepts passwords, and can take many guesses in a single request.

Make sure the limit covers it too, or have it switched off if nothing on the site uses it.

A worked example

A family-owned flooring store in a suburban retail park had a WordPress site built in 2015, with a blog updated every couple of months.

Every post said Posted by admin. The developer had set that account up, and its password also opened the store's newsletter account.

When the site began to crawl in the evenings, the host found a steady stream of requests, all night, to the login page and xmlrpc.php.

The users screen listed four administrators: admin, a developer the store had not used in years, a former office manager and a forgotten test account.

A new administrator with an unrelated username took over from admin, with every post attributed to it. The other three accounts were deleted, and the newsletter password was changed.

Failed logins were limited at the server, xmlrpc.php was switched off, and the one remaining administrator added two-step login. The blog now shows the owner's name.

Two-step login for administrators

Two-step login asks for something after the password: usually a six-digit code from an app on your phone, which changes every thirty seconds.

A guessed or leaked password is then not enough by itself, which is the very situation the overnight guessing is trying to create.

WordPress does not include it, but well-maintained plugins add it to the login screen. Start with administrators, since an administrator can install code and change everything else.

Keep the backup codes these plugins offer away from the phone, because whoever holds it will one day lose or replace it.

Administrators nobody remembers

The users screen can be filtered by role. On a site a few years old, the administrators usually outnumber the people who need to be one.

Former staff, developers from two redesigns ago, test accounts from the build: each is a working login with full control, and nobody watches whether it is used.

Delete the ones nobody can account for, attributing their content to a current user. For people who still edit the site, lower the role: an Editor can manage every page and post but cannot install plugins or add users.

Fewer administrators means fewer passwords that open everything.

The counter-case

Some sites are in better shape than this.

A site with one administrator, a username that appears nowhere and a long unique password has done the hard part; limits and two-step login are an hour's work for whoever maintains it.

Moving the login page to another address cuts the noise in the logs. It is a nuisance to the guessers rather than a lock, and can trip up apps that expect the usual address.

And no setting replaces updates. A login can be perfect while an old plugin offers a way round it.

For every WordPress site, the four still apply: unique usernames, limits, two-step login and fewer administrators.

This week

1. Filter the users screen by administrator.
2. Delete accounts nobody can account for.
3. Replace any account called admin with a new one.
4. Attribute old content to the new user.
5. Limit failed logins, including through xmlrpc.php.
6. Add two-step login for every administrator.
7. Store the backup codes away from the phone.

Step four is the one to slow down for. Deleting a user offers to delete everything that user wrote, and on many sites the admin account wrote every page.

Keeping the code behind that login current is covered in plugins nobody has updated in two years.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.