1. Include a fallback sign-in code in your magic link, in case the user needs to log in on a device where accessing their email isn’t practical.
2. Make sure the sign-in link can handle email clients that open links automatically to generate preview screenshots.
3. Ensure the sign-in link works with email clients that use an in-app browser instead of the user’s preferred browser. For example, an iOS user might prefer Firefox mobile, but their email client may force the link to open in an in-app browser based on Safari.
I think that a link to a page where you enter a one time code gets around a lot of these issues.
Sending a code goes around a lot of issues.
I've done both in my SaaS product - link is GET with the OTP in the link, the target page checks if the link is in the URL, and if not, then the user can type it in.
Only for signup, though. For sign-in, the default is to always have the user type it in.
Recently ran into this issue as new mail accounts got confirmed automatically and magic links were invalid when the user clicked them, because Microsoft already logged in with it during checking.
What an insane policy, why am I surprised Microsoft came up with it…
When McDonald's switched from email/password to magic links I had a hard time getting the magic link to work with the McD app. It usually would just open in the McD website.
Thus was quite annoying because about 98% of the time I eat McD's I would not do so if I could not order via the app [1].
I finally gave up and switched to using "Sign in With Apple" (SIWA). There was no way that I could find to add SIWN to an existing McD account, so had to use the SIWA that hides the real email from McD. That created a new McD account so I lost the reward points that were on the old account, but at least I could again use the McD app.
[1] They have a weekly "Free Medium Fries on Friday" deal in the app available for use on orders of at least $1. Almost every Friday for lunch I make a sandwich at home and then get cookies and the free fries to go with it from McD.
1) rooted or bootloader-unlocked Android devices are not allowed (granted it's easy enough to get past it for now but the checks are still there). 2) 2FA requirements as if anyone would bother to steal coupons from others
It appears that they want ordering burgers to have the same level of enhanced security as banking apps. Not even crypto or trading apps bother to block unlocked devices in such a way. Blocking rooted devices doesn't even make banking apps more secure but for them I can at least understand the reasoning.
so I got the magic link on their computer and then I made a qr code
but wait, the email quarantine system had altered the whole link so I had to extract that
but wait the redirect url back to slack was malformed because of the url encoding and i had to fix that and then make the qr code
like wow just give me a qr code or code instead in the original magic link email!
Having a code completely negates that advantage, as attackers can just set up a fake website that asks for the code.
Magic links should log you in on the device you click them, not on the device that requested the login session. Anything else, while being a little bit less annoying, is a security issue and should be treated as such.
I don't like that for a number of reasons.
If the user opens the magic link in the same browser that initiated the email, then just log them in. Otherwise, present them with the Apple-style "Do you want to authorize a login from 1.2.3.4 using Firefox on iOS possibly located in Portland, Maine? [Authorize] or [Reject]".
Hey, wasn’t Firefox on iOS based on Safari related tech anyways?
https://en.m.wikipedia.org/wiki/Firefox
> However, as with all other iOS web browsers, the iOS version uses the WebKit layout engine instead of Gecko due to platform requirements.
I do agree with what you’re saying though! Just those two in particular will probably have pretty good compatibility, which I was amused to find out when I looked into it.
Any suggestions on what needs to be handled here? My first thought is UA checking to see if it looks like a real browser.
https://www.rfc-editor.org/rfc/rfc7231#section-4.2.1
>The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.
Exactly the same for email unsubscribe links, or a one click "buy now" link.
Have your logging-in session wait for / poll "has visited magic link", and authenticate that session when it's done.
Tons of systems do this. It works great, and it can quite easily work without any web browser at all on the logging-in side because it just needs to curl something -> poll for completion and save the cookies -> curl against the API. A number of oauth flows for e.g. TVs work this way, for instance, because it's a heck of a lot easier than integrating a full browser in the [embedded thing]. Many app-based 2FA (e.g. Duo) works this way too.
This works on 99% of magic links I've tried except for cases when they are trying to prevent account sharing. I remember the Bird bike app did this, where they required the magic link to be clicked on the same device login was initiated on. I was using my friends account and he would just forward me the link until one day this stopped working.
I assume it generates a session on the post-login screen and authorize that session upon accessing link
1. Some users (0.1%) just don't ever get the email. We tried sending from our IP, sending from MailGun, sending from PostMark, having a multi-tier retry from different transactional tools. Still, some people just will not ever be able to log in.
2. People click old Magic Links and get frustrated when a 6-month old link "doesn't work". We've decided to remedy that by showing them a page that re-sends the link and explains the situation (like Docusign does) instead of an error message.
3. People will routinely mis-spell their email and then blame the system when they don't get the code.
All of this still results, I feel, in way fewer support tickets than the email+password paradigm, so I'm still in favor of Magic links.
I never tried to add magix links, but I added Google Sign in to my SaaS several month ago, and since then, it accounts for more than 90% of new sign-ups (users are devs, so rather tech savvy and privacy aware). I'm now convinced that no other method is a priority (I still have email/password of course).
I do it for services I don't care about. In my mind it is more privacy for me. Keeps you out of my real inbox and my password out of your system and I believe that I can - to some extend - remove myself without having to go through whatever crap account deletion process that services has tried to cobble together.
Worst offenders let me login with google and then immediately asks for name and phone number or email and asks me to verify it.
In general, I do understand that use of SSO is due to convenience. Especially since in many cases websites provide less friction when signing up via SSO instead of using username+password.
I am shocked, shocked, by the number of different K. Strauser people who have typed that email address into some random website or another. I've gotten bank notifications, loan documents, Facebook signup info, meeting minutes from some random volunteer work, and all kinds of other things. When I can figure out from context who the intended recipient is, I try to let them know so they can fix it. On one occasion, the person sent me back a swear-laden diatribe for "hacking their email". Sigh.
I think this has made me a better engineer, though. When someone says something in a meeting like "...as long as they type their email correctly", I can jump in and address that myth head-on. No, people will not type it correctly. If it's a minor pain in the neck for me, with an uncommon name, I can only imagine the traffic that the world's John Smith's get.
Username+password (or passkeys) with a password manager (which ensures that credentials are used on the correct domain) via HTTPS is probably the only end-to-end encrypted way of exchanging credentials with good UX for general public.
90% of web apps don't handle that kind of information, and for them a magic link is at least as good as passwords (as this article explains). Those that do handle things like personally identifiable information (beyond an email address) really should be enforcing 2FA or proper electronic IDs.
There is a whole profession writing recommendations about information security, and every web developer needs to be able to do this kind of analysis at a rudimentary level. We don't need to wing it, we can analyze security requirements in a systematic way.
It's not like the rest of the customer's data is not valuable? If you don't feel comfortable storing passwords, the amount of data I'd trust you with is strictly zero.
Planning for a breach doesn't make you more likely to have one—if anything it makes you less likely!
I could understand requiring a third factor to authenticate if signing in from a different location or a different ISP than I've been using for the past 5 years, but it's ridiculous to do so if nothing has changed (except the final octet of my DHCP-assigned address) since I last signed in yesterday. I use a different computer (via SSH) to read my email than I do for web browsing, and cutting-and-pasting a signin link that's hundreds of characters long (spanning multiple lines in Emacs, so I have to manually remove \ where it crosses line boundaries) is a PITA.
Adding friction on every sign-in colors all subsequent interactions I have with an app, and makes me hate using it.
You shouldn’t get the device verification requirement if you’ve used the device before (we store a permanent cookie to check this) or for the same IP. Any chance your cookies are being cleared regularly?
We added this after attackers created clones of http://mercury.com and took out Google ads for it. When customers entered their password and TOTP on the phishing site, the phisher would use their credentials to login and create virtual cards and buy crypto/gold/etc. The phisher would also redirect the user to the real Mercury and hope they figured it was a blip.
This device verification link we send authorizes the IP/device you open it on, which has almost entirely defeated the phishers.
Since WebAuthn is immune to this style of phishing attack, we don’t require device verification if you use it. I highly recommend using TouchID/FaceID or your device’s flavor of WebAuthn if you can—it’s more convenient and more secure. You can add it here: https://app.mercury.com/settings/security
That said, we are talking internally about your post and we do recognize that as IPv6 gets more traction IPs will rotate much more regularly, so we’ll think if we should loosen restrictions on being a same-IP match.
I wasn't aware that WebAuthn didn't have this requirement. I prefer TOTP because I actually like having a second factor in addition to a credential stored on my computer's hard drive (whether a password or a private key in my password manager), but I might be willing to reduce my security posture to get rid of this annoyance.
One suggestion: the link would be half as annoying if it was easily cut-and-pasteable rather than a long email-open-tracking link spanning multiple lines. This is what it looks like when I copy it out of my email:
https://email.mg.mercury.com/c/eJxMzs1u4jAUBeCncXZB9vVfvPACZshoWIwYoiasdgkra2KV_JCGqPTpK-imq7xxx40vlO9IKia6ggL6zUlQHObdF6\
JI0alRHBWQvWKRuD4loLZxsJSRXZAwfNBQeQWozasdgeWsMyFZozE4RKZ4d151NOFtuq9w6IqLb-d5fGdyzaBmUIdx_NkzqBeacrqXkZaMxGSNQyQmf7_9GW7\
Hf1cJ8zW9TshAwwba3ccLuN3u_r_PR9j_GkxxxmadDu32c59jMfkYFmKKP0baIT0vzP4ynHN_-yyhZOTy9jmPPQn6gL-VLMfvvIA_XxbywRYhUbZUp0RpVCUC\
qDsbasJHeObFMZ4YrFw1cAAAD__4XPZXw
Edit to add: looks like email.mg.mercury.com is hosted by Mailgun. Are you intentionally sharing these authentication tokens with a third party by serving them through this redirect? Do your security auditors know about this?
unfortunately, only few ISPs do IPv6 correctly by assigning a fixed prefix to customers. most of the ISPs apply the ipv4 logic when adding ipv6 planning hence this situation.
hopefully this will improve in the future and more stable prefixes will be given to users.
security = 1/convenience
but also vice versa
Ricky Mondello wrote a really great blog last week[1] about how passkeys, as OP alludes to at the end, can be used alongside Magic Links, that I think is worth a read.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
The fact is that even in the best of times, e-mail isn't reliable. Things go to your junk folder. Links get blocked by work spam filters. Mailboxes get full (I assume? it's been a while).
Personally, I have my e-mail on my iPhone and anywhere else (work laptop or gaming PC) I have to log into icloud.com to check my e-mail; it's cumbersome. Let me put in a password. Let me scan a QR code like embedded devices do. Give me at least one other option.
I'm still used to Apple people being almost completely invisible publicly.
Every implementation of passkeys I've seen has presented me with the option to create a passkey after I've already logged in with some other method. I'll admit that I haven't dug into it deeply, but the UX I've been presented with consistently makes passkeys appear to be an alternative to the "Remember this computer" button, not to passwords in general. Somehow the service has to know that this new device is authorized. I know depending on the provider there's such a thing as passkey syncing, but that doesn't solve the problem of getting the initial authentication done.
The key insight with magic links is that your security system is no stronger than its recovery mechanism. We are never going to get to a world where passkeys are treated as the only authentication mechanism—there will always be a recovery mechanism, and in most cases an automated one via email. Given that that is the case, magic links simplify things by just not pretending that we have a more secure layer on top. By making the recovery mechanism the primary means by which you interact with the authentication flow you're being more honest about the actual security of your auth system.
Edit: filmgirlcw has a link to an article that is much better than this one that explains how the two actually complement each other: https://news.ycombinator.com/item?id=42628226
There are definite UX problems around passkeys that could be improved and I think exporting will make syncing across systems a lot better (one of the reasons I use 1Password as my primary password and passkey system is so I can use my passkeys across devices; of course it helps that my employer uses 1Password as our system so I am logged into my personal and enterprise accounts and can auth then from personal or work devices, provided additional auth or enrollment isn't needed) -- but if the problem as 404 defines it is that they don't want to be responsible or even have to worry about storing your passwords/auth controls, I think passkeys is at least better for a subset of users than Magic Links.
But again, like Ricky, I don't think it should be viewed as either or. It should be both.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
> though I don't know if making your email an even stronger attack vector is necessarily one of them
I'm unconvinced that magic links do make your email an even stronger attack vector. Essentially every service that would be inclined to use magic links would already have a way to reset your password entirely once the email is compromised. All magic links do is make this the primary way to interact with the auth flow.
The bad guys already know that your email is the best target. Magic links just make that very explicit.
Like what? I'm failing to come up with a single benefit (for the user).
Give it a few more years and I suspect we will start to see services start with creating a passkey and never collecting a password. The passkey portability specs will be implemented, and hopefully Gnome/KDE implement passkey support.
sigh TBH, I hope not. Maybe optionally, but for now the friction might keep companies from going passkey only, which (I think) would be a total nightmare from a security and usability perspective.
Passkeys support authentication via a secondary device over Bluetooth (and this is supported in every major browser on every major platform). So you can login to a site on a machine that’s completely disconnected from your personal passkey store by scanning a QR code with your personal phone.
The login flow basically goes “request login with passkey” -> “browser recognises it doesn’t have the needed passkey, and offers a QR code to scan” -> “scan QR code with phone” -> “phone and browser handshake via Bluetooth” -> “passkey handshake happens between website and phone” -> “login completes”.
I’ve personally used this flow with my work laptop and my personal iPhone many times. iOS has built in support for the Passkey QR codes, so you can scan the code with the standard camera app. Additionally iOS supports allowing 3rd party passwords managers to take over the Passkey flow once you’ve scanned the QR code. So in my case I complete the flow with 1Password.
End-to-end the flow is pretty damn seamless, I’ve never personally had it fail, and take 30seconds to complete. The most annoying part is trying to remember where my phone is.
Anthropic has been the once exception to this personal policy simply because Claude is the best LLM out there. But it's a mountain of pain every time I have to re-login, and I've complained to them multiple times about this.
Is it though? Majority (if not all) services I frequently use have email as recovery option for forgotten passwords.
In any case the correct approach here is to fix password reset/account recovery (e.g. with social key recovery) rather than reduce everything to the lowest common denominator.
It also can be said to lower security because it instills the behavior of clicking on links in incoming emails as a standard practice.
When links in email come into mind, so does phishing.
I hate these magic links a lot.
The point is not to click suspicious links. If you know a magic link was sent, it's not suspicious.
That being said, I hate them just for the delay.
™Kelly Shortridge 2021 (https://x.com/swagitda_/status/1503751776134180873)
Otherwise it's been a while I haven't seen an reset link instead of a reset code. Copy/pasting is not much of a hassle, and it works even if the mail is checked on a different device.
The only real link I had to deal with were app callbacks that were explicitly labeled as such (with instructions from the app to explain what to expect)
Click that stupid magic link for a service we use, and they’re asked for their Office 365 credentials… all the while I’m telling them not to click links in emails.
apple's email privacy scheme seems interesting (apple always loads all images), but I don't know if there are drawbacks.
Sites that send an OTP (crazy-pink-horse-3837) that you can copy, and paste is a good middle ground if implementing the link that just Auths the original request is too difficult.
Most sites will have a confirmation once you click the link that includes the browser version and IP address. I have seen that info only in the email itself too with no confirmation afterwords, but not for some time. Have never seen one that is just a link with nothing else that once clicked allows the other device in but supposes could be implemented that way.
The article itself is about not making them the only option (which is fair), and the OP says if they do it should login the device which originally made the request (which I agree). If the implementation is just an email with only a link, no other information with no confirmation (yes, it's fine to let this device in), then I would have to agree with you it's very risky and could allow anyone to login as you (hopefully no sites are doing this, but...)
That would let you authenticate your desktop browser from an email you opened on your phone if you're on your home network, but without becoming widely exploitable by phishers.
The phishing risks for a bank account login are very different than those for a ‘returning player’ login to a casual gaming site for example.
The victim got a phone call in which the she got manipulated into authorising something in the BankID smartphone app. But what she was actually doing was authorising the attacker to log into her online bank account.
First after several years (of blaming the thousands of victims for their millions lost) did the system start using QR codes on the screen scanned by the smartphone.
Remember that the flow the magic link is part of is one you initiate, that causes you to get an email you are expecting.
That email, and the landing and confirmation page it links you to, can explain very clearly that you are only supposed to authorize this if you are trying to log in on known device in known location that is displaying recognizable number on the screen right now.
edit: saw that nicce basically said that a second before I hit post.
OTP is far better than an actual magic link - you can still include a link that pre-fills the code.
You click the button on the page which knows the session you're logging in from and link code and does a POST which completes the login. This is how all the "login by scanning QR code" flows work.
To be fair, in-app browsers should die, especially those without an "open in regular browser" opt-out – which RSS readers should readily offer anyway.
Throw every product manager responsible for forcing in-app browsers upon their users in jail.
[1] https://en.wikipedia.org/wiki/RSS
[2] https://en.wikipedia.org/wiki/Comparison_of_feed_aggregators
This gets the best of both worlds: the security of passkeys on existing devices, and the passwordless setup and account recovery for new devices.
Bonus: it even avoids vendor lock-in where cloud providers have all your passkeys.
Also, when logging in from a new device, many accounts which use password-based auth today send a confirmation email and ask users to either enter the emailed code or click on the link. This is part of their existing security protocol. So we are not introducing a new unique thing here.
They can present it as a "more secure" login method, obscuring the reason they actually like it.
You still need another method for the first login.
Discord implements this feature, and this phishing scheme is extremely common: bots/scammers will message you saying "to access <some desirable content>, please scan this QR code" -- and if you scan the code, the scammers have just taken over your account. It's not much harder than rickrolling someone unless they're savvy enough to be aware of the scam.
Of course this can be mitigated somewhat by putting a big scary confirmation screen that says "don't click continue unless you're trying to log into your account from another device", but 1) users don't read, they just click "continue"; and 2) the attacker controls the narrative before the user clicks the QR code; they can craft the language to make the scary warning screen make sense to the user ("yes, I am trying to log into this discord server that this person sent me an QR code to").
In this case, what alternative is there than having a magic link in the footer of that email that says "unsubscribe" that includes a token unique to that email address that acts as proof of owning an email account when you then click that link and ask to unsubscribe?
But using them as the only option to login is really, really annoying. Mails can get trapped in spam filters, delayed by intermediate server overload or spam filters that sometimes take 10 minutes, servers doing graylisting... Plus all the other annoyances listed in the article (e.g. multi-device users, in-app browsers). At the very least, support passkeys if you really don't want to store (hashed) passwords. And no, SMS is not an alternative: I was several times barred from logging in to a service because SMS wasn't properly working (can happen easily while roaming abroad).
I seriously HATE magic links. My email inbox is barely better a social network's time suck. Lots of urgent, little important, wrecks any flow I had.
Forcing me into my inbox is highly likely to cause me to forget about the reason I was there (to get into your app). Or, at best, it slows me way down and nearly always breaks my flow.
Perhaps this is acceptable for the security boost (?) for the average user, but man, when I get forced into magic links I sometimes just abandon the app altogether.
Disclaimer: 1. I have/pay for a password manager, which helps with the forgotten password problem a lot. It also allows me to have extremely hard-to-crack passwords.
I'd even say magic link emails border on misuse of email; they're a fundamentally different form of communication from all other uses of email. It's not easy on neurodivergent brains to deal with that combination of pollution (magic links in my inbox) and distraction (actual emails in my face when I'm trying to log in and was not trying to check my email). Protonmail's client could really make my day if they found a way to reliably separate those 2 channels so I didn't have to even open my inbox to get login codes/links.
What I don't understand is why I've never been prompted to use a password manager by any site with a signup flow. It seems easier to normalize their use through messaging than keep acting like passwords are supposed to be something you consciously remember. Nobody should remember their passwords, except for maybe 2-3. But now we're moving toward a world where login just means more friction and less control instead...
I wish magic links would go away, but if they need to stay, that approach was the least terrible.
Almost everyone outside of some HN users use email regularly. They have it open on a second monitor and it is an important part of their workflow.
If their companies are not super tech savvy and not using SSO, the users probably at least have a company email address they’re logged into.
I don’t think it’s worth over optimizing for a small percentage of users. Worst case scenario you need to contact support.
99% of enterprise users will be fine with magic links, compared to dealing with people who use horribly weak passwords. Most of them seem to prefer them to passwords.
SSO is always best option if available but magic links are definitely second.
I've received magic links to my Gmail account that belong to other people, for accounts that have ordered flight tickets, or clothing, or digital services.
Those people, I guess they now have no way to access their online account, as they cannot password reset (if that was the fallback), or change their email (usually requiring confirmation), or receive their magic link.
There's nothing I can do here, except to delete the email, I don't have any indication as to what the correct email should be, and the person's name is the same as my legal name and there are a lot of people with that name in the World.
Few services verify an email during sign-up, because I'm sure data shows that added friction during sign-up results in fewer people signing up.
I have my own domains for email so I haven't had the issue of someone else entering my email but I keep hearing from friends getting that.
Frankly, if somebody else uses my address for a service and I'm receiving anything other than email verification from that service, I'm reporting it as spam on both Gmail and Fastmail because that's what it is.
Magic links and OTPs have become common for many other sites I use -- Udemy, Teachable etc. come to mind.
Recently I bought a cheap "smart watch" for my kid. Mostly for the digital display with configurable clock faces and simple step counting. The app would refuse to activate the watch unless we provide a valid mobile number and OTP. Why the hell do I need to give them a working mobile number just to use a smartwatch. Even if I wanted (which I did not) to get notifications / calls / texts / caller ID / contacts from my paired smartphone ... the smartwatch app does not need to know my phone number for that functionality to work. Feel so powerless.
I'm building something for a very tech illiterate audience, and everybody loves the simplicity of it.
I'm quite fast at passwords and 2fa. The whole thing is second nature, I have a password scheme to deduce the password for any site but keep them long and high entropy, and I can do 2fa calculations from any trusted device without taking my hands off the keyboard (thanks to oathtool), and anyway my passwords are sync'd securely and I can look them up with hands on keyboard.
This is strictly better than "single point of email failure". Why force me to be less secure and less usable.
Please, just allow me to use passwords and regular old TOTP.
Obviously, your mileage may vary but it was a good reminder to always validate your assumptions, especially in your critical user flows.
How are you tracking login success rates?
I creates a bar management/sales platform for our group of friends. It's self service so people purchase their products on their phone and pay later.
People get... intoxicated... after which passwords appear to become quite the problem. Magic links solved that.
To solve the multi device and in-app browser problem people can also open the links on another device. That'll show a short code they can enter on the original device to actually log in. It's not perfect, but it works.
I do fully agree that passwords should always be an option as well.
With Stratechery, once you get to the website with the magic link, I can then copy the authenticated podcast RSS feed to Overcast and the authenticated RSS feed for the articles to NetNewsWire.
Those subscriptions are then synced to Overcast and NNW on my iPad and Mac via iCloud.
Each podcast RSS link is personalized and you go to the show notes page and click on the link to Manage your account. It will take you to the website using the embedded browser where you can manage your subscription and get access to the various feeds.
Speaking of Overcast, even though its doesn’t create a username and password by default, you can create one. But it’s only to access the web version of Overcast.
1. enter username
2. choose password or magic link (select password)
3. enter password properly
4. Thank you for logging in. Please click your magic link to log in.
Why did you waste my time putting in a password when the magic link was the only option?
Our response to above: https://wideangle.co/blog/passwordless-authentication-magic-...
Conclusions:
Magic Links good? Yes.
Magic Links the best? No.
We dumped them for a host of reasons, but included in there was their use of tragic link logins.
Absolute clowns. Glad to see this practice getting the negative attention it deserves.
Since the application only sends a weekly email (a markdown template for goal/task tracking) it seemed easier to just use a magic link, only.
I am happy at how much easier the auth code ended up, and fail to see much downside for such an application.
I'm not sure it would be a good system for more complex apps and services.
I had this case recently: Sending a job application, so wanting to check what my LinkedIn actually says (I don't use or even update LinkedIn regularly). Now LinkedIn thinks my login looks suspicious and sends a confirmation email. (It does that nearly every time the rare cases I log in, probably because I delete cookies.) But the mail doesn't arrive. My email provider is usually very reliable, but later I learned that just in this moment they experienced multi-hour delays. While this was not a magic link it shows that any login requiring a quick email delivery can fail in the worst moment.
On the other hand, training users to expect and use hard-to-read login-links in emails is not really good either. It promotes a broad range of scams, phishing, and potential malicious code exploits, even if the a particular sender's site has been hardened somehow. (e.g. a TOTP app on a phone.)
The "email is authentication" pattern
https://news.ycombinator.com/item?id=41475218
Unfortunately blocked on my (work) network -- classified as miscellaneous / unknown category.
If you check the early comments on the thread I posted the full content for someone else who could not reach .zip domains.
Agreed with some other folks that Passkeys is not a replacement for email verification.
Would it be possible to bookmark the login link so that in the future I don't first have to go to my email in order to log into the service?
Auth is the worst part of building a service and sucks all the fun out of it. API auth is a mess because people can’t keep a token string secret. Now we need JWTs, OAuth, token refreshing, and a whole bunch of BS that no one enjoys.
One reason why OpenAI and Anthropic APIs are so much more fun to use than Google and AWS offerings is that you get a token and are responsible for keeping it safe. It makes the entire workflow dead simple. I’m not creating a new project or fiddling with IAM just to try out an endpoint.
The most-devices people I know are those who have a laptop, phone and tablet. That's it, I literally cannot think of anyone I know with more then this, and most of those with tablets are using it for games or reading or for the kids.
Magic links are indeed the best solution for the average user. Type in your email with autocomplete, get a notification from the mailbox, click, click, and you're in.
My autocomplete can fill a password or passkey in too. Don’t waste my time.
There's even cooler ways that are already working including nsec bunkers.
This is the way of the future IMHO, most people just don't know it yet.
If you want strong security, offer passkey login. It's safer than email and much more user friendly especially with FaceID/TouchID on Apple devices.
Even something small thing like email -> hit enter -> then we show password input, will cause me to stop using your service.
Don't send me a link, tell me where to find it, after I log in.
What? You have your email on literally every device -- be honest.
I think it's interesting that the author has chosen to not have email on PCs, but I can see why. I also completely get why they'd opt to not have private email on a work laptop.
In the US, because the Fifth Amendment Self-Incrimination Clause, passwords cannot be demanded. Passwords are testimonial evidence. [United States v. Hubbell (2000); re Grand Jury Subpoena Duces Tecum (11th Cir. 2012)]
Biometrics on the other hand are not. The court ruled that a defendant could be compelled to unlock a phone with biometrics because it is not testimonial. [Commonwealth v. Baust (Virginia, 2014); State v. Diamond (Minnesota, 2017)]
Basically, passwords cannot be compelled to be disclosed, while biometrics can.
There is similar legal stance in Canada, UK, Australia, India, Germany, and Brazil to name a few.
Finally, under duress, passwords can be held, while biometrics cannot, without self harm.
There is not a similar stance in the UK. You can be compelled to provide a password. Section 49 of the Regulation of Investigatory Powers Act 200 (RIPA and let that doublespeak sink in a second) allows the police to compel it subject to a warrant from a judge.
The sentence (subject to sentencing guidelines) is up to two years in prison or 5 years for national security / child indecency cases.
You can claim you don't remember/know it as a defence, but in most cases that's not going to be believed by a jury.
In theory once you got out you could be re-served with the notice and face another 2-5 years. Rinse and repeat.
But none of this has much to do with the biometric auth you do with passkeys, because passkeys are used in places passwords would be used — logging into apps and websites. Which you see only doing when your device is already unlocked and you are actively using it.
In the UK the Regulation of Investigatory Powers Act (RIPA) makes it a criminal offence to not divulge a password if compelled via a RIPA notice.
Seeing passkeys as a dedicated login on their own is...strange. For all of the reasons that you indicate.
The term "Magic Links" once meant a [futuristic PDA](https://en.wikipedia.org/wiki/Magic_Link). Nowdays, companies like [Auth0](https://auth0.com/docs/authenticate/passwordless/authenticat...) use it to refer to the slightly-magical feat of including a login link in an email.
Last week, the great website you should subscribe to if you haven't already (it's great, when you're not logged out), [404 Media](https://www.404media.co/), posted ["We Don't Want Your Password"](https://www.404media.co/we-dont-want-your-password-3/) in defense of so-called magic links.
Of course, as stated in the article, such email links are harder to phish than passwords, can't lead to a breach of passwords, and protect the site itself against users who might reuse passwords previously compromised.
The article even covers some of my annoyances with this system, but throws out this sentence:
> [We find this to be a much easier login process and wish it was more common across the web where appropriate.](https://www.404media.co/we-dont-want-your-password-3/)
Easier than what? Easier than a long password, without a password manager? Easier than a passkey? Easier than an OTP sent to the same email address?
This sentence reads to me as one written by someone mostly working and _living_ from a single laptop and mobile device. The second part of the sentence, calling for more sites to do this is why I am writing this.
For any scenario with a minimal amount of complexity, like users with multiple computers, and you're looking at a scenario where the site's unwillingness to deal with other login methods shoves friction on the end-user.
### What makes them tragic:
1. Multiple devices. Who doesn't use at least a few computers weekly? I don't have my email on my gaming PC, nor do I have it on my work laptops. 1. Slower. From 2 seconds slower to minutes slower, depending on SMTP delays as well as how awkward it is to get the link to the right browser. 1. Anti-mobile. As mentioned by 404 in their own article, this breaks the ability to use in-app browsers, which is quite annoying especially for RSS reader type apps. It makes interacting with any local link in the RSS feed extremely annoying. 1. Indirect security downsides. Pushing people to access personal email on work devices (or vice-versa) isn't exactly a win for security.
Another annoying _passwordless_ system is to email or SMS an OTP the end user can type in.
While this sucks, it at least allows you to easily log in in situations where you don't have a clear and easy copy/paste path from the email client to the browser you want to log in to.
[Stratechery](https://stratechery.com/), powered by [Passport](https://passport.online), uses this type of scheme (click link OR type in OTP), which is still shifting annoyances onto end-users to free developers from implementing passkeys, but at least has a bit more of an appreciation for end-users.
If you insist on using magic/tragic links by default, at least consider offering a robust alternative, such as [passkeys](https://fidoalliance.org/passkeys/), especially if your audience is technical and privacy-focused.
> 1. Multiple devices. Who doesn’t use at least a few computers weekly? I don’t have my email on my gaming PC, nor do I have it on my work laptops.
"Who doesn’t use at least a few computers weekly?"
I don't. And many, many other people.
See what I did there? I assumed that everyone's like me, just like you did in your blog post. Without data, both of us are wrong.
----
I'd add that magic links also act as a distraction: you open your email client, and it by default opens your inbox, and you start going through all of those unread emails that you just found in your inbox...
Shopify is a big proponent for magic links because they went all-in on their new "Shop" customer accounts. What a disaster. Branding something with such a generic word as "shop" is terrible and average customer doesn't understand that it's supposed to be a brand name.
When you consider that a smartphone is "another" computer (or for many users, the computer that is not the smartphone is the "other" computer), I imagine that number goes way up. Someone using a computer at work and a personal phone, for example.