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.
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.
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.
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...
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.
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...)
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.
edit: saw that nicce basically said that a second before I hit post.
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.
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.
[1] https://www.bombmanual.com/web/index.html#:~:text=On%20the%2...
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.
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’.
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.
OTP is far better than an actual magic link - you can still include a link that pre-fills the code.
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.