5 ms·

Another relatively new problem with magic links specifically on mobile is that your email client will likely open the link in an embedded browser which is typic

by mojuba 4y ago

Another relatively new problem with magic links specifically on mobile is that your email client will likely open the link in an embedded browser which is typically isolated from the main browser app and doesn't share the cookies with it. There are some workarounds for this but they don't seem very secure, plus they add some complexity. E.g. once the backend validates the magic link click, it logs the user in also in the browser that initiated the email send. I think a sort of a phishing attack is possible here. Also the page that initiated it should periodically refresh itself to see if the session was validated somewhere else. I haven't been able to find any more secure or simpler solutions to this problem. Any thoughts?

mffap 4y ago
> Also the page that initiated it should periodically refresh itself to see if the session was validated somewhere else. I guess the link must be disabled / invalidated after first use and your auth server and client obviously must verify if a given link is still valid.
- mojuba 4y ago
  Of course the link should be invalidated, but that doesn't protect from a situation where an attacker initiates a login, then the user receives an email and clicks. The chances are slim but some people might get confused and click without much thinking - and voila, the attacker has a valid session.
  - pritambaral 4y ago
    Simply opening a Magic Link doesn't have to authenticate the initiating login. The user can be asked to interact with the page, being shown the source of the link (time, browser, device, IP/Region, etc.), to authenticate the login. This adds a little bit of friction to legitimate cases, but then again having to open your email and find a link and click it is already plenty of friction that this additional step can be considered a negligible addition to that.
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 mojuba 4y ago

mffap 4y ago

> Also the page that initiated it should periodically refresh itself to see if the session was validated somewhere else. I guess the link must be disabled / invalidated after first use and your auth server and client obviously must verify if a given link is still valid.

mojuba 4y ago
Of course the link should be invalidated, but that doesn't protect from a situation where an attacker initiates a login, then the user receives an email and clicks. The chances are slim but some people might get confused and click without much thinking - and voila, the attacker has a valid session.
- pritambaral 4y ago
  Simply opening a Magic Link doesn't have to authenticate the initiating login. The user can be asked to interact with the page, being shown the source of the link (time, browser, device, IP/Region, etc.), to authenticate the login. This adds a little bit of friction to legitimate cases, but then again having to open your email and find a link and click it is already plenty of friction that this additional step can be considered a negligible addition to that.

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.