Disrupting the Attacker's Workflow

An attack on a membership site is rarely a single clever move. It's a workflow, and like any workflow it has steps. Break any one step and the whole thing stalls. The login and authentication toggles each break a specific step, which works better than understanding them as a pile of unrelated checkboxes.

Step one: harvest usernames

Before anyone can guess passwords, they need usernames. Unfortunately WordPress out the box is happy to help with this.

The REST API hands them out at /wp/v2/users to anyone who asks. Author archives are just as generous: request /?author=1, get redirected to /author/dana/, and now you know the admin's login name. Repeat for 2, 3, 4... and you have your member list, which on a membership site is also your customer list.

Two toggles close this:

• Disable REST user enumeration removes the users endpoints for anyone not logged in. Your members' names stop being public data.
• Disable user enumeration redirects ?author=N queries and author archives to the home page. The probing trick stops working.

Step two: confirm what's valid

With candidate usernames in hand, the attacker checks their work at the login form. WordPress tells them when they've found a real account: "Invalid username." One valid username later, the error becomes "Incorrect password," and the attacker now knows exactly which account exists.

Remove login error hints replaces every login failure with one generic message. Valid username, invalid username, wrong password: all the same reply. The attacker's list of maybes stays a list of maybes.

Step three: brute-force

Confirmed username plus unlimited guesses equals a credential-stuffing contest, and bots are patient. Limit login attempts ends the contest: five failures from one IP address, then a fifteen-minute lockout for that address. A human who typo'd their password three times never notices. A bot doing a thousand guesses a minute gets five.

One honest caveat: the limit is per IP, and legitimate members sometimes share an IP, an office network, a school, a household. If you hear "the whole office is locked out," this toggle is why. The fix is patience (fifteen minutes) or a firewall-level rule with whitelisting, not panic.

Step four: linger

Suppose the worst happens and an attacker gets a member's password, or an admin walks away from a logged-in laptop in a coffee shop. This is where lingering gets expensive.

Idle session timeout signs out idle sessions after 60 minutes. An abandoned admin login becomes a useless cookie instead of an open door to member data and payment settings.

Disable application passwords closes a subtler door. Application passwords let external tools authenticate over the REST API with full account access, and they keep working after the main password changes. An attacker who once had your credentials can plant one and stay connected forever. If you don't use the WordPress mobile app or app-password integrations, turning this off removes the tunnel entirely.

The chain, end to end

Harvest usernames, confirm them, guess passwords, linger after success. Enumeration off, error hints off, attempts limited, sessions expired, app passwords gone. Every toggle in this section exists to make one of those steps not work, and the cheapest time to enable all five is before anyone's knocking.