Expand MFA to Include Email as a Second Factor
Type: Enhancement
Area: Authentication / Security / User Accounts
Current Behavior:
Two-factor authentication on 6502ish is currently limited to TOTP (Time-based One-Time Password) via authenticator apps such as Google Authenticator, Authy, or 1Password. Users without a smartphone, or who prefer not to install a dedicated authenticator app, have no way to add a second factor to their account.
Requested Change:
Add email as an optional second-factor method that users can enroll in from the account settings page, either alongside or instead of TOTP.
Requested capabilities include:
- Allow users to enable email-based MFA from the same settings screen that enables TOTP today
- On login, if the user has email MFA enabled, send a short-lived one-time code to the account's verified email address
- Codes should be numeric, six digits, and expire within ten minutes
- Rate-limit code sends per account and per IP to prevent abuse of outbound email
- Lock the account after a configurable number of failed code attempts, matching the existing TOTP failure policy
- Allow a user with both TOTP and email enrolled to choose email as a fallback when their TOTP device is unavailable
- Honor the existing session-expiry reauth flow so a stale AJAX request redirects to the correct MFA challenge instead of a generic login page
Pros:
- Lowers the barrier to MFA adoption for users who will not install an authenticator app — a real concern on a site whose demographics skew older
- Reuses the email infrastructure already in place (MailService, PHPMailer, the queued email worker) rather than adding a new dependency or third-party service
- Provides a practical account-recovery path when a user loses their TOTP device, reducing support workload for SysOps
- Familiar user experience — "we sent you a code, paste it here" is a pattern almost every user already understands
Cons:
- Email is a weaker second factor than TOTP. A compromised or phished email account hands the attacker both the password-reset channel and the second factor in one shot
- Credential-stuffing attacks that already pair a breached password with its matching email address are not meaningfully blocked by email MFA
- Delivery latency, greylisting, or spam-folder routing can turn a slow SMTP path into an intermittent login-blocker
- Adds new code paths — rate limiting, code generation, expiry, brute-force lockout — that need to be written, tested, and maintained
- Risk of users enabling email MFA instead of TOTP and ending up with weaker protection than they had before; the settings UI has to make this trade-off explicit
Expected Outcome:
Users who cannot or will not use a TOTP authenticator can still protect their account with a second factor, and users with TOTP enabled gain an email-based fallback for when their phone is unavailable. Overall MFA enrollment on the site should increase.
Notes:
Email MFA should never be offered to an account whose email has not been verified. The settings UI should clearly label TOTP as the stronger option and recommend it first. MFA-code sends should route through the existing email queue so delivery load is isolated from transactional email.
