ModTwoAuth

Delivers enterprise-grade Two-Factor Authentication (2FA) for MODX 3 Manager and Frontend. It supports modern methods:

TOTP (RFC 6238)

Email

Telegram bot (with interactive approve/reject buttons)

WebAuthn/FIDO2/Passkeys (Touch ID, Face ID, hardware keys).

Includes a built-in security diagnostics panel to verify HTTPS, CSP, and encryption status.

Fully customizable via chunks and compatible with frontend Login workflows.

2FA for managers

In System Settings → ModTwoAuth, enable modtwoauth_enable_2fa.

Each manager sets up a method for themselves: Users → edit own account → "🔐 2FA" tab - scan the QR, confirm an email code, link Telegram, or register a Passkey, then flip the "Enable 2FA" switch.

From the next login, MODX will request the second factor after the password. Managers always use the built-in verification page template (chunk modtwoauthVerifyTpl); the URL is changed via the modtwoauth_verify_url setting (default /2fa).

2FA for website users (frontend)

Enable modtwoauth_frontend_enable_2fa (enabled by default).

Place the snippets on a page available to authorized users (e.g., in the personal account):

[[!ModTwoAuthFrontend]] [[!ModTwoAuthSessions]]

Users set up methods themselves, enable 2FA (after login), and see the list of active sessions for the last 30 days; any other session can be terminated - it will be rejected on the next request. Disabling 2FA requires the current password.

The frontend verification page can be styled with your own chunk - set its ID in modtwoauth_verify_chunk_id. An empty or invalid value falls back to the built-in modtwoauthVerifyTpl; this setting does not affect the manager.

First public release.

Authentication methods: TOTP (RFC 6238, window ±1), Email codes, Telegram (QR/deep-link binding, login via code or a button in the bot), WebAuthn/FIDO2/Passkeys (ES256/RS256/Ed25519) — for both the manager and the frontend.

Security:

Protection against reuse of TOTP codes (the timestep of the last accepted code is stored in the database).

The Telegram webhook rejects all requests without a secret; the secret is derived from the bot token; only hashes of one-time tokens are stored in the database; login confirmation is bound to the chat and the session.

Rate limiting for sending email codes (modtwoauth_resend_cooldown); a global limit on failed attempts with lockout that persists in the database; per-method attempt limits during setup.

Session ID regeneration after 2FA in all flows; session lists and individual revocation; modtwoauth_session_max_age forcibly terminates stale 2FA sessions.

TOTP secrets are encrypted with libsodium XChaCha20-Poly1305; the key can be moved outside the component (system setting); automatic migration of plaintext secrets on install.

CSRF tokens on all confirmation forms; optional CSP Report-Only; security diagnostics in the panel.