"Passwords are dying"<p>NOPE. Magic Links are dieing. This is probably the 20th time I've seen a start-up posting proudly about how they chose magic links over standard auth and I don't think any of them have stuck.<p>It is a TERRIBLE user experience.<p>* We have a tab open on your site, it tells us to go to our e-mail to get a link, and then that opens up a different tab.<p>* Or we only check that address on phone which means we can't easily login on desktop unless we also have that e-mail address logged in on desktop as well.<p>* It removes our ability to use password managers.<p>* Doesn't allow us to have multiple e-mail addresses easily. Now I have to remember what e-mail address I used for your service to go find the magic link.<p>STOP doing it. Give people two-factor authentication. Give people options if you want and see if anyone opts into magic links.<p>All that being said... It looks like this service does require password for sign-up and login right now unless you use google auth? Not sure how this blog post relates to the actual company. Maybe its something they are thinking about doing?
Magic links are really REALLY annoying if cookies get removed often or if you don’t have access to email.<p>Offer a password option, people! Back it up with a magic link if you must but offer a password!<p>Especially if your magic links go to spam.
One big flaw with login links sent to email is the delivery problem.<p>You can't assume the email will be delivered so quickly.<p>Who wants to get locked out of their account because the email has not arrived?<p>Login links can be a convenience feature but they must not be the only mechanism for login.
This is a made-up problem. Passwords are fine. You need some way to authenticate users and using a magic link increases friction if someone uses a password manager or does not have access to their email. I can log in to Bitwarden once and auto-fill any form on any website with one click. Using a magic link I have to:<p>1. wait for the email to arrive<p>2. click on the link<p>3. navigate back to my inbox<p>4. delete the email<p>5. navigate back to the app/website<p>(this is my inefficient way of doing it, I just don't like to have emails lying around that I don't need anymore)<p>> All this work just for the auth, which is not your core product and not what users come to you for.<p>What is part of my core product, if it's not something as basic as the authentication? I dislike the idea to outsource every tiny bit of a solution, especially if it's something I better keep control of.
Quite a few standard password login flows have a "magic link" stream already, in the guise of password recovery -- enter your username on a link, click "forgot password", and get an email with a magic link allowing you to log in (after resetting the password). Which means the security model is not, in some cases, exactly what it appears to be...
One thing I like about the implementation that magic.link provide which isn't clear from reading the article is that the device you use to log into the passwordless service and the device you use to log into your email can be different. For example, I can log into this incidents.sh service on my work PC and click the one-time link on my phone and it will work. No need to sign into my email account on my work PC.
I’m not convinced and personally find it irritating. One data point I can share: Know your team (ex Basecamp) moved from magic links to offering passwords after a while. I think others went down the same path but can’t recall specific names. It’s fun for a short while until it isn’t. Password reset flows are magic link for those who don’t want to remember their passwords.
So now there is a minimum of three companies involved (spike, magic, the email provider) just to log me in - and there is <i>still</i> a password that can be leaked, the one for my mailbox. Great...
I don't get it. Both Chrome and Firefox come with password manager which can auto-generate strong, unique passwords. Magic links are nice, but they should not be the only option.
I think this approach is fine depending on what your product is and who your users are. One obvious callout is that now your login is tied to the delivery of the email. The article claims passwords are an additional form of friction, but so is going into your email and then clicking on a link. Some people use mailservers which as abysmally slow, and you have also now increased the cost of your product by sending more emails through your provider.<p>For me personally, the least friction I experience in a site is one that asks me to put a password and a username on registration and login. Subsequently, if I can optionally enable 2FA from the settings/profile page, I am happy. I use a password manager so this allows me to use a given site pretty easily.
How about this:<p>1. Enter email<p>2. If the hidden password field autocompletes, use it<p>3. If not, send a magic link email that doubles as “someone is trying login” notification AND show the password field<p>So at this point you covered:<p>- people with password managers<p>- people who remember passwords<p>- people who don’t remember passwords
Ugghh, I hate magic links. I use graylisting on my mail server and these magic links tend to take ~10min to arrive – at which point they're usually expired and I have to request another one. :(<p>Email was never meant as a means for synchronous communication, so stop pretending it is!
If widely adopted, then a compromised e-mail could lead to much deeper access than a single compromised password would (except for those who use the same pw everwhere). I understand the motivation, and agree re: the issues of passwords, though.
Here is a related thread discussing this very topic:
<a href="https://news.ycombinator.com/item?id=25628729" rel="nofollow">https://news.ycombinator.com/item?id=25628729</a>
Wow. Who are these people’s customers? I can’t think of a single enterprise company (or really any company using SSO to manage their applications) that would find this acceptable. It would be instantly dead in the water for my small IT department.
Magic links suck. I just want to use my password manager and not login to email first to login to your service after that. Medium for example uses magic links too and it's so annoying.
We use 6 digit codes via email for passwordless. The login links typically just have a code parameter anyhow, and at least Auth0 allows for both. We opted for codes vs links because links add all kinds of session-based issue across browsers and devices. People are able to login on desktop with a code they read in their mobile email, etc.<p>As others have noted, passwordless does hinge on email deliverability and that hasn't been easy to nail. That said, almost all login flows tend to rely on email delivery for both verification and password resets.<p>For those used to the convenience of password managers, its an extra step that can add friction. Longer sessions help.
You can't "solve" passwords because authentication requires something you have or something you know. Not everyone has email, magic links by email are insecure, and it defeats the ubiquity of password managers and keychains. There's no eliminating private keys or passwords anytime soon because it's a utopian aspiration wishing away first principles.<p>What can happen is better federated SSO using OAuth2 like Apple, Google, FB, Github, and/or similar for web applications to defer or eliminate yet another <i>mandatory</i> password.