Emailing a one-time code is worse than passwords

Original Article ↗ Hacker News Discussion ↗

Email one-time codes and phishing risk

  • Many commenters agree that email (or SMS) one-time codes used as the primary login are weak: they turn your inbox into the single point of failure.
  • The key attack pattern (“real-time phishing” / confused deputy): BAD site asks for your email, silently starts a login on GOOD, you receive a legitimate code from GOOD, and then type it into BAD, which immediately logs into GOOD as you.
  • This pattern works even when BAD is not impersonating GOOD’s brand, just claiming “we use X as our login partner,” which is plausible in today’s SSO-heavy world.
  • Sending a link is seen as slightly better than a code, because copying a full URL into a phishing form is more tedious and suspicious, but still not bulletproof.

Passwords, TOTP, and 2FA

  • Several note that this phishing flow also works against TOTP codes and push-based 2FA: if the user is tricked into typing a current code into BAD, the attacker can relay it.
  • However, passwords + TOTP have advantages:
    • Password managers usually refuse to autofill on the wrong domain, making classic phishing harder.
    • A leaked password alone is insufficient if TOTP is required.
  • Others counter that for most users with weak/reused passwords, email/SMS-based login may still reduce credential-stuffing risk, especially since password reset via email already makes email the de facto single factor.

Magic links and alternatives

  • Magic email links are widely seen as safer than 6‑digit codes, but come with UX problems: embedded email browsers, cross-device flows, link prefetching, and users trained to click any link.
  • Some propose more robust schemes (e.g., PKCE-like flows binding the code to the originating device, capability URLs, or cookies + challenges) but acknowledge complexity.

Passkeys: security vs. lock-in

  • Broad agreement that passkeys (WebAuthn):
    • Are domain-bound and non-phishable in the same way,
    • Never expose private keys, and
    • Work very smoothly in some ecosystems (notably Apple, some password managers).
  • Major concerns:
    • Backups and migration: users can lose access when devices die; cross-platform UX is immature; export formats are not yet standardized or widely implemented.
    • Attestation: fear that sites will require specific hardware/vendors, block “unapproved” managers (e.g., KeePassXC), and create de facto Big Tech lock-in, even if current consumer sync implementations mostly omit attestation.
    • Usability: inconsistent site implementations (is it password replacement? MFA? both?), QR flows that fail, and confusion among non-technical users.

Password managers and real-world behavior

  • Strong advocacy for password managers + strong unique passwords + TOTP as a practical, user-controlled baseline.
  • Pushback that most non-technical people don’t use them and often have poor password hygiene; any scheme must work for that majority.
  • Persistent tension between maximal security, usability for “granny,” and avoiding opaque, centralized control over authentication.