Magic Links and One-Time Codes

Short answer: A magic link or one-time code lets people log in without remembering a password, because the site sends a secret to their e-mail address or phone. It is safe enough for many sites when the secret is long and random, works only once, expires within minutes, is bound to the browser that asked for it and is protected by rate limits. It is only as strong as the mailbox that receives it, so it is not a replacement for stronger methods on sensitive accounts.

How passwordless e-mail login works

With a magic link, the visitor types an e-mail address and the site sends a message containing a special link. Opening the link proves that the person controls the mailbox, so the site starts a session. A one-time code works the same way, except that the message contains a short number that the visitor types into the login page.

Both methods replace the password with proof of access to an inbox. That removes weak and reused passwords, which are behind a large share of account takeovers, and it removes the need for a password reset flow, since logging in already is a reset. For visitors who log in rarely, such as customers of a small shop, it is also more convenient.

Where the risks are

The trade-off is that the security of your site now depends on things you do not control. Anyone who can read the visitor’s e-mail can log in as that visitor. A stolen phone with an open mailbox, a compromised mail account or a shared family mailbox all become a way into your site. The method also adds new places where bugs can appear: the token itself, the link, the request form and the delivery of the message.

The attacks that matter most are guessing or reusing tokens, intercepting links, tricking users into opening links that log them into the attacker’s session, flooding the form and abusing it to send unwanted mail. Each has a defence that is cheap to build if you think about it in advance.

Consider a small online shop that lets customers log in by e-mail to see their orders. A customer types the address, receives a link, and within a minute sees the order history. That is a good experience, and the data at stake, a list of past purchases and a delivery address, is modest. Now compare it with a staff member who can refund orders. If the same link logged them into the admin area, a single compromised mailbox would give an attacker the ability to move money. The method is the same, but the risk is very different, so the protections should differ too. Decide how much damage a stolen session could do before you choose how strict the login should be.

Build the token correctly

Make it unpredictable. Generate it with the cryptographic random generator of your platform, at least 128 bits long. Never build it from the e-mail address, the time or a counter.
Store only a hash. Keep a hash of the token in your database, not the token itself, so that a leaked database does not give attackers working links.
Make it single use. Mark the token as used the moment it is accepted, and reject it afterwards. Prefetching by security software can open links before the user does, so consider a confirmation button on the landing page instead of logging in on the first request.
Let it expire quickly. Ten to fifteen minutes is common. A code for a sign-in can be even shorter. Old tokens should be invalid as soon as a new one is requested.
Use a long code if you use digits. A six-digit code has only a million combinations, which is safe only with strict attempt limits.

Bind the link to the browser

A subtle attack works like this: an attacker requests a login link for their own account, then persuades a victim to open it. The victim’s browser logs in as the attacker, and anything the victim then enters, for example payment details or personal data, goes into the attacker’s account. To prevent it, bind the token to the browser that requested it. When the visitor asks for the link, set a random value in a cookie and store its hash next to the token. When the link is opened, accept it only if the cookie matches. If the visitor opens the link on another device, show a code to type on the original device or ask them to confirm.

This is more friction, but it removes a whole class of tricks. For low-risk sites you can accept the trade-off in the other direction, as long as the account holds nothing sensitive.

Limit requests and attempts

The request form can be abused to send many messages to one address, harassing the owner or hurting your sender reputation. Limit the number of requests per address and per IP, add a small delay between messages and show the same response whether or not the address has an account, so that the form does not reveal who is registered. The guide to rate limiting explains the techniques. For codes, limit the number of wrong attempts, for example five, and then invalidate the code. Without this, an attacker can try all million combinations.

Automated scripts that submit thousands of addresses are also a form of abuse. Bot protection on the form, described in the comparison of captcha options, can reduce it.

Deliver the message reliably

A login method that depends on e-mail fails when the message does not arrive. Send the message from a domain with correct authentication, as the guides to SPF, DKIM and DMARC describe, and treat it as a transactional message with its own, clean sending stream. The article on transactional and marketing e-mail explains why mixing them hurts delivery. Keep the text short and clear, state the expiry time and tell the reader what to do if they did not ask for the message. Avoid link shorteners and heavy tracking, since they make filters suspicious, as the article on tracking domains in e-mail shows.

Always give a fallback. If a visitor cannot receive the message, they need another way in, but that fallback must not weaken the whole system. A support process that resets access on request by e-mail is an easy target for social engineering, so verify identity before you change the address on an account.

When it is not enough

For accounts that hold money, personal records or administrative power, an inbox alone is a thin protection. Add a second factor, or use a stronger method such as passkeys, which are bound to the device and resist phishing. See passkeys for websites and the article on two-factor authentication. Administrators of a content system should not log in only by a link to their mailbox. For ordinary customer accounts on a small shop, a magic link with the protections above is a reasonable choice.

Think also about what happens after the login. A session that stays valid for months on a shared computer undoes the care you took with the token. Give sessions a sensible lifetime, let people log out and revoke all sessions, and ask for the link again before sensitive actions such as changing the e-mail address or the delivery details. Notify the account owner by e-mail when a new device logs in, so that a stranger’s access does not go unnoticed. These small steps cost little and make a passwordless system much more resilient in daily use.

A short checklist

Token generated with a cryptographic random generator, 128 bits or more.
Only a hash stored, single use, expiry of minutes.
Token bound to the requesting browser or confirmed by a button.
Rate limits on requests and on attempts, with identical responses for known and unknown addresses.
Links over HTTPS only, with a session cookie set with secure flags, see cookie flags.
Authenticated, transactional e-mail with a clear message.
Second factor for sensitive accounts.

Check the basics of your site

Passwordless login only works well on top of correct HTTPS and authenticated e-mail. Run a free check with Site AI Audit to see your certificate, security headers and SPF, DKIM and DMARC records in one report.

The bottom line

Magic links and codes are a practical way to remove passwords, but they move the weight of security to the mailbox and to your implementation. Use strong single-use tokens that expire fast, bind them to the browser, limit requests and keep a second factor for anything valuable.

FAQ

Is a magic link safer than a password?

It removes weak and reused passwords, which is a real gain. It is not safer when the mailbox is poorly protected, so the result depends on the account that receives the message.

How long should a magic link stay valid?

Ten to fifteen minutes is a common choice, and shorter for one-time codes. The link should also become invalid when a newer one is requested or after the first use.

Why does my link sometimes say it was already used?

Some mail security tools open links to scan them, which can consume a single-use token. A landing page with a confirmation button avoids the problem, because scanners do not press it.

Should I show whether an e-mail address has an account?

No. Show the same message either way, such as “If this address is registered, we have sent a link”. Otherwise attackers can use the form to find out who your customers are.

Can I use a six-digit code?

Yes, if you limit wrong attempts, expire the code quickly and tie it to the request. Without those limits, a million combinations is small enough to be guessed by a script.

Magic Links and One-Time Codes: How Safe Is Passwordless Login?