3 ms·

The way I've implemented in one of my own projects [1] but that I'm not fully happy with (and the way that Amazon.com does it) is to do what you suggest: create

by ammmir 4y ago

The way I've implemented in one of my own projects [1] but that I'm not fully happy with (and the way that Amazon.com does it) is to do what you suggest: create a record on the backend when the login attempt begins and have your frontend keep checking that record until there is a result like email verified/not-verified/timed-out. When the user clicks the magic link in the email, update that record with their choice to approve or reject the login, or ultimately time out and invalidate the login attempt. This avoids the separate cookie jar problem. The phishing scenario is a real one, though. People have been conditioned to click Yes on everything. Coinbase's magic links implementation, for example, requires you to click the magic link in the same browser session that initiated the login. This is a bit more secure, although annoying from a UX perspective if you're in an embedded WebView like you mentioned. The middle ground is something like instead of sending a link, send a code via email that you enter on the website, but that just removes the magic of magic links and is no different than what it was before! [1] https://loginwith.xyz https://loginwith.xyz

notahacker 4y ago
> The middle ground is something like instead of sending a link, send a code via email that you enter on the website, but that just removes the magic of magic links and is no different than what it was before! Wouldn't an even better middle ground option be defaulting to magic links, with the magic link destination both logging in and notifying the user that if they user want to switch [back] to a different web browser or device they can use their email and $TIMELIMITEDCODE? (Perhaps with the notification disabled if the browser which opens the magic link shares a cookie jar with the browser session which requested the magic link, and perhaps including a "You recently tried to access using $RequestOriginatingBrowserName on $DeviceID" to hint they might want to get out of their mail client) Offers both the magic bit and a non-magic way to escape from the sandbox that is less likely to be a vector for speculative phishing attacks.

by ammmir 4y ago

notahacker 4y ago

> The middle ground is something like instead of sending a link, send a code via email that you enter on the website, but that just removes the magic of magic links and is no different than what it was before! Wouldn't an even better middle ground option be defaulting to magic links, with the magic link destination both logging in and notifying the user that if they user want to switch [back] to a different web browser or device they can use their email and $TIMELIMITEDCODE? (Perhaps with the notification disabled if the browser which opens the magic link shares a cookie jar with the browser session which requested the magic link, and perhaps including a "You recently tried to access using $RequestOriginatingBrowserName on $DeviceID" to hint they might want to get out of their mail client) Offers both the magic bit and a non-magic way to escape from the sandbox that is less likely to be a vector for speculative phishing attacks.