not wanting to use google (or any third party) is a reasonable reason for me
Sometimes the link goes to spam, sometimes you have to search for it like a needle in a haystack of other notifications.
Sometimes you are not logged into your email on that device, or it's a small screen that makes it a pain.
Maybe it's my mother, and she now has to go find where she wrote down her email password because she still can't figure out that 1Password thing I setup for her. Also, she does not have 1Password on this computer (maybe it's a public library).
All this pain because a developer did not want to bother with authentication.
Many, many products are like this nowadays, but the worst offenders are developer tools and OSS projects, and looks like the justification is just that, they just wanted to scratch their itch of a specific feature, why bother with auth when there is google.
Am I crazy?
This is exactly the reason people use magic links - passwords are painful.
I generally don't mind having one or the other, so either password or magic link. What I can't stand is having both in the same login flow:
- Enter your email
- Get sent a magic link
- Open magic link
- Continue and enter your password
- Enter your 2FA as well
- Smash computer
The problems with passwords you mention, are valid. But, the same situation will happen for authentication - your mom can't remember her email account's pwd, but then you want her to remember facebook, google and all the other services' pwds?? Just think about where is the difference of "remember email pwd" and "remember 1Password pwd" ?? absolutely no difference.
So, while I understand your points, I'm thinking, magic links are the easiest and failure proof and user friendly way, to verify the user.
Another point is: Onboarding is very fast. The new user doesn't even need to bother with input of pwds, verfication, etc ...
for me:
please no account creation in the old style. Give me magic links. Implement a 2nd factor to check, if necessary - but just let them passwords dieeeeee
As with all things, you need to know your audience. If you are making a product for people over 60, probably a simple username/password would work best.
So I avoid any service where this is an option.
Does not get prefetched, does not require a click (if at the library, you can check your email on mobile and simply type the number), no need to remember anything, does not get marked as a malicious link by anti-fraud software.
It's really easy for us nerds to write off how confusing, cumbersome, and frustrating passwords are for most people.
My experience is, passwords are a 1 second affair: open website, tap credential highlighted by password manager, trigger face/touch id or whatever exists on android/windows, done.
Email experience: open website, click login, get some link, go to another app, wait for it to pull emails, look for email, open email, click link, opens in browser, maybe not the same browser where you opened the app, so go back and copy link, realize copying links from email buttons is not easy on mobile, finally login.
If this is where you guys want this to go, it sucks. How can we improve it? Maybe we need to implement some wait to do what apple does when you get a 2FA code via sms? It just shows it to you in app instead of having you open messages app?
- People tend to use bad passwords
- People tend to forget passwords (you need to write whole password recovery, etc)
- You always have your smartphone with email close to you
- It's way easier than 2FA with Authenticator and cheaper than SMS
- You limit password sharing for your service
It forces you to look at all your unread emails - and you invariably get distracted by some OTHER email that seems important, when you were trying to log into a website to achieve some totally different important thing.
But it isn’t better for the user of the service.
1. Stop labelling it with a confession.
2. Stop forcing the user to reset their password when they demonstrably don't have their password manager ready to store it. [Whether that be 1Password, or just autofill in google chrome]
As the only auth method, it isn’t great. As an option? I wish it were universal. Anything other than those or passkeys creates more issues in your mum's case. And passkeys are new.
(That said – If we’re distinguishing between magic links and email OTPs, there’s really no good reason not to have both in the same email, and the latter is better for the public library use case.)
Sites, do yourself a favor and store active sessions indefinitely and the only password-dealing scenario you'll ever see will be (1) at sign up, once per user, (2) when users clear cookies, which the login-problematic types rarely do for obvious reasons.
95% of my family password support is the sites that log them out on their own.
Edit: grammar/pronouns
If you control the email address signed up with, you have "god" access to the account (can perform password resets, etc). They essentially outsourced security to your email provider.
But some of us would prefer to keep more separation between their email accounts and other services. Eg. If my email's hacked, I don't want that to pwn my other stuff.
2FA helps but often there are ways around it if you control the email account.
Low security should use passwords. None of that fancy &@73gdb-Whb stuff. Just a regular word. Suitable for Netflix and meditation apps that want a basic login to prove that you paid.
Medium security should use magic links and a simple password that you don't need to write. If you lose your email, the password prevents hackers from taking over your app. If you lose your password, hackers can't take over your device. Suited for something like social media or MMOs, which are targeted very often.
High security might need proper 2FA with auth app, password rotation, stuff like that. Probably shouldn't be necessary unless there's constant active attempts to hack. Everyone gets attacked, especially in the era of AI, but I'm saying at least 10 attacks a day.
You can also layer on extra levels of security, but IMO that's about the level you should expect from users.
I've also seen it confuse users who aren't used to it.
It's great from a tech/security perspective but I wouldn't put it into my own product for those reasons. I definitely would not make it the only login mechanism.
We're just moving the problem
Or when the email service is overloaded and the magic link takes more than 30 minutes to arrive and by the time you open it, it has expired?
You and I use a password manager.
Many don’t. They reuse the same password or create a password and forget it. Both are worse scenarios than a magic link or a one time code.
X.509 client certificates would be better (especially since the connection already uses TLS, and yet they do not take full advantage of it and instead require TLS for things that do not need it). It doesn't require email, doesn't require cookies, doesn't require JavaScripts, doesn't require a web browser, doesn't require Unicode (although it can be used if wanted and commonly is), protects against MITM, allows single-sign-on (even without an authentication server, or if the server is down), and the private key can be passworded (without the server needing to know your password; this is handled entirely on the client side). Furthermore, you can store whatever data you want to in the certificate.
Tbh I don’t feel like most providers (including Keycloak) are offering strong, turn-key solutions for this.
The closest I saw to streamlined passkey support that you can host yourself is from Hanko.io - that provider didn’t work for my use case but something to consider.