Secured WP

Description

Adds layer of security for your WordPress site. Adds custom login page slug, enables 2FA, removes security issues. Adds remember device, counts login attempts and lock usernames if the password is wrong. Out of band e-mail is also supported – instead of entering codes, your user can use simple login link from within their e-mail client.

WooCommerce

WooCommerce is also supported for 2FA, just enable the plugin and all your customers will be asked to enable two-factor authentication.

List with currently supported features:

1. Login redirection – redirects the default wp-login.php to a slug of your choice
2. Login attempts – counts the unsuccessful attempts, and locks user if there are too many
3. 2FA settings – gives the ability to use two factor authentication and Out Of Band email link
4. Remember devices – current device could be remembered for given amount of days and user wont be asked for the 2FA code on it before that (the password is still required)
5. Removes XML-RPC from your WordPress site
6. Custom shortcode ([wps_custom_settings]) can be used to give the users without access to the dashboard to setup the 2FA
7. Backup codes – ten single-use codes per user, the way back in when the phone is lost
8. Signed-in sessions – see everywhere an account is signed in, and log sessions out one by one

Login Redirection

You can change the default wp-login.php to slug of your choice. That will prevent most common hacker attacks and will harden your WordPress installation. You can redirect the original wp-login.php to the slug of your choice.

2FA login

Enable two-factor authentication for your WordPress site, and to enforce your website users, or some of them to use 2FA. Next time user logins s/he will be asked to enable the 2FA using their favorite application. Once the process is completed, every time the user logs, s/he will be asked to provide the 2FA code.

Which second step users get after the password:

• TOTP on – a code from the authenticator app. With Out of band e-mail also on, the email link is offered as an alternative.
• TOTP off, Out of band e-mail on – a one-time sign-in link sent to the user’s email address.
• both off – no second step; the password alone signs users in, even with 2FA enabled. Passkeys do not change that: they are a separate way to sign in, not a step after the password.

An emailed link is a weaker second step than TOTP: whoever controls the mailbox can also reset the password.

Setting up the authenticator (at the first login after 2FA is enabled, or on the profile page) shows a QR code, an “Open in authenticator app” button and the setup key with a Copy button. On a phone the QR code cannot be scanned from its own screen: the button opens the otpauth:// link, which iOS and Android hand to the installed authenticator or password app (Google Authenticator, Microsoft Authenticator, 1Password, iOS Passwords, …); the setup key can also be copied and pasted into the app. The code field is marked as a one-time code, so iOS / macOS Passwords and password managers that hold the secret offer the current code at later logins.

On the profile page everything Secured WP adds – remembered devices, the authenticator and passkeys – is grouped in one “Secured WP” panel; the same panel is used by the [wps_custom_settings] shortcode and on WooCommerce’s My Account page.

Login Attempts

This gives you the ability to prevent brute force attacks if the hacker knows the username and tries to guess the password. With this enabled, after the given amount of tries that username is locked for the given amount of time – from the address the tries came from. Somebody guessing from one place cannot lock the real user out everywhere. If the account fails ten times the allowed amount from many addresses, it is locked everywhere, except on devices the user asked to remember. Behind a reverse proxy or CDN, use the wpsec_client_ip filter to supply the visitor’s real address, otherwise every visitor shares the proxy’s address. Attempts are counted before the password or code is checked, with counters that cannot be outrun by sending many requests at once. An account locked by an administrator cannot be used with application passwords either.

Remember device setting

With that, user can use given device for the given amount of days without being asked for the 2FA code. The password is always required – a remembered device never signs anybody in on its own. The devices can be removed or checked from the default user settings page; changing the password or resetting the authenticator forgets them all.
That setting is based on current setting (global) for the current moment, which means that when the day value (in settings) is changed globally, that wont reflect the already set cookies and user devices.
Example: If you set that to 10 days and there is a user which decide to use Remember Device functionality, when you change that value to 15 days, that wont increase the time for that user. Same applies for decreasing the value.

Encryption key for 2FA secrets

Authenticator secrets are stored encrypted (XChaCha20-Poly1305), so a copy of the database alone – a leaked backup, an SQL injection – does not let anyone generate your users’ codes. That only holds if the key is kept somewhere other than the database. The plugin takes the key from the first of these that exists:

1. The WPSEC_ENCRYPTION_KEY environment variable. Best choice when your host lets you set environment variables (Docker, most managed hosts, or fastcgi_param WPSEC_ENCRYPTION_KEY "..."; in nginx). It always takes priority.
2. The WPSEC_ENCRYPTION_KEY constant in wp-config.php: define( 'WPSEC_ENCRYPTION_KEY', '...' );
3. A key stored in the database – only as a fallback. It keeps working when the WordPress salts are changed, but anyone holding a copy of the whole database also holds this key.

The key must be at least 32 random characters, for example the output of openssl rand -hex 32. A shorter value is ignored and reported as an error; users then cannot set up an authenticator until it is fixed.

When none of these exists, the plugin creates a key itself – on activation, the first time the plugin settings page is opened, or the first time one is needed – and tries to add it to the top of wp-config.php, right after the opening <?php (after a declare() line, if the file starts with one):

// BEGIN Secured WP - encryption key for the stored 2FA secrets. Do not change or remove it; see the Secured WP readme.
defined( 'WPSEC_ENCRYPTION_KEY' ) || define( 'WPSEC_ENCRYPTION_KEY', '<64 hex characters>' );
// END Secured WP

The top of the file is used because every wp-config.php starts with <?php, while the “That’s all, stop editing!” line differs between hosts or is missing. The plugin only writes when wp-config.php is writable and does not mention WPSEC_ENCRYPTION_KEY yet, never when the file declares a namespace, and only after PHP itself has parsed the result. It writes in place (owner, permissions and symlinks are kept) and puts the original back if the result does not read back exactly. To stop the plugin from ever editing wp-config.php, add add_filter( 'wpsec_write_wp_config', '__return_false' ); to a must-use plugin.

When wp-config.php cannot be written, the key is stored in the database, and the plugin settings page and Tools > Site Health say so. To move it out of the database, do one of these:

• Make wp-config.php writable, click “Move the key to wp-config.php” on the plugin settings page (or run wp wpsec move-key), then make the file read-only again. The same key is written to the top of the file and deleted from the database, so nothing needs re-encrypting.
• Or copy the key yourself. After confirming your identity, the settings page shows the exact block to paste (wp wpsec move-key prints it too when it cannot write). Put it at the top of wp-config.php, right after <?php – anywhere before the line that loads wp-settings.php works – or, where the host manages wp-config.php, in the file the host tells you to use for your own settings.
• Or set the WPSEC_ENCRYPTION_KEY environment variable to the value between the quotes in that block.

As soon as the plugin finds the same key in wp-config.php or the environment, it uses it from there – it takes precedence over the database – and deletes the database copy (the next time an administrator opens the admin, or on wp wpsec key-status).

If your deployments replace wp-config.php (git, CI, or a host that manages the file), the block the plugin wrote would be removed on the next deploy. Copy it into the wp-config.php you deploy, or use the environment variable. If the key goes missing while users still have authenticators encrypted with it, the plugin does not create a new key over it: the settings page, the Users screens and Site Health report how many authenticators cannot be read, until the key is restored or those authenticators are reset.

Changing or adding a key: every stored value records which key encrypted it. The plugin reads with any key it still has, and re-encrypts with the current one (the first in the list above) whenever a secret is read.

• Moving from the database key or the wp-config.php constant to the environment variable: just set the environment variable. The old key stays where it is and is still used to read.
• Changing the value of the environment variable or the constant: put the old value into WPSEC_ENCRYPTION_KEY_PREVIOUS (environment variable or constant) and the new value into WPSEC_ENCRYPTION_KEY. The previous key is only ever used to read.

To move everything at once, run wp wpsec reseal. Once it reports nothing unreadable, the old key can be removed: delete WPSEC_ENCRYPTION_KEY_PREVIOUS or the old constant, and wp wpsec reseal --drop-database-key deletes the database fallback key.

Never remove or change the only key that encrypted the stored secrets. Those users’ authenticators cannot be read any more: they are told so at login, can use the emailed link or a passkey if enabled, and must have their authenticator reset. Salt changes do not affect the key.

Secrets stored by earlier versions (encrypted with a key derived from the WordPress salts) are read and re-encrypted with the new key automatically. If the salts were changed before the upgrade, those secrets cannot be read and must be reset.

Backup codes

Right after setting up the authenticator, each user gets ten backup codes (XXXXX-XXXXX), shown once, with Copy, Download and Print. Each code signs in once instead of an authenticator code – at login (“Lost your phone? Use a backup code instead”) and when confirming identity for security changes. So a user who lost their phone can sign in, confirm their identity with another code, reset their authenticator on their profile and set it up on the new phone, without an administrator. Codes also work when the stored authenticator cannot be read because its encryption key was lost.

The profile has its own Backup codes section next to the authenticator: how many are left and when they were made, always visible, with “Make backup codes” (it asks the user to confirm their identity first when needed; a new set replaces the old one). Users who set up the authenticator before backup codes existed get a first set, once, at their next login, and every user with two-factor login sees an admin notice when they have no codes or 2 or fewer left – dismissible until that changes. Administrators see a user’s count on their profile, never the codes, and cannot make them for someone else.

Codes are stored as password hashes, independent of the encryption key and the salts, and each can be used exactly once, even by simultaneous requests. Resetting the authenticator retires the codes; the next setup comes with a new set. For support, wp wpsec backup-codes <user> --generate prints a fresh set to hand over.

Signed-in sessions

The Secured WP panel on the profile lists every place the account is signed in right now – browser, IP address, when it signed in and when the session expires – marks “this browser”, and logs sessions out one by one or all others at once. Administrators can do the same for users they may edit (“Log out everywhere”). Logging out single sessions needs WordPress’s own session storage; if a plugin replaces it, only “log out all other sessions” is offered.

Resetting a user’s authenticator

A reset removes the authenticator and its backup codes and forgets the user’s remembered devices; they set up a new one (with new backup codes) at their next login. It is needed when a phone is lost, or when an authenticator cannot be read (its encryption key was lost). The Users screen shows “UNREADABLE – reset required” in the Secured WP Status column for those.

• Users screen: “Reset authenticator” under the user’s name, or select users and choose “Reset authenticator” from Bulk actions. Administrators are asked to confirm their identity first.
• Multisite: the authenticator belongs to the user across the whole network, and WordPress lets only network administrators edit other users. The reset is offered on Network Admin > Users, and on a site’s Users screen only to network administrators – site administrators do not get it.
• Profile page: another administrator can reset it there too.
• The user themselves, with a backup code: sign in with one, confirm identity with another, then “Reset authenticator” on the profile.
• WP-CLI: wp wpsec reset-authenticator <user>..., or wp wpsec reset-authenticator --unreadable for every authenticator that cannot be read.

WP-CLI

All commands are under wp wpsec; wp help wpsec <command> shows the built-in help. They act on the whole installation – on multisite the key and the users’ authenticators are network-wide, so --url makes no difference. Anyone who can run WP-CLI already controls the site, so the commands do not ask for identity confirmation the way the admin screens do.

wp wpsec key-status

Shows where the encryption key comes from (environment variable, wp-config.php constant, or database), how many keys are available for reading, how many authenticators are stored (and how many are still in the pre-2.5 format), and warns about a misconfigured key, a key kept in the database, or authenticators encrypted with a key that is no longer available. If the database still holds a copy of a key that is now also set in wp-config.php or the environment, the database copy is deleted and the command says so.

wp wpsec move-key

Moves the key stored in the database to the top of wp-config.php, between the “BEGIN Secured WP” and “END Secured WP” lines, then deletes the database copy. It is the same key, so nothing needs re-encrypting. wp-config.php must be writable while the command runs; it can be made read-only again afterwards. If the file cannot be written, the command …