A magic link is a passwordless authentication method: instead of verifying a password, the service emails you a one-time URL containing a high-entropy token. Click it, the server validates the token, and you're logged in. No password is ever set, stored, or transmitted. The same pattern shows up as a one-time code you type instead of a link — same model, different delivery.
The appeal is genuine, and so are the trade-offs. The honest framing is not "magic links are secure" or "magic links are insecure" but "magic links move your security boundary, and you need to know where it lands."
What the Model Actually Removes
The wins are real and worth stating plainly. Passwords are responsible for an enormous share of account compromise — not because the cryptography fails, but because humans reuse them, pick weak ones, and get phished. Removing the password removes that whole failure class:
- No password reuse. There's no password to reuse across sites, so a breach elsewhere can't be replayed against you. This kills credential stuffing at your service.
- No password database to steal. A leaked user table contains email addresses and token metadata, not password hashes an attacker can crack offline.
- Proof of email control on every login. Each sign-in re-confirms the user controls the inbox, which doubles as continuous email verification.
- Lower friction. No "forgot password" flow, because there's no password — the normal login is the recovery flow.
Where the Secret Went
Here's the part the marketing skips. Notice that the "forgot password" flow on a traditional site is itself usually... a magic link. Password reset has always meant "we email you a link to regain access." Magic-link auth simply makes that the front door instead of the back door.
Which means the security of the account now rests entirely on the security of the email account. Your inbox was already a master key — most services let you reset their password through it — but magic links make that dependency total and explicit. If an attacker controls your email, they control every magic-link account you own, directly and immediately.
Magic links don't remove the master secret. They consolidate it into your email account. That's a reasonable trade when your email provider has strong security — and a dangerous one when it doesn't. The chain is exactly as strong as your inbox.
The Threats That Don't Go Away
Going passwordless via email closes some doors and leaves others open. Be clear-eyed about which:
| Threat | Magic links help? |
|---|---|
| Credential stuffing / reuse | Yes — no password to stuff |
| Password DB breach | Yes — nothing to crack |
| Phishing | No — a fake "sign-in link" email is itself a classic phish, and real-time relay of the token works |
| Email account takeover | No — it becomes the whole game |
| Email interception in transit | Depends on mail-path TLS, which the user can't see or control |
| Link landing in logs/history | No — URLs leak into proxies, browser history, link previews |
The phishing point deserves emphasis because it's a common misconception. Magic links are not phishing-resistant. An attacker can build a fake login page, capture your email, trigger a real magic link to be sent, and relay it. Unlike a passkey — which is cryptographically bound to the real site's origin and simply won't sign for an impostor domain — a magic-link token is just a bearer secret. Whoever clicks it first wins.
Building One That Doesn't Bite You
If you implement magic links, the details separate a safe deployment from a liability:
- High-entropy tokens. Use a cryptographically secure random generator — at least 128 bits. Store only a hash of the token, so a leaked database doesn't hand over live links.
- Short expiry. Minutes, not hours. The link is a transient credential; treat it like one.
- Strictly single use. Invalidate the token the instant it's redeemed, and invalidate any older outstanding links for that account.
- Bind to the request context. Where possible, require the link to be opened in the same browser session that requested it, so a forwarded or intercepted link is useless on its own.
- Rate-limit issuance. Prevent attackers from spamming a victim's inbox or using your mailer as an abuse vector.
- Don't leak via referrer or previews. Account for link-scanning and preview bots that "click" links in transit — a naive single-use token can be burned by a security appliance before the user ever sees it.
A magic link is a bearer token wearing a friendly costume. Anyone who possesses it is authenticated. Every design decision should flow from that one uncomfortable fact.
Where It Sits Among the Alternatives
Magic links are a reasonable middle tier: better than passwords for casual accounts, worse than hardware-bound credentials for anything high-value. The progression of strength runs roughly: reused password → unique password in a password manager → password plus a second factor → magic link (email-bound) → passkey (origin-bound, phishing-resistant).
For a low-stakes service where the worst case is an attacker reading a newsletter, magic links are a fine, low-friction choice. For anything holding money, health data, or private communication, the right answer is a credential bound to your device and to the real site — not a secret that travels through the inbox and can be relayed.
Where Haven Fits
This is precisely why Haven does not gate your encrypted content behind an emailed link. Your account is anchored by keys derived on your device from a passphrase that never leaves it — there is no bearer token that, if intercepted, would hand someone your messages. An attacker who compromised your email would not thereby gain the ability to decrypt your Haven communications, because the decryption keys were never in any inbox to begin with. Magic links are a fine convenience for low-stakes logins; they are the wrong foundation for end-to-end-encrypted communication, where the entire point is that no single channel — least of all email in transit — should be able to unlock your data. If you're weighing authentication models, our comparisons of hardware keys vs authenticator apps and two-factor methods go deeper.