Magic/tragic email links: don't make them the only option

Original Article ↗ Hacker News Discussion ↗

Overall sentiment

  • Strongly mixed but skewed negative.
  • Many find email magic links frustrating or unsafe as the only login method, especially compared to passwords + managers or passkeys.
  • Some defend them as simpler for non-technical or infrequent users and useful in specific contexts.

Usability and UX of magic links

  • Multi‑device pain: email often isn’t available on work laptops, gaming PCs, TVs, or shared/corporate devices; users end up forwarding links, copying long URLs, or creating QR codes.
  • Slower and fragile: SMTP delays, spam filters, graylisting, corporate firewalls, and .zip TLD blocking frequently interrupt flows.
  • Distraction: being forced into an inbox breaks task flow and leads to users getting “lost” in email.
  • In‑app browsers: email/RSS/Slack clients open links in embedded WebViews or wrong browsers, stranding the session.
  • Frequent re‑logins plus magic links (e.g., some AI tools, banking apps) push users to abandon products.

Security considerations

  • Email as single factor: if email is compromised, accounts are too; many point out this is already true for password resets.
  • Phishing risk: training users to click login links in email normalizes behavior phishers exploit; QR login has similar abuses.
  • Anti‑phishing scanners and link previewers auto‑click links, consuming one‑time tokens or auto‑confirming actions.
  • GET‑based logins violate the “GET must not change state” norm and interact badly with prefetchers and security tooling.
  • Some implementations log in the requesting device when the link is clicked elsewhere, which can be a “phisher’s dream.”

Alternatives and mitigations

  • Email/SMS OTP codes are widely seen as a better middle ground: work cross‑device, avoid link auto‑clicks, but remain phishable.
  • Recommended mitigations:
    • Link → landing page → explicit “Confirm login” POST.
    • Couple link to a browser cookie or IP; if mismatch, require extra confirmation or OTP.
    • Include device, location, and browser info on confirmation screens.
    • Provide backup codes or allow passkeys/passwords alongside magic links.
  • Some advocate QR‑based cross‑device flows, but note they are heavily phished in practice.

Passkeys and other auth methods

  • Passkeys praised for strong security and quick UX on existing devices; suggested as primary, with email OTP/magic links as recovery.
  • Concerns:
    • Recovery and vendor lock‑in (loss of device, platform bans, sync failures).
    • Poor fit for untrusted or shared devices where users don’t want their whole passkey store.
    • Legal issues around biometrics vs passwords in some jurisdictions.
  • Many still prefer traditional username/password + password manager + TOTP for control, speed, and predictable cross‑device use.

When magic links are seen as acceptable

  • Low‑risk, infrequently accessed tools, simple enterprise utilities, guest checkouts, unsubscribe links, and “grandma‑friendly” apps.
  • Several argue they can be “good” in such niches, but “not the best,” and should rarely be the only option.