Login Security features

The first lockout is twenty minutes, the next is an hour, then three, then nine, then a day — because a machine that comes straight back has learned nothing and a person who remembers never sees the second one. A correct password clears the count against that account, and never the address's: signing in to an account of your own does not buy more guesses at anybody else's.

This counts the failures against one username too, across every address they came from.

A locked-out address is turned away at the very first hook WordPress offers, before it has looked anything up.

A request trying one of those is a machine working from a list, and it can be told no without touching the database. Checked against your own users first, so a site that genuinely has somebody called support never refuses them.

No text messages, no account with a service, no third party: the app and your site share a secret and both look at the clock. The QR code is drawn on your own server rather than fetched from a chart service, because the one thing on that screen that must not leave your site is the secret. Ten recovery codes, an administrator can switch it off for anybody, and WP-CLI can too. On a WooCommerce shop, customers set it up in a Two-step sign-in tab in My Account, where WooCommerce keeps them, and are asked for it when they sign in there.

Set a minimum length and refuse the usual passwords — decoration and all, because Password1! is password with a shift key — along with keyboard runs, rows of digits, and anything holding the username or the site's name. Checked when somebody sets or resets one, entirely on your own server, with nothing sent anywhere. Every form, including WooCommerce's own registration, account and reset pages — which are the ones your customers actually meet. The passwords already on your site are judged the next time each owner signs in, for the people the rules apply to, and anybody whose password fails is asked to change it and listed on the Users screen. The password itself is never stored. Off until you switch it on, and it applies either to everybody or only to the people who can change the site.

All four are closed, while author pages and bylines stay. And the Settings screen names anybody whose public name is still their username, which no setting can hide.

The default blocks that one call and leaves everything else working, so Jetpack and the mobile app carry on. You can also switch XML-RPC off entirely, or leave it exactly as WordPress has it.

On most sites that is thousands of requests a month arriving as a 404 instead of as a password check. The new address is shown and emailed the moment you save it.

While "Stop somebody after too many wrong passwords" is on, both get the same sentence, on wp-login.php, a moved sign-in page and WooCommerce's My Account alike, and on the WordPress sign-in page the name stays in the box and the form shakes either way. A password reset for a name that is not an account goes on to the page a real one gets, sending nothing. The registration form keeps WordPress's own words, so somebody signing up is told what to fix.

By default, three emails an hour for one account and five requests from one address, and while the limit is on, an address locked out for guessing is told how long to wait instead of being sent one. A request your CAPTCHA turned away, or an email your site could not send, uses up nobody's hour, and a made-up name is refused at its fourth like a real one. On wp-login.php and WooCommerce's My Account alike. Trusted addresses and signed-in administrators are never limited.

The sign-up forms on wp-login.php and WooCommerce's My Account turn them away: a field only a machine fills in, a form sent back too quickly, and a limit of new accounts from one address in an hour. At checkout only the limit applies: the field and the clock never stop a customer paying, though an order that would make one account too many from one address in the hour is refused. Everything happens on your own server, and each sign-up turned away is in the log with the reason. On for new sites; a site that already had the plugin is asked first.

It lists who would come across first, works with the other plugin switched off, and changes nothing of the other plugin's. Anybody with a second step here already keeps theirs, and each person brought over is asked to make ten new recovery codes on their profile. WP-CLI does the same, with a dry run.

Then the code screen offers "Do not ask on this browser for 30 days", on wp-login.php and at My Account. You choose the days and the roles it is never offered to, and administrators start left out. The cookie is HttpOnly, sent over HTTPS only and kept for your site alone, and only a keyed hash of it is stored. A new password ends it, and people can forget any browser from their profile.

Searchable by address or username, filterable by outcome, and kept for as long as you choose. Successes are in there too, because "was that me?" is the question somebody asks the morning after.

It names the address and why the lockout happened, the username when one was tried from many addresses, and how many attempts were refused in the last day while attempts are being recorded.

A Second step column on Users, with recovery codes left, a link that lists the people who can change the site and have not set one up, and the count on the Settings screen. On the Dashboard, a real account being guessed at with no second step gets a Send a password reset button, for anybody who could edit that account from the Users screen.

The address you switched the plugin on from is added to the trusted list automatically. There is a recovery link that trusts whatever address you open it from for an hour, so it works from a train or a phone. And WP-CLI can unlock anything from the command line if all else fails.

An office, a VPN, a monitoring service. Their attempts are still recorded — trusted means never locked out, not invisible.

Which is the way back in that works when the admin screens are the thing you cannot reach.