Sigil – Passkeys and Two-Factor Authentication

Sigil adds a second authentication step to WordPress logins. Users enrol a passkey, an authenticator app, backup codes or email codes from their profile, and administrators can require 2FA for chosen roles with a grace period.

Methods

• Passkeys (WebAuthn), using a platform authenticator such as Face ID, Touch ID or Windows Hello, or a hardware security key. Requires PHP 8.0 or newer.
• Authenticator app (TOTP), compatible with any RFC 6238 application.
• Backup codes: ten single-use codes, generated the first time any method is set up.
• Email codes: a six-digit code sent to the account email address.

Enforcement

• Require 2FA per role, or for everyone with a chosen capability.
• Set a grace period so existing users get time to enrol instead of being locked out on the next login.
• A “2FA” column on the Users screen shows who has set it up and who has not.

Enrolment without the dashboard

Put [sigil_2fa] on any page and users can set up and manage their methods there. Sites that keep members out of wp-admin need this, and enforcement redirects to that page when it exists instead of to an admin screen the user cannot open.

Multisite

Accounts are network-wide in WordPress, so second factors are too. An authenticator or backup codes cover every site on the network, the policy is set once under Network Admin, and the rate limiter counts across the network rather than per site. On a network, resetting another user’s 2FA is a Network Admin action, which is how WordPress governs user editing there.

Passkeys are bound to the domain they were created for, so by default a passkey covers the site it was registered on. A network under one operator can widen that to cover every subdomain site with the sigil_rp_id filter. It is opt-in because widening lets any site under that domain request assertions, which matters when sites have different administrators.

REST API

Routes under sigil/v1 read a user’s methods, reset or remove them, read and edit the policy, and describe or complete a pending login challenge so a decoupled front end can run the second step itself. The challenge routes are authenticated by the challenge token issued after the password step. Reading and changing anything else requires the same capability as the equivalent screen.

This does not add a second factor to token authentication. A request that authenticates with an application password never reaches the interactive login, so it is not challenged.

Recovery

Three ways back in if a second factor is lost:

• Backup codes are generated and displayed at first enrolment.
• A user with the edit_users capability can reset another user’s 2FA from the Users screen.
• wp sigil reset <user> clears a user’s second factor from the command line when no one can reach the dashboard.

Application passwords

Two-factor authentication does not apply to application passwords, which authenticate REST API and XML-RPC requests. The settings screen documents this, and application passwords can be disabled per role.

Third-party libraries

• QR Code Generator for JavaScript 2.0.4 by Kazuhiko Arase, MIT licensed, bundled unmodified at assets/js/vendor/qrcode.js (https://github.com/kazuhikoarase/qrcode-generator). Draws the authenticator QR in the browser.
• WebAuthn by Lukas Buchs, bundled in vendor/, used to verify passkey registrations and assertions.

Neither contacts an external service.