Live data from Hacker News

Are Magic Links Outdated?

zitadel.com

191–200 of 230 posts

Re: Are Magic Links Outdated?

#191
post #178

Earlier quoted context omitted.

At Clerk, ( https://clerk.dev , auth SaaS) we did a ton of work to get magic links to play nice with multiple devices, it's certainly a pain, and there's tradeoffs. The crux of it is, do you sign in the "originating" device (where the magic link was sent from), or the "consuming" device (where it was clicked). Because it's veryyy common for people to be on a website on their computer, then click the link on their pho…

Never do this. Automated email scanners may fetch the URL. For example, Hotmail’s mail delivery process is notorious for triggering magic links.

You can defend against this a little bit by having the magic link load a page with a button (which submits a POST action) that you have to click.

Re: Are Magic Links Outdated?

#192

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…

They don't need to be - this is a limitation of how the site has implemented magic links. When implemented best, clicking the magic link in your email should simply confirm the authentication, and your _original_ browser window/tab should be signed in.

That way, you can be signing in on a desktop browser, click the email link on your phone (or a different browser sandbox), and the desktop window will be signed in.

Re: Are Magic Links Outdated?

#193
They’re yet another way for logging in to suck for people who use a password manager.

Another example of this is consumer apps that insist that you should login with your phone number and make you click an extra button to change to the email login option.

Re: Are Magic Links Outdated?

#194

Earlier quoted context omitted.

If you're storing your "multi-factor" authentication codes in the same place (ahem, "factor") as your password, you're doing it wrong.

I used to think this but I don’t agree any more. A factor is a factor: your service password + your password manager password = 2 factors. Yes, if someone compromises your password manager then you’re in a bad position but that’s not what service-level multi-factor authentication protects against.

> that’s not what service-level multi-factor authentication protects against

I don't understand your point. This is exactly what multi-factor authentication protects against if you don't store your MFA codes in your password manager.

Re: Are Magic Links Outdated?

#195

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…

one time code is far, far easier when apple is able to autocomplete it

Re: Are Magic Links Outdated?

#196
Anyone have advice for creating easy-to-use-yet-secure login solutions for users who are less tech-literate?

My company is an ISP, and most of our customers are not very "good" at using technology. Any yet, they do sometimes want to log into our dashboard for one reason or another, and it tends to be a lot of trouble.

We've found that:

- Many people do not have an email. Some people don't have a phone number. Many people have only one or the other, but not both.

- People typo their emails... a LOT. I initially had some very simple validation for email addresses, until I started getting droves of emails that were one character off. I'm at this very moment working on a feature to alert users if they type "gmail.co", "gmail.con" or "gnail.com", which are all very common (and two of which are completely valid domain names by the way!).

- Some people get confused by "creating a new account" or dealing with multiple accounts in general. They'll say "my email login didn't work." Well, to me it's obvious that they have a different password for different accounts, but to them it's not.

- Building on that, they are not great at password resets. The "send a password reset to email" thing is confusing to them, because from their perspective their email is the account. Am I resetting my email password?? They don't like it so they don't want to do it.

- Since we are an ISP providing customers with WiFi, there is also confusion between the WiFi password and the dashboard password. I've had people successfully reset their dashboard password, expecting it to also set their WiFi password.

- Literacy can also be less than ideal. I once reset a customer's WiFi password over the phone, and the new password contained an exclamation point. She didn't know what an exclamation point was. I got her to do SHIFT-1 eventually, but it took a while. (I found out later that nobody else sees an exclamation point as an "upside-down i", which is what I've always seen it as. The proper way to describe it to someone who doesn't know is "line with a dot underneath".) Now my password generator only uses A-Za-z0-9 (but not 0 or O).

So, I have been learning the hard way that not every person in the world is an avid Hacker News reader who knows what accounts and password hashes are and how everything works. And yet, these people deserve to be empowered by technology just like the rest of us.

The thing is, many of these folks are able to use software just fine, it's just that they have trouble getting logged in. It really is the logging in that trips everything up.

So I've been thinking lately that I want to fix this for my company, but I'm unsure what to try.

I had the thought of trying Webauthn, but that seems unusable for me as per this comment I wrote a few weeks ago[0]. If I could solve the problem in that comment, I think a lot of my customers would use "Login with TouchID", "Login with FaceID", etc.

Anyway, my point is that no, I do not think magic links are outdated. We use a lot of magic links. Need to update your credit card? We'll text you a link. Want to reschedule your install? We'll text you a link. This is the best way we've found to actually get our software into the users' hands.

[0] https://news.ycombinator.com/item?id=31850471

Re: Are Magic Links Outdated?

#197
post #82

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…

> 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. It might be howling into the void but the conclusion I reach from this is that "Mobile email clients are a nightmare". Generally speaking, embedded browsers in mobile apps are a terrible idea and break user expectations in multiple ways.

Back in the day on the web site the marketing team always insisted links open in a new windows b/c customers won't ever come back if you direct them away. Eventually browsers let users override that nonsense. The insistence by our marketing team on all these embedded browsers reminds me of the same mindset in 2020.

Re: Are Magic Links Outdated?

#198
post #175

Earlier quoted context omitted.

You're over complicating this. In fact it might provide a similar kind of protection the physical chip provides for debit cards. Let me explain: 1. Someone (anyone) initiates the login flow 2. The user record in a DB gets enriched with - the 6-digit OTP (sent via email) - the "secret" (shared with the initiating browser) - the current session failed attempts counter (default: 0, max: 3) - the total failed attempts co…

>In fact it might provide a similar kind of protection the physical chip provides for debit cards. Let me explain: You didn’t explain how this gives you any protection akin to a physical chip on a debit card… Let me illuminate the problem with a real-world analogy: this system is like me walking into a bank with a list of account names, and the bank issuing me debit cards for those accounts with random PIN codes, no…

> You didn’t explain how this gives you any protection akin to a physical chip on a debit card…

In both cases you (an admin) control how many attempts you wish to accept before sacrificing the usability over security (temporarily disabling the card and forcing you to call the bank and disabling 6-digits OTP in favour of ie. 12-digits OTP).

Your real-world analogy is, this time, too simplified :) Let me counter-argument with my example:

You are in a a possession of 1 million user emails and request OTPs for all of them (let's assume no other security measures are in place). If you hit all of the 1M records with 3 attempts of OTP - according to my simple experiment - you might hit (on avg) 3.18 accounts.

Of course, in real life, your attack would be mitigated on other (non-application) level.

Please find my ugly code for that experiment: https://pastebin.com/S2ufabhU

PS. When OTP size is increased to 7 digits - the avg account hit drops to 0.33. For 8 digits - it drops to 0.02. (please mind I'm using lousy RNG :)

PS2. What I'm trying to emphasize is that there's nothing wrong with OTP-auth like this if properly implemented with other basic anti-bruteforce techniques. You could get "better" results with simple password spraying.

Re: Are Magic Links Outdated?

#199
post #78
post #69

Earlier quoted context omitted.

Microsoft Authenticator - syncs your codes to the Cloud so you can pull them elsewhere (which your phone is out of action.)

Doesn't that defeat the purpose to a degree?

Microsoft thinks it is fine for most user's threat models because these use two stacked layers of encryption: your Microsoft account and either Apple's cloud backup encryptions or Google's. To move these codes between devices you have to login in both your Microsoft account and also your Apple or Google account in quick succession. I know on Apple devices it works in the same (iCloud) backup layer that disables other device keys so doing this on a new device will "break" access on the previous device (only one device at a time has access). (I'm not sure about Google's ecosystem.) You can't easily switch ecosystems with this. Microsoft seems to think it unlikely enough that both your Microsoft account and your device ecosystem account will be compromised at the same time that there is enough security in this depth.

Re: Are Magic Links Outdated?

#200
post #198

Earlier quoted context omitted.

>In fact it might provide a similar kind of protection the physical chip provides for debit cards. Let me explain: You didn’t explain how this gives you any protection akin to a physical chip on a debit card… Let me illuminate the problem with a real-world analogy: this system is like me walking into a bank with a list of account names, and the bank issuing me debit cards for those accounts with random PIN codes, no…

> You didn’t explain how this gives you any protection akin to a physical chip on a debit card… In both cases you (an admin) control how many attempts you wish to accept before sacrificing the usability over security (temporarily disabling the card and forcing you to call the bank and disabling 6-digits OTP in favour of ie. 12-digits OTP). Your real-world analogy is, this time, too simplified :) Let me counter-argume…

So you actually agree with me.

1. I don’t have any problem with OTP-based magic links, if they’re implemented carefully. As you’ve just demonstrated, a 6-digit OTP with 3 retries allowed is not sufficient at scale.

2. I’ve also demonstrated that OP’s proposal to augment the 6-digit code with a “secret” token gives you no additional security. It can only protect against someone peeking over your shoulder to snatch your OTP.

3. As you’ve just demonstrated, increasing the OTP length will mitigate the problem, as it increases entropy. For peace of mind, I’d recommend 64 bits of entropy, which can be achieved with a 13-letter alphanumeric code (case insensitive), or with 5 words from a dictionary of 10 000.

Post reply on HN