User enumeration: definition

A login pair has two halves: the username and the password. If the attacker already knows the first one, they focus their attempts on real accounts instead of random names. User enumeration is therefore a classic reconnaissance step that sets up a brute-force attack or credential stuffing. The OWASP Web Security Testing Guide lists it among identity management tests.

How enumeration works

The attacker looks for a difference in behavior between an account that exists and one that doesn't. OWASP lists several:

• a different error message for “unknown username” and “incorrect password”;
• an HTTP status code, response size or page title that varies;
• a longer response time when the account exists, for example because a reset email is being sent;
• a user-specific URL that returns 403 if the user exists and 404 otherwise;
• a forgotten password form that confirms or denies the account exists.

The defense in principle is the same everywhere: return identical messages and responses in every case.

Sources of enumeration on WordPress

By default, WordPress publishes several pieces of information that lead to usernames. An author's slug (user_nicename) is derived from the login username: knowing the slug often means knowing the username.

• /?author=1 redirects to the author archive, which contains their slug.
• The REST API (/wp-json/wp/v2/users) returns the numeric ID, display name and slug of authors who have published. In 2017, CVE-2017-5487 was assigned to WordPress 4.7 for an overly broad list, fixed in 4.7.1.
• The users sitemap (wp-sitemap-users-1.xml), present since WordPress 5.5.
• oEmbed responses, which contain the author's name and archive link.
• The login form, which distinguishes an unknown username from an incorrect password.

Our article on WordPress user enumeration shows how to test each of these sources on your site in two minutes, and the one on the REST API explains how to close the users route to anonymous visitors without breaking the editor.

For WordPress: how to protect your site

1. Don't publish with an administrator account: create an Author or Editor account for writing. An account that has published nothing appears neither in the API, nor in the sitemap, nor in the archives.
2. Choose a “Display name publicly as” value different from the username, under Users, Profile (the slug, however, doesn't change).
3. Close unnecessary sources: author archives, the REST users route for anonymous visitors, the sitemap's users provider, the author in oEmbed responses.
4. Make the login error message generic.

Keep things in proportion: a username is not a secret. A long, unique password and two-factor authentication protect the account even if its name is known; hiding the username only takes away a free advantage from the attacker.

WP Masquerade Pro's Hardening module closes these sources with one option: /?author= and author archives, the REST users route for anonymous visitors, the author sitemap, the author in oEmbed responses and neutral error messages. Logged-in users and other REST routes keep working. Names published elsewhere (post bylines, the theme, an email address) remain visible.