📊 Poll: Should 6502ish add email as an additional MFA option (alongside TOTP)?
Yes — the recovery path + lower onboarding friction is worth the weaker factor. 100% (2)
No — keep TOTP as the only option, email as a second factor is too weak. 0% (0)
2 votes
0
OP New Sysop Apr 20, 2026 10:23am

I'm thinking about adding email as a second-factor option alongside the existing TOTP (Google Authenticator / Authy) setup. Right now, if you want to use 2FA you need an authenticator app, period. That's the secure baseline — but it locks out anyone who doesn't want to install one, or who's lost their phone and didn't save a backup.

This thread is to hear from you directly. Vote yes or no; drop a reply with your reasoning.

The pros

  • Lower friction onboarding. The biggest barrier to MFA adoption is "install this app first." If a user can complete the flow with nothing but the email address they already registered with, more people turn it on.
  • Recovery path when the authenticator is gone. Phone wiped, app uninstalled, new device with no backup — email as a secondary factor means you're not stuck filing a manual recovery ticket with me.
  • Account changes are already gated on email. Email verification and reset links already go to the registered address, so we're not expanding the trust model — email is effectively already a recovery factor, just an unofficial one.
  • Works on a dumb phone. TOTP requires a smartphone or desktop app. Email works on whatever can read mail.

The cons

  • Email is weaker than TOTP. If someone gets into your email account (reused password, webmail breach, SIM-swap on a phone number that receives 2FA emails too) they can pivot into your 6502ish account. TOTP is isolated from that threat model.
  • Delivery isn't instant or guaranteed. Provider throttles, spam filters, and blackhole rules eat codes. A user who's already frustrated at "why can't I log in" hits another wall.
  • It's the weakest factor masquerading as parity. NIST deprecated SMS for 2FA for similar reasons; email is in a similar bucket. Calling it "an MFA option" may give users a false sense of security.
  • One more thing to maintain. A deliverable-code pipeline, a code TTL, brute-force protection, rate limits, UI for "didn't receive it? resend" — all of it adds surface area and bugs.

The likely compromise if I do it

  • Email MFA would be opt-in, not default. TOTP stays the recommended path.
  • It would be clearly labeled in the UI as "lower security, easier recovery".
  • Mods and admins (role >= 3) would continue to require TOTP — email wouldn't be accepted for those accounts at all.
  • Rate-limited aggressively on the sending side: no more than N codes per hour per account, regardless of who's asking.

What I want from you

Vote yes or no below. Then reply with the thing that actually matters to you — recovery? accessibility? the security trade-off? a specific scenario where TOTP burned you? I read every reply.


. __  ____   ___ ____  _     _     
 / /_| ___| / _ \___ \(_)___| |__  
| '_ \___ \| | | |__) | / __| '_ \ 
| (_) |__) | |_| / __/| \__ \ | | |
 \___/____/ \___/_____|_|___/_| |_|
        D2sk - Sysop

Log in or register to reply to this thread.