Why we went passwordless on our new product
spike.sh"Passwords are dying"
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.
It is a TERRIBLE user experience.
* 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.
* 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.
* It removes our ability to use password managers.
* 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.
STOP doing it. Give people two-factor authentication. Give people options if you want and see if anyone opts into magic links.
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?
Totally agree. I advise all of my clients away from "password less" because it's a terrible UX.
I recently moved all of my email forwarding away from ImprovMX and a big reason was the obnoxious passwordless system. There are a few others I've bailed on as well for the same reason.
"It looks like this service does require password for sign-up and login right now unless you use google auth?"
We have implemented magic link in our new product, also as a way to trying out the tech and understanding user feedback. Appreciate your comments and a lot of great feedback from the discussion on this post in general.
Magic links are really REALLY annoying if cookies get removed often or if you don’t have access to email.
Offer a password option, people! Back it up with a magic link if you must but offer a password!
Especially if your magic links go to spam.
Its an even bigger friction for users, essentially I have to login to another service to login to yours.
Maybe they should offer a mobile app that works like microsoft and google where you get a notification and you click approve or deny on the phone. Basically, use traditional 2fa as the only factor instead of the second factor.
Another app is worse than another website.
True, but I think most people are signed in to at least one email account on their phone, so in the ideal case it's as easy as two clicks: 1 to open the email notification, and 1 to click the magic link.
I wonder if it could be securely done with the web notifications API, to make it 1 click?
Click on the service you want to log into, wait 30 seconds-10 minutes for email to arrive, THEN click on email and click on magic link.
And end up clicking on it on the wrong device and now you’re logged in on your phone instead of the desktop.
One big flaw with login links sent to email is the delivery problem.
You can't assume the email will be delivered so quickly.
Who wants to get locked out of their account because the email has not arrived?
Login links can be a convenience feature but they must not be the only mechanism for login.
How about a code delivered through SMS? Especially for mobile apps?
Same problem. A good login mechanism needs to rely on a "previously agreed upon" mechanism to perform the login and not break because an SMS or email is delayed. A password works this way. TOTP/HOTP 2FA also works this way.
The trade off is higher security vs sites with passwords or an reset email option.
How are magic links higher security than passwords + two-factor auth? A magic link gives an attacker the ability to compromise any sites using magic links as long as they get access to the e-mail.
2fa + password means they could compromise the e-mail and still not be able to reset a password without the TOTP.
Social Auth is even more secure than magic links because the larger companies like Facebook and Google have already implemented SECURE 2fa and they've also implemented IP / Computer tracking so that if abnormal authentication happens you have to go through better verification.
If a magic link gets opened from Argentina when the user traditionally logs in from North Dakota, are you blocking that until they go through more verification? If not its not more secure.
I'm comparing magic links alone to passwords plus an additional reset email. Magic links with no passwords will be more secure.
If you add 2fa to passwords and keep the email reset then magic links alone will still be more secure.
Password reset ~= Magic link. The risk profile of this is no different than a password reset with no fallbacks such as 2FA.
I had to google "~=" had no idea some languages use that for "not equals" instead of !=.
I've only found lua and MATLAB that use it but its interesting to understand. I was super confused on what you were trying to say.
I thought he meant "about equal" as I've always used tilde to me about/approximately.
Maybe he can clarify. I don't want to assume he meant "not equals" but thats what I found on google
I'm comparing passwords with an email reset vs magic links with no password in my comment.
Magic links will be more secure.
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:
1. wait for the email to arrive
2. click on the link
3. navigate back to my inbox
4. delete the email
5. navigate back to the app/website
(this is my inefficient way of doing it, I just don't like to have emails lying around that I don't need anymore)
> All this work just for the auth, which is not your core product and not what users come to you for.
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...
Those can be actually worse because you end up having to choose a different password every time, and you're probably not going to make it stronger every time you forget...
Use your browser’s password suggestion.
I haven’t picked a password in a couple of years.
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 still a password that can be leaked, the one for my mailbox. Great...
> and there is still a password that can be leaked, the one for my mailbox
It's forcing you to centralize your access to a single account, which sounds bad, but at the same time it's always been that way since most services provide a "forgot password" feature.
If someone gets into your email, your accounts are all fucked anyways.
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.
This isn't so much "getting rid of passwords" as it is "delegating the password to your email".
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.
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:
1. Enter email
2. If the hidden password field autocompletes, use it
3. If not, send a magic link email that doubles as “someone is trying login” notification AND show the password field
So at this point you covered:
- people with password managers
- people who remember passwords
- people who don’t remember passwords
Email links mean I can't login from someone else's pc because I don't have my email setup on it. I find that very bad UX
You don't need your email set up on someone else's PC in order to log into a service which uses passwordless login. You only need access to your email from some device - not necessarily the device which you want to log in with.
As I understood the service, it does not require that you click the link on the same machine that you login from. In fact, the screen shots sort of assume that you open the mail on your phone even if you login from your desktop.
In this day and age, you should not login to anything from someone else's PC.
In this day and age, you should not login to anything from someone else's PC.
There are a lot of occupations where you don't have your own computer, and share one with many other people.
For many jobs, the value is not in the person, but in the position, so the position has a single computer for a function that multiple people fill. Especially if you work for a company that operates 24/7.
For example, each person person operating a control computer at a recycling station does not have his own computer. There is a computer for each position, and who mans that position will change from day to day.
Freight dispatchers, retail sales, customer service, airline operations, and many broadcast positions are in the same boat.
Imagine how big an airline ticketing counter would have to be if "In this day and age, you should not login to anything from someone else's PC" was reality.
That's a silly interpretation of my point. Sure, log into work resources - including your work email - with your work computer. Email token auth works fine for your work context.
If you're mixing work resources and personal email (or vice-versa), you have a problem. You should never hand off control of your intimate personal life to the security (or lack thereof) of your employer. And vice versa; your employer should not trust putting their intellectual property on questionably secured personal computing devices.
In that scenario, do you have individual accounts on the computer or are you all using a single login and sharing it? The first scenario is fairly secure, the latter is a nightmare.
In that scenario, do you have individual accounts on the computer or are you all using a single login and sharing it?
I've never worked for an airline, so I can't say what happens in that specific scenario.
However, when I worked for a chemical company, printing out the hazardous materials labels for sample drums that were shipped all over the country, the computer had a single common login for all users.
I don't see how that is a nightmare.
I feel pretty safe logging into stuff from my wife's computer.
Then you should feel pretty safe logging into your email from your wife's computer.
Then forward the magic link email to your friends email address.
I delete cookies regularly and would find this incredibly annoying.
If you delete cookies regularly, I assume you are entering your password regularly? Do you use 2FA on these sites? I assume you have to go through the motions each time. What makes clicking on these links more annoying? Some 2FA (or confirm your identity) is done through email still.
I'd expect most 2fa to be through an authenticator app (google authenticator for example), SMS, or a physical device like yubikey.
I don't think I've seen anyone use e-mail for 2fa. All the devices I listed above are in real-time through TOTP timings. E-mail is NOT in real-time.
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. :(
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.
Could you explain why? Is it because a log-in request essentially looks exactly the same as a "forgot password" request and is likely to slip under the radar of someone monitoring for suspicious activity?
If you use N sites which all adopt this authentication mechanism (i.e. widespread adoption); and if I can access your e-mail, then I can access all of those N sites. Furthermore, yes, because all those accesses look normal, nobody would detect it as unauthorized.
Here is a related thread discussing this very topic: https://news.ycombinator.com/item?id=25628729
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 didnt want to implement full blown password login..."
Checking if a password matches seems a lot easier than 1)generate a code 2) send an email with the code 3) have an endpoint the verifies the code 4) find the websocket connection associated with the code 5) send a websocket frame with the access token for the use to authenticate future requests
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.
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.
For those used to the convenience of password managers, its an extra step that can add friction. Longer sessions help.
Email links are a great password system on a "mobile first web". Not so much when you are using a desktop..
Email links are a great password system on a "mobile first web". Not so much if you are using a desktop..
How so? I only have one service that I use which employs magic links, and I use it on a desktop with no problems.
I'm starting an internal project for my company which will utilize magic links. About 50% of the users are expected to be on desktop, and 50% on iPads, so I'd like to know what the problem is for desktop users before I go too far.
While on a mobile I have a gmail app (always logged in), on the desktop (browser) I don't store cookies so I'm rarely logged in. Typing a password with 2-step verification to follow a magic link is not optimal.
I think you're being downvoted because you deliberately choose to introduce a layer of complexity into your life, then complain when something is complex.
A layer of privacy shouldn't be downvoted or considered complexity. If someone chooses to not be tracked that is not something to look down on.
If you care about privacy, you'll pick flows that all your users to maintain their privacy.
If you care about privacy, you'll pick flows that all your users to maintain their privacy.
As stated, my project is an internal company project and will be entirely on company-owned hardware, so I don't care about my user's privacy in this case.
Why not for desktops? It should work in the same way.
Nothing is as passwordless as the existing social login Auth0.
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.
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 mandatory password.
>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 mandatory password.
Then you get locked out of like 9 things at once when {you ragequit github for political reasons and forget to migrate everything, google kills yet another thing, google locks your account for funsies, apple locks your account until your macbook pro refund is processed correctly,....}
Security requires good governance and trust - and ultimately realizing that everything connected online can and will likely be breached - and so if something is important enough, the design should be that it never touches the network. I personally don't fear any of my history or life coming out if it were - at least at this point, and in reality if security becomes a real concern due to well, tyranny and the universal battle against bad actors/evil, then my current location would be the only thing I'd ultimately not want known - and so you simply stay off grid then.
> Security requires good governance and trust
Neither of which the web currently has.
Arguably true.
I think magic links can be quite secure, and for spike.sh most users will have a company provided and company managed email account. There are also techniques to make magic links more secure, like pinning them to the browser/device that requested the log-in using a cookie.
I think passwordless-only is a bad call for the consumer market. Notion ran passwordless for years but we dealt with constant issues of users losing access to their email and having no (easy for them) way to prove ownership of the related Notion account. We switched to normal password accounts.
The premise is that what you “have” is unique (and thus secure) access to your email.
It bears the same risk of the unique access being lost as having unique access to your finger for finger print scanning, minus the risk of physical injury on compromise.
Magic links and federated emails have the same points of failure. If you got their email password you're in
And I don't like federated emails because I can't tell Google (I can tell FB, ironically) that I don't want all my data shared with the service I'm logging in with (some services like Samsung phone stuff wants to get everything)
So thanks but I'd rather only share an email/password in some cases
Personally I'd rather them support magic links than support only google login, only apple or facebook, only github, etc. Nobody supports all of them.