11–20 of 230 posts
I hate them. Force me to go to my mailbox while I have a good password manager and just want to use that instead. I get the idea, but this should be an alternative, not a default. Also sends loads of single use emails that will remain for ever in users mailboxes.
It depends. I used magic links for a system where the user would log in every 6-12 months. It didn't make sense to force them to make a password.
Register:
1. I click the password field.
2. I click "use autogenerated password"
3. Sign up.
For login:
1. Click "login".
The magic link experience is comparatively awful:
1. My email address never auto-fills so I need to click the field and select the completion suggestion. This is even worse if I am using a per-site email address.
2. Click login.
3. Go to my email.
4. Most often wait a few seconds.
5. Click the link. (add extra steps if I want to open in a private window or container tabs, or tons of pain for a different device)
6. Delete the email.
7. Find the new tab.
8. Maybe drag it to the right location in the tab bar or the right window.
And that is assuming that my email providers likes your email and it doesn't get greylisted, put in spam or even outright rejected.
Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop.
In our app (Loomio) we default to magic/codes, but let users use passwords if they prefer.
I hate them. Force me to go to my mailbox while I have a good password manager and just want to use that instead. I get the idea, but this should be an alternative, not a default. Also sends loads of single use emails that will remain for ever in users mailboxes.
If it's magic link or multi-factor authentication, I know which one I prefer. Try explaining to an MFA-loving service that your phone is out of action while it's being repaired.
I hate them. Force me to go to my mailbox while I have a good password manager and just want to use that instead. I get the idea, but this should be an alternative, not a default. Also sends loads of single use emails that will remain for ever in users mailboxes.
I'm mildly surprised that one of your complaints is that these fill your email. It seems simple enough to delete them?
I can't quite put my finger on why it's different from having SMS 2FA codes in my Signal inbox, but it feels like more clutter.
MagicLinks are a mobile nightmare. Mobile email clients use their own browser and cookie jar which consume the session cookie you're trying to put into the user's main browser. This results in users 'never staying signed in' and a lot of frustration. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…
So I could log into GitHub and save the cookies in a bookmarklet.
Then every time I want to use GitHub, I click the bookmarklet and it sets the cookies, so I am logged in.
I dabbled with the idea a bit, but it seems not straight forward. Maybe due to some metadata that cookies carry. They are not just key:value pairs.
For example here on HN, when I type "document.cookie" into the console, I get back an empty string.
I've been thinking about magic links using QR codes rather then email. EDIT: The idea here is that on a device where you're already logged in you generate a QR code, you photograph that code on another device, and then you confirm on the first device that it's really you who photographed the code on the other device.
I don't understand. What would the QR encode? Surely not the magic link itself, as that would defeat the purpose.
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?
Earlier quoted context omitted.
Also a possible way for magic links to be secure even if email is compromised is for the requesting browser to create a secret client side so that only that browser can actually proceed with the magic link.
If the email is compromised, the hacker can just go to the front page in their own browser and generate a fresh login email, so there's no extra protection in client-side browser secrets.