[mooreds]

Lots of issues with magic links. And yet, and yet. For a certain class of accounts, I'm okay deferring to my email inbox.

From a security perspective as a user, it's no different than deferring to a social provider like Google, but has the benefit in that it gives a user more control over the third party they choose to delegate control to.

You allow username/password access and that's great too. I'm a fan of giving users options, but I don't know if anyone has done studies and found that a single login option actually is better for conversion. I'd be interested in seeing some numbers around that.

I wouldn't recommend a magic link for high value accounts, but I have pretty easy access to my mailbox, from everywhere (in contrast to my password manager, which is cumbersome to use from different accounts). I can also forward the email with the link to any device where I have email.

If it is a low-value account that I use infrequently, I'm a fan. The alternative is to just use 'forgot password' to get a link that resets my password. That is pretty much the same functionality.

I guess the hard part there is that no one building software thinks their app is 'low-value'. :)

[wongarsu]

From a security perspective, most passwords can be reset by email, so sending a magic link or code to the email has approximately the same security properties.

The only real difference is if the password reset forces you to change the password and logs you out everywhere, then you can at least detect the break-in more quickly with the password approach.

[nisegami]

>I guess the hard part there is that no one building software thinks their app is 'low-value'.

I know the things I'm working on are low-value and appreciate it. In fact, I genuinely dread ever working on something high-value.

[adrr]

If the high value account does password resets via email a magic link email is no less secure. Even banks do password resets by email but combine it with private info like SSN which really isn't private due to all the breaches like equinox.

Email is the master key to most of your accounts.

[ninkendo]

> Email is the master key to most of your accounts.

I’ve been mulling over ideas for this in my head for a while, about fully standardizing the magic-link-to-login approach as a full single-sign-on implementation.

Sites could craft an email with a specific header scheme that denotes what it’s trying to do, for what website, and what the magic link key is. The body of the email would still look like a regular magic link email as it does today, as a graceful fallback behavior.

The website login screen could detect if the user agent supported magic links (best way to do this detection is TBD…), the requirements being be that (a) The OS has an email account configured for the user (like via Mail.app or similar), and (b) the OS can broker the security information of the magic links to the browser so that it doesn’t need “full” access to your email, just a standardized API for the browser to get the magic link header info.

If everything checks out, the UX for the login page would be:

- User: enters email address to log in with, hits submit

- Webpage: renders a quick loading spinner

- Website: Sends a magic link email to the email address

- OS: Sees the special magic link email and notices that the browser is in focus on the same origin (using an origin policy that requires the magic link’s headers matches the same origin as the page)

- Browser: Gets magic link/token from the OS

- Browser: Submits token to website

- User sees the login succeed.

- (Optional:) The mail client puts the email itself in a trash folder or some other place so the user doesn’t even notice it (although they should be able to dig it up if they want.)

The graceful fallback if the browser/OS setup is not supported would be that the website just renders the same “check your email for a link” page it would have normally sent.

Apple has enough integration to easily implement this on iOS and macOS, it would be great to see this happen. They already implement autofill for security codes sent to SMS or email, so they already have a similar level of integration, it just needs to be made seamless and not even require user input. It could also be a totally open standard so that any OS/desktop environment/etc could implement it.

[lkbm]

I was recently thinking something similar for implementing a 2fa similar to how Google and Apple do it: pop up a notification on your phone asking "Is this login you?"

Throw some structured data into the email. Email clients can detect and do the popup that hits a callback endpoint. Clients that don't support it still get the code via regular email.

I avoid the OS-layer implementation at the expense of the user having to confirm it's them, but this also means it works cross-device, which is what I'd want for 2fa anyway.

[mooreds]

What is the win of this over webauthn (if the website supports it)? I guess the big win is that the graceful fallback is smoother.

Seems like a lot of moving pieces that only an OS vendor (who controls both the browser and the email client and could build the integration between them) could implement.

[adrr]

Webauth authenticates the device. Still need a way to authenticate the user then you can use webauth going forward on the device. This is assuming you’re using the TPM chip on the device and another FIDO2 device. Standard user won’t have a FIDO2 device like a yubikey but if their phone or computer is relatively new, they will have a TPM chip.