Not telling a machine which half was wrong

WordPress says Unknown username for one and The password you entered for the username X is incorrect for the other. That hands a machine working through a list the answer to half its problem: it learns which usernames exist, throws away the rest, and spends everything it has on the ones that do.

While Stop somebody after too many wrong passwords is on, the answer is the same whether the name typed is an account or not:

• The sign-in form, on wp-login.php, at a sign-in page you have moved and in the small sign-in box wp-admin shows when a session runs out. A wrong password, a username that is not an account, an email address that is not an account and a name turned away by Refuse usernames nobody here has all get one sentence: That username and password do not match an account on this site. The name typed stays in the box and the form shakes every time. WordPress itself keeps the name in the box only when it is an account, so the sentence alone still gave that away. If a CAPTCHA on the form adds its own refusal, its words are shown beside the sentence, the same either way.
• The lost-password form on wp-login.php and at a moved sign-in page. A name or email address that is not an account goes on to WordPress's Check your email for the confirmation link page, as a real account does, and nothing is sent. When a CAPTCHA on the form turns a request away, only the CAPTCHA's own words are shown, account or not.
• The sign-in form on a WooCommerce shop, on the My Account page and at checkout: the same one sentence. WooCommerce keeps the name in the box either way and does not shake its form.
• My Account → Lost password on a WooCommerce shop. A name or email address that is not an account goes on to WooCommerce's own Password reset email has been sent page, as a real account does, and nothing is sent. On a network, WooCommerce before 9.9 turns away an account that is not a member of the shop's site as if it were made up, so that account gets the same page, is counted like a made-up name, and is sent nothing.
• An app signing in with an application password over the REST API. A name that is not an account and a wrong application password get the same error code and the same sentence.

What is still different:

• how long the answer takes. WordPress checks a password only when the name is an account, and a real account's reset email is sent while the visitor waits. So the answer for a real account takes longer, often by enough for a machine to measure;
• a site that cannot send email. The lost-password form says the email could not be sent for a real account, and a made-up name never gets that far;
• admin, support and the rest of that list, while Refuse usernames nobody here has is on. One of those names that is not an account is turned away without being counted, so it never leads to a lockout. The same name as a real account is checked, counted and locked out like any other, so a machine that keeps trying one of those names can tell from the lockout whether it is an account;
• an account another plugin has barred. When a plugin or your theme turns password resets or application passwords off for some accounts, those accounts are told so, and a made-up name is not;
• registration forms. WordPress's own, WooCommerce's and the account made at checkout say whether a username or email address is already taken, because nobody could sign up otherwise;
• sign-in and lost-password forms another plugin or your theme runs itself, unless it goes through WordPress's or WooCommerce's own steps.

So somebody who mistypes their username or email address on a lost-password form is told to check their email, and nothing arrives. If a customer says a reset email never came, ask them exactly what they typed.

With the setting off, these forms answer in WordPress's and WooCommerce's own words, which say whether a name is an account.

Your own lockout messages are not flattened — somebody who is locked out is told how long for, because that is useful to a person and no use at all to a machine that is already being refused.

Nor is WordPress's registration form, where Anyone can register is ticked. Somebody signing up whose email address is not correct, or whose username has characters WordPress does not allow, is told so in WordPress's own words. That form says whether a username is taken whatever this plugin does, because nobody could sign up otherwise; what limits it is Screen new sign-ups for bots under Settings → Sign-ups.