Best implementation I see of this requires you to click the link on whatever device you receive the email on, but it doesn’t transfer the session there - it just triggers completion of the login process on whatever device you initiated the process on.
This is bad (phishing). The better solution is have the login only work on the device where the link is opened, and for cross-device use to also provide an OTP code the user can read on the receiving device and easily type in on the initial device. (Or only provide the OTP code and no link.)
How is that secure against the same phishing attacks that a clickable link is vulnerable to (basically the idea that someone can socially engineer you into a situation where you think you are supposed to complete the auth flow with them, enabling them to sign in as you?)
Well, it doesn't solve the issue of someone sending you a fake login e-mail that you then mistakenly click on, that's true, but the whole point of magic links is that there isn't an auth flow; there's no password for them to steal from you.
In other words:
1. A malicious individual sends them a fake login link
2. The link can't ask them for a username and password because the site doesn't have passwords, just magic links
3. The site could ask them for your OTP code if they have one, but the bad actor doesn't have their magic link and the OTP code expires in a few seconds anyway
4. Without the bad actor actually getting access to a legitimate magic link nothing happens
It does solve the issue of:
1. You visit the site on your device at the same time as they visit on their device
2. They get two e-mails and maybe click on the one that approves your session instead
3. Your session on your device logs in; theirs doesn't so they figure it's a bug and go click the other one. Now you're both logged in.
If you require the session to be logged in by the link directly, it ensures that only the device you're viewing the e-mail on gets signed in; in the above scenario, your malicious session is never logged in, but their legitimate one is.
Agreed! If they all worked like this would be a happy camper. Nothing worse than being in one browser, opening the email, then it opens and authenticates you on the default browser or even better on a different device and needing to forward the link to the other device so you can open it there (yes odd scenario but try not to access certain emails from certain devices).
Sites that send an OTP (crazy-pink-horse-3837) that you can copy, and paste is a good middle ground if implementing the link that just Auths the original request is too difficult.
where? i just went through Settings > Apps > Gmail on my iphone and found nothing about this. Likewise the in-app Settings in the GMail app lets you choose which browser is the "default app" but it's already set to Safari (the other options are Chrome, by Google, and ... Google, by Google). But that uses an embedded
Safari instance inside gmail, not the phone's Safari app.
To get what you want (links open in Safari.app, not the safari webview inside Gmail): configure your default browser in Settings (your iphone settings, not gmail's settings) to be Safari, and then in Gmail choose "Default browser app" instead of Safari.
It's super vague and unclear why things should work this way, and I don't know if this is forced on them by iOS or what. I'm trying to think of why choosing "Safari" in the gmail settings would use the webview instead of the app, and the most-charitable reason I can think of is that they don't want to contribute to the person having hundreds of Safari tabs open...?
Less-charitable reasons might include wanting to keep users in the gmail app for driving "engagement". I read somewhere that when apps use the in-app webview, the app dev can inject arbitrary javascript and thus has full control and can see keystrokes, what the webview's viewport is looking at, etc. I really don't think that's what google is trying to do here, though.
Wow - i even saw the words "default browser app" and did not even realize it was a setting choice. That works - thank you!
wrt reason : I think that the webview has cookie isolation from the actual app, so using the webview is a bit more privacy-protective. Google being Google that seems unlikely to be the motivating reason, but who knows what good may lurk in the heart of men...
Most sites will have a confirmation once you click the link that includes the browser version and IP address. I have seen that info only in the email itself too with no confirmation afterwords, but not for some time. Have never seen one that is just a link with nothing else that once clicked allows the other device in but supposes could be implemented that way.
The article itself is about not making them the only option (which is fair), and the OP says if they do it should login the device which originally made the request (which I agree). If the implementation is just an email with only a link, no other information with no confirmation (yes, it's fine to let this device in), then I would have to agree with you it's very risky and could allow anyone to login as you (hopefully no sites are doing this, but...)
If you really want to allow for another browser to authenticate a login request, you can at least limit it to sessions coming from the same IP.
That would let you authenticate your desktop browser from an email you opened on your phone if you're on your home network, but without becoming widely exploitable by phishers.
Some people will still click the button because they expect it will give them more information about why they received the link. You can add text along the lines of “authorize login on $other_device”, but it’s still risky.
AFAIK, McDonald’s does this with their mobile app (they weren’t letting me log in with my password) But the problem with their implementation was that the magic link that they send you is wrapped in a click tracker whose domain is blocked by pihole (and the likes), and I could not reach the actual auth URL to complete the login process.
A fully competent security team will, on the other hand, carry out a more comprehensive threat modelling exercise and make a pragmatic choice about whether this kind of auth flow is appropriate for your usecase.
The phishing risks for a bank account login are very different than those for a ‘returning player’ login to a casual gaming site for example.
BankID scams in Sweden worked because it did not require there to be authentication between the device that logged in and the device that authorised the login.
The victim got a phone call in which the she got manipulated into authorising something in the BankID smartphone app. But what she was actually doing was authorising the attacker to log into her online bank account.
First after several years (of blaming the thousands of victims for their millions lost) did the system start using QR codes on the screen scanned by the smartphone.
Solvable with the right information in the authorizing email.
Remember that the flow the magic link is part of is one you initiate, that causes you to get an email you are expecting.
That email, and the landing and confirmation page it links you to, can explain very clearly that you are only supposed to authorize this if you are trying to log in on known device in known location that is displaying recognizable number on the screen right now.
Rather than a recognizable number, users should be prompted to select a matching non-pronounceable glyph. Something like the keypads from KTANE [1].
That makes it impossible to text or speak it to a phisher.
Bonus points if you show the symbol as a noisy animated glyph, something like [2], or a link to a DRM'd video showing a symbol. That would make it very difficult to view even with screen recording or remote desktop software.
There is a substantial class of users this would be too much to ask of, i.e. they wouldn’t understand it or would assume that they are being scammed somehow.
The thought of using unpronounceable text to deter phishing attempts reminds me of putting illegible Unicode as challenge question answers to prevent the CSR from giving an account away to convincing social engineers.
> the flow the magic link is part of is one you initiate
There's nothing stopping anyone else from initiating the flow assuming the common implementation where only an email is required to initiate sending the link.
Here is the link you requested from ‘Android Device’ in ‘Belarus’ - click here to sign in and allow that device to access your account - only click this if you requested this email
You don’t click the link if you didn’t request it.
The phisher will be on the phone with their victim, pretending to be a support agent for the business. They will say, "Yes click the link, that's how you verify with us."
So many people on this thread leaping in with the phishing threat model.
This is a simple quick login process, you wouldn’t use it in a place where 2FA is required. It is a mistake to think of this as a substitute for 2FA just because it has some of the same elements as a secondary device authentication. It’s not intended to be a 2 FA flow though! It’s a single factor - ‘does the user have access to a device that can read emails sent to this associated email address’. We aren’t combining it with a password or anything else.
That is the same level of auth used for things on many services like ‘registering for a free account’, and frequently for ‘resetting the password on an account’.
It’s not a complete security solution and you wouldn’t use it everywhere. It would be a bad fit for a banking app or access to a publishing interface. It’s not a bad interface for things like ‘logging in to my subscription on the TV’ or ‘returning as a customer to a website I shopped with once before’.
Yeah exactly. Plus, sometimes SOMETHING will click the link before it even gets to the person's inbox (some enterprise spam filter with a sandboxed browser for example).
edit: saw that nicce basically said that a second before I hit post.
Many email clients will click the link and invalidate it - for example outlook is a classic here - so the best implementation does not use redirects/links at all.
OTP is far better than an actual magic link - you can still include a link that pre-fills the code.
Yes but clicking the link itself shouldn't log you in. Any implementation of magic links that does this is broken because of link previews.
You click the button on the page which knows the session you're logging in from and link code and does a POST which completes the login. This is how all the "login by scanning QR code" flows work.
I’ve been stung by this before, where I’d already closed the original browser tab since I assumed the magic link would open a new tab (as they usually do)
