Passwordless login still needs a device-side confirmation against intercepted links

What it is

Mail and SMS can be copied by a gateway, opened by someone else in a shared inbox, or clicked first by an attacker who already reads the mailbox. Device-side confirmation means that after the link or code is presented, the device that started the sign-in (or a trusted already-signed-in device) must still nod: approve, match a pairing code, or “yes, this is me on this computer.” Single-use invalidation does not stop the first click by someone else; confirmation stops that intercepted redemption. This entry does not rank short-code entropy against links, and it does not discuss paste.

Why it happens

Passwordless treats “possession of the inbox channel” as “the person is present.” Channel possession is often shared: corporate mail archives, a family account, a backup app reading SMS, a malicious extension. If the interceptor’s first redemption mints a session, the person on the original device only sees mail already opened, with no veto. Confirmation splits issuance in two: the channel proved delivery, and the initiator is still online and explicitly agrees. Agreement must bind to the initiating session, not to “any already-signed-in device may tap yes”—a stolen old phone could then approve. People need a coarse picture of the new device (browser, rough place); otherwise approval becomes meaningless confirm-fatigue.

Studying it

Arrange “the link opens in a client other than the initiator” versus “it opens on the initiator,” with and without an approval step, and see who receives the session.

Independent variables: whether the initiating device must confirm, confirmation timeout, granularity of device traits shown, whether a session is still issued without confirmation. Dependent variables: whether the intercepting end gets a session, whether it still enters after the owner refuses, mistaken approvals from unreadable traits, abandonments from the extra step.

“Open it myself in another browser” in the lab only approximates forwarding, not an attacker who owns the mailbox. Role-play with a second person granted mailbox access. Do not treat confirmation completion as a security result: high completion may only mean people habitually tap Yes. Refusal paths, and judging “this trait does not match, so refuse,” are what connect to interception.

Where it stops holding

Opening the mail client and bouncing back into the app on the same device looks like approving oneself; detect “redemption and initiation share a browser session” and skip, or people are trained to approve blindly. With no second signed-in device and the initiating page closed, confirmation has nowhere to go: void the challenge and make them start again, rather than falling back to an unconfirmed link. Low-assurance content subscriptions cannot demand approval on every mail; save confirmation for a new device, a new place, or a high-consequence action. Confirmation is not a pre-enrolled second factor in MFA; it hangs off this sign-in challenge. Enrollment and custody of backup factors are a different problem.

Applying it

• Keep the original page in a waiting-for-approval state when passwordless starts; opening the link elsewhere only reaches “wait for this device to confirm,” and must not mint a session.
• The approval card shows coarse traits of the new end (device class, rough place, time) with an explicit refuse; refuse voids the token.
• Same-browser-session redemption may skip confirmation; cross-browser and cross-device must confirm. On timeout, both ends say “request again,” not a silent sign-in.
• Verify: start “send link” on device A, open the mail link on device B that was not part of the design; B must not enter before A approves, and must not enter after A refuses. Opening mail and app in the same session on A should need no extra nod. When mistaken approvals happen, check whether people can point to the trait on the card that did not match.

Related

• Within the group: H6.03.1 OTP fields must accept paste and autofill · H6.03.2 OTP expiry and resend interval must be visible · H6.03.3 SMS failure needs a fallback channel · H6.03.4 A magic link must expire after one use so forwarding cannot reuse it · H6.03.5 Limit OTP guesses to stop brute-force enumeration · H6.03.6 Magic links and OTP codes are not equivalent authenticators
• Adjacent: H6.12 Multi-factor authentication · H6.06 Multi-device sessions
• Search terms: magic link interception · login approval · device confirmation