[HN Gopher] Magic/tragic email links: don't make them the only o...
___________________________________________________________________
Magic/tragic email links: don't make them the only option
Author : gepeto42
Score : 156 points
Date : 2025-01-07 21:06 UTC (1 hours ago)
(HTM) web link (recyclebin.zip)
(TXT) w3m dump (recyclebin.zip)
| billy99k wrote:
| I've never liked magic links. I've found multiple sites that will
| just clobber the existing login session when you access the magic
| link, meaning someone could trick you into logging into another
| account.
| Pxtl wrote:
| I like magic links (as long as they self-renew the cookie so I
| never have to log in again) but you do highlight the critical
| need for a good landing page if you use them, like "are you
| sure you want to log in as SomeUserNameGuy? You're currently
| logged in as SomeOtherUserNameGuy."
| imzadi wrote:
| Firewall blocks that link
| ceejayoz wrote:
| Probably the entire .zip TLD.
| gepeto42 wrote:
| Yeah. To be honest, I kind of setup this blog as a joke when
| the dot zip gTLD came up, as an inside joke with a few fellow
| security people who (rightfully) are against the ever
| expanding list of TLDs we have to deal with.
| Mystery-Machine wrote:
| What's wrong with ever expanding list of TLDs? Is there a
| security threat or you just don't like it or?
| gepeto42 wrote:
| Some of them make it way easier for threat actors to
| obtain large amounts of domains for cheap or free,
| without fear they'll disappear right away.
|
| Paul Vixie had a great talk and research about this
| ~2018: https://www.youtube.com/watch?v=nkoNjntc5Lw
| gepeto42 wrote:
| Because I'm an idiot who likes hosting stuff on bad gTLDs,
| here's the markdown content of the actual post for you and
| everyone behind some corporate firewall that blocks dot zip:
|
| 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/pass
| wordless/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.
| dbliss wrote:
| You are a national treasure.
| Jerrrry wrote:
| URL encoding solves part of this.
| >Example.com/Verify/5W9GF
|
| If it fails, prompt for OTP on the fallback /Verify/ or
| /code/ page.
|
| Local convenience cookie for authenticating device and permi-
| cookie for requesting device.
|
| Permanent cookies should be accompanied with a 4 digit
| numeric PIN between any critical functions unless the session
| is new.
| jameshart wrote:
| Best implementation I see of this requires you to click the link
| on whatever device you receive the email on, but it doesn't
| transfer the session there - it just triggers completion of the
| login process on whatever device you initiated the process on.
| megous wrote:
| A phisher's dream.
| gepeto42 wrote:
| Yeah exactly. Plus, sometimes SOMETHING will click the link
| before it even gets to the person's inbox (some enterprise
| spam filter with a sandboxed browser for example).
|
| edit: saw that nicce basically said that a second before I
| hit post.
| nicce wrote:
| All the email scanners likely trigger the process anyway.
| jameshart wrote:
| Solvable with the right information in the authorizing email.
|
| 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.
| Mystery-Machine wrote:
| You're assuming users read.
| avidiax wrote:
| Rather than a recognizable number, users should be prompted
| to select a matching non-pronounceable glyph. Something
| like the keypads from KTANE [1].
|
| That makes it impossible to text or speak it to a phisher.
|
| Bonus points if you show the symbol as a noisy animated
| glyph, something like [2], or a link to a DRM'd video
| showing a symbol. That would make it very difficult to view
| even with screen recording or remote desktop software.
|
| [1] https://www.bombmanual.com/web/index.html#:~:text=On%20
| the%2...
|
| [2] https://www.youtube.com/watch?v=RNhiT-SmR1Q
| Jerrrry wrote:
| The thought of using unpronounceable text to deter
| phishing attempts reminds me of putting illegible Unicode
| as challenge question answers to prevent the CSR from
| giving an account away to convincing social engineers.
| layer8 wrote:
| There is a substantial class of users this would be too
| much to ask of, i.e. they wouldn't understand it or would
| assume that they are being scammed somehow.
| forgotusername6 wrote:
| And then when you need to provide an accessible version?
| michaelmior wrote:
| > the flow the magic link is part of is one you initiate
|
| There's nothing stopping anyone else from initiating the
| flow assuming the common implementation where only an email
| is required to initiate sending the link.
| jameshart wrote:
| Yes and when you receive an email saying
|
| Here is the link you requested from 'Android Device' in
| 'Belarus' - click here to sign in and allow that device
| to access your account - only click this if you requested
| this email
|
| You don't click the link if you didn't request it.
| lcnPylGDnU4H9OF wrote:
| The phisher will be on the phone with their victim,
| pretending to be a support agent for the business. They
| will say, "Yes click the link, that's how you verify with
| us."
| jameshart wrote:
| So many people on this thread leaping in with the
| phishing threat model.
|
| This is a simple quick login process, you wouldn't use it
| in a place where 2FA is required. It is a mistake to
| think of this as a substitute for 2FA just because it has
| some of the same elements as a secondary device
| authentication. It's not intended to be a 2 FA flow
| though! It's a single factor - 'does the user have access
| to a device that can read emails sent to this associated
| email address'. We aren't combining it with a password or
| anything else.
|
| That is the same level of auth used for things on many
| services like 'registering for a free account', and
| frequently for 'resetting the password on an account'.
|
| It's not a complete security solution and you wouldn't
| use it everywhere. It would be a bad fit for a banking
| app or access to a publishing interface. It's not a bad
| interface for things like 'logging in to my subscription
| on the TV' or 'returning as a customer to a website I
| shopped with once before'.
| jonplackett wrote:
| You might not. Your granny? Maybe.
| Findecanor wrote:
| BankID scams in Sweden worked because it did not require
| there to be authentication between the device that logged in
| and the device that authorised the login.
|
| 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.
| ultimoo wrote:
| so anyone can log in as you if you receive an email and
| accidentally click on it?
| sbrother wrote:
| Or if your mail client, spam filter or anything else tries to
| prefetch the link...
| jeffalyanak wrote:
| If you really want to allow for another browser to
| authenticate a login request, you can at least limit it to
| sessions coming from the same IP.
|
| 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.
| Gigachad wrote:
| To be safe the link can load a page with a form / button that
| says confirm the login.
| layer8 wrote:
| Some people will still click the button because they expect
| it will give them more information about why they received
| the link. You can add text along the lines of "authorize
| login on $other_device", but it's still risky.
| Sn0wCoder wrote:
| This is a fair point to bring up.
|
| 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...)
| Sn0wCoder wrote:
| Agreed! If they all worked like this would be a happy camper.
| Nothing worse than being in one browser, opening the email,
| then it opens and authenticates you on the default browser or
| even better on a different device and needing to forward the
| link to the other device so you can open it there (yes odd
| scenario but try not to access certain emails from certain
| devices).
|
| 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.
| jameshart wrote:
| Or in the Gmail client on iOS which opens links _in an
| embedded browser_.
| crazygringo wrote:
| You can change that in settings.
| finnh wrote:
| where? i just went through Settings > Apps > Gmail on my
| iphone and found nothing about this. Likewise the in-app
| Settings in the GMail app lets you choose which browser
| is the "default app" but it's already set to Safari (the
| other options are Chrome, by Google, and ... Google, by
| Google). But that uses an embedded Safari instance inside
| gmail, not the phone's Safari app.
| philsnow wrote:
| To get what you want (links open in Safari.app, not the
| safari webview inside Gmail): configure your default
| browser in Settings (your iphone settings, not gmail's
| settings) to be Safari, and then in Gmail choose "Default
| browser app" instead of Safari.
|
| It's super vague and unclear why things should work this
| way, and I don't know if this is forced on them by iOS or
| what. I'm trying to think of why choosing "Safari" in the
| gmail settings would use the webview instead of the app,
| and the most-charitable reason I can think of is that
| they don't want to contribute to the person having
| hundreds of Safari tabs open...?
|
| Less-charitable reasons might include wanting to keep
| users in the gmail app for driving "engagement". I read
| somewhere that when apps use the in-app webview, the app
| dev can inject arbitrary javascript and thus has full
| control and can see keystrokes, what the webview's
| viewport is looking at, etc. I really don't think that's
| what google is trying to do here, though.
| Glyptodon wrote:
| Even on Android that behavior is the bane of my existence.
| portaouflop wrote:
| OTP is the only sane option - there are too many edge cases
| for magic links to make them a good user experience
| layer8 wrote:
| This is bad (phishing). The better solution is have the login
| only work on the device where the link is opened, and for
| cross-device use to also provide an OTP code the user can read
| on the receiving device and easily type in on the initial
| device. (Or only provide the OTP code and no link.)
| jameshart wrote:
| How is that secure against the same phishing attacks that a
| clickable link is vulnerable to (basically the idea that
| someone can socially engineer you into a situation where you
| think you are supposed to complete the auth flow with _them_
| , enabling them to sign in as you?)
| layer8 wrote:
| It doesn't protect from telling them the OTP code, that's
| true.
| danudey wrote:
| Well, it doesn't solve the issue of someone sending you a
| fake login e-mail that you then mistakenly click on, that's
| true, but the whole point of magic links is that there
| isn't an auth flow; there's no password for them to steal
| from you.
|
| In other words:
|
| 1. A malicious individual sends them a fake login link
|
| 2. The link can't ask them for a username and password
| because the site doesn't have passwords, just magic links
|
| 3. The site could ask them for your OTP code if they have
| one, but the bad actor doesn't have their magic link and
| the OTP code expires in a few seconds anyway
|
| 4. Without the bad actor actually getting access to a
| legitimate magic link nothing happens
|
| It _does_ solve the issue of:
|
| 1. You visit the site on your device at the same time as
| they visit on their device
|
| 2. They get two e-mails and maybe click on the one that
| approves your session instead
|
| 3. Your session on your device logs in; theirs doesn't so
| they figure it's a bug and go click the other one. Now
| you're both logged in.
|
| If you require the session to be logged in by the link
| directly, it ensures that only the device you're viewing
| the e-mail on gets signed in; in the above scenario, your
| malicious session is never logged in, but their legitimate
| one is.
| paxys wrote:
| If you have a halfway competent security team they will never
| ever let this fly. You are begging your users to get phished.
| jameshart wrote:
| A fully competent security team will, on the other hand,
| carry out a more comprehensive threat modelling exercise and
| make a pragmatic choice about whether this kind of auth flow
| is appropriate for your usecase.
|
| 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.
| portaouflop wrote:
| Almost no one has a competent security team and if they do
| they don't listen to them. Security is just compliance
| checkboxes and lists nowadays
| josephh wrote:
| AFAIK, McDonald's does this with their mobile app (they weren't
| letting me log in with my password) But the problem with their
| implementation was that the magic link that they send you is
| wrapped in a click tracker whose domain is blocked by pihole
| (and the likes), and I could not reach the actual auth URL to
| complete the login process.
| portaouflop wrote:
| Many email clients will click the link and invalidate it - for
| example outlook is a classic here - so the best implementation
| does not use redirects/links at all.
|
| OTP is far better than an actual magic link - you can still
| include a link that pre-fills the code.
| Spivak wrote:
| Yes but clicking the link itself shouldn't log you in. Any
| implementation of magic links that does this is broken
| because of link previews.
|
| 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.
| pimlottc wrote:
| I've been stung by this before, where I'd already closed the
| original browser tab since I assumed the magic link would open
| a new tab (as they usually do)
| catchmeifyoucan wrote:
| From a developer perspective, I like magic links. They help
| verify an e-mail address, and log you in at the same time.
| Mystery-Machine wrote:
| Like there's no other way to verify an email address. From a
| developer perspective, I hate it, because it's yet another
| functionality that I need to add and support in my app.
| Glyptodon wrote:
| Why doesn't sending an OTC to an email and marking it
| verified if they put in the code also work?
| marketneutral wrote:
| claude.ai supports only either magic email links or google sign
| in. definitely a factor in why I prefer ChatGPT.
| airstrike wrote:
| I also find their magic link annoying, but since claude.com
| doesn't log me out all of the god damn time like chatgpt.com
| does, Claude is winning this round too...even though this is
| not a factor in why I prefer one vs the other.
| rtsil wrote:
| I just signed up for Claude yesterday and I didn't even realize
| that I didn't enter a password. It was when I wanted to use it
| on my phone (with Firefox, not the app) that I realized that
| there was no Claude entry in my password manager. It made me
| irrationally angry for about 5 minutes, and had I known it in
| advance, I would probably not have bothered.
| pjerem wrote:
| I like the Kagi qrcode login option. You scan the QR code with
| any device you are already logged in and boom, you can login with
| a button. Its like steam guard but with no app. It's in fact so
| simple that I don't understand why it's not universal.
|
| You still need another method for the first login.
| NobodyNada wrote:
| The biggest disadvantage of this scheme is that if a malicious
| actor can trick you into scanning an arbitrary QR code, they
| can get access to your account (by visiting the login page
| themselves to generate a QR code, and then sending you the
| code).
|
| 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").
| Mystery-Machine wrote:
| > 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.
|
| "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.
| kens wrote:
| Shop is the same as Shopify? Thank you (seriously) for pointing
| this out. I've been getting Shop emails and I had no idea.
| Mystery-Machine wrote:
| Haha. Thanks for proving my point!
| benoliver999 wrote:
| I've not seen Shop but always liked the simple ShopPay UX.
| codazoda wrote:
| I got one of these a couple days ago. I thought it was a well
| timed scam at first.
| dbalan wrote:
| The 404 article irked me a lot, thanks for writing this.
| gepeto42 wrote:
| You're welcome. Been thinking about it for a few days, and I
| had to do it. I don't disagree there's some benefits but being
| told "IT'S BETTER!" annoyed me quite a bit.
| rickcarlino wrote:
| Issues I've encountered building an app with magic links:
|
| 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.
| michaelmior wrote:
| > Make sure the sign-in link can handle email clients that open
| links automatically to generate preview screenshots.
|
| Any suggestions on what needs to be handled here? My first
| thought is UA checking to see if it looks like a real browser.
| rickcarlino wrote:
| In my app, I just added an "Almost there!" Page with a button
| that the user needs to click. I still need to add a fallback
| option that uses a one time code for the other reasons
| mentioned above.
| nine_k wrote:
| E.g. require to click a button to actually sign in, don't
| consume the token and establish the session on mere URL
| access.
| timfsu wrote:
| Using a time-based expiration rather than a usage-based
| expiration should help
| snthd wrote:
| The link is a "safe" GET request. The page loaded via the
| link should do an "unsafe" POST for the login, via javascript
| with a form button for fallback.
|
| 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.
| layer8 wrote:
| 1 and 3 are mentioned in the article. It's still annoying if
| there is no password option.
| mooreds wrote:
| We went to a lot of trouble to make our magic link
| implementation work with anti-phishing software, corp link
| checkers and more. https://github.com/FusionAuth/fusionauth-
| issues/issues/629 documents some of the struggle.
|
| I think that a link to a page where you enter a one time code
| gets around a lot of these issues.
| andrei_says_ wrote:
| I arrived at the same conclusion after going through the
| steps and seeing that some corporate systems mark the login
| link as malicious, and there's nothing I can do about it.
|
| Sending a code goes around a lot of issues.
| paxys wrote:
| 3 isn't really possible, because the redirect needs to be back
| to the browser session where you initiated the login from.
| scott_w wrote:
| Honestly, having run a number of experiments with magic link, I
| wouldn't recommend them. We saw our login success drop
| noticeably. We tried a few different approaches over the course
| of a quarter but even our best attempt only mitigated the drop
| compared to having email/password and Google Login.
|
| Obviously, your mileage may vary but it was a good reminder to
| always validate your assumptions, especially in your critical
| user flows.
| sebastiennight wrote:
| I'm super interested as we've been debating adding
| email/password (since we only use Magic Links at the moment).
|
| How are you tracking login success rates?
| scarface_74 wrote:
| > Stratechery, powered by Passport, 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.
|
| 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.
| gepeto42 wrote:
| Yeah the Stratechery implementation for podcasts is great. The
| more annoying thing is each of them has its own domain and
| requires logging in, if you don't know you can dig into
| Stratechery.com. I would prefer if I could login to it with a
| passkey or username+pwd, but it's a much better system overall
| than just dropping an email link.
| scarface_74 wrote:
| Once you subscribe to one of the podcasts, you can choose the
| "Manage your account" link from the podcast notes and choose
| the "Delivery Tab".
|
| It will give you all of the links to all of your podcasts. I
| did this from the "Dithering" podcast notes
|
| https://imgur.com/a/ThbTaly
| yawaramin wrote:
| Way better option: emailed OTP code and passkey with Conditional
| Mediation UI. If the user is logging in from a device that
| already has a passkey, the CM UI will let them just select it and
| log in instantly. If they are logging in from a device which
| doesn't, we can make the UX such that it asks them to enter the
| emailed code, and after that is successfully it immediately asks
| the user to set up a passkey for instant sign-in.
|
| 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.
| ejs wrote:
| I usually implement the whole username/password auth flow, but
| recently used only magic links for a simple application.
|
| 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.
| benoliver999 wrote:
| I have a system where users log in extremely infrequently.
| Tempting to move away from username & password because they
| just reset every time anyway.
| t0mas88 wrote:
| I recently encountered a food delivery website that insisted on a
| magic link / 2FA code check after a password login. Come on...
| I'm trying to order a pizza.
|
| 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.
| kleiba wrote:
| Sorry to ask - I don't have personal experience using such a
| system.
|
| 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?
| Gigachad wrote:
| No. The links are temporary.
| kleiba wrote:
| Oh, I see. Thanks! So, they're basically the second part of
| 2FA?
| Gigachad wrote:
| They aren't really 2FA at all since often you don't need a
| password. To login you just type your email and enter the
| code you got from the email or click a link.
|
| Shopify works this way where buyers don't have passwords
| and only log in with codes sent via SMS/Email.
| davewasthere wrote:
| And worse (sometimes) consumed by email scanners. There's all
| sorts of hassles with them. Email deliverability often an
| issue too.
| lolinder wrote:
| Am I misunderstanding something, or are passkeys not actually an
| alternative to magic links?
|
| 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
| Glyptodon wrote:
| The first thing I thought when I read this is how can the
| author make the specific criticisms of links/otp codes and then
| suggest passkeys, which have pretty much the same issues x10.
| Like if using a OTP from your phone or copying a link from your
| phone when using a work PC to visit a website is a pain, how
| much easier/better/same is it to try and have your work
| computer work with your personal passkey from a laptop or
| something?
| filmgirlcw wrote:
| I think as Ricky wrote last week [1], they should augment Magic
| Links or other auth methods. There are some positives about
| Magic Links for sure (though I don't know if making your email
| an even stronger attack vector is necessarily one of them), but
| for people who use a password manager, for example, they are a
| definite friction point that I think passkeys most certainly
| could alleviate.
|
| 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/
| lolinder wrote:
| Thank you for the link! I saw your other comment and actually
| edited mine to point to that, because it's definitely the
| answer to my question!
|
| > 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.
| filmgirlcw wrote:
| >The bad guys already know that your email is the best
| target. Magic links just make that very explicit.
|
| That's a good point. I guess my rationale is that it being
| explicit makes me feel less comfortable for my parents/non
| tech-savvy friends, who already may not follow best-
| practices for email hygiene (and may not use email
| providers that enforce stricter hygiene like 2FA or other
| methods of protection) and thus, systems like this, make
| their email even more explicitly the ultimate place to go
| for access to stuff.
| Gigachad wrote:
| Passkeys are in a transition period right now. There is no
| reason you have to have an alternative login method if you are
| using Passkeys, but no service has switched over to being
| Passkey only yet. Some users on older OSs / Linux might not be
| able to generate and store Passkeys yet, many users are not
| using a cross platform credential manager so if you've created
| passkeys with iCloud Passwords, there isn't a way to log in via
| linux right now.
|
| 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.
| filmgirlcw wrote:
| I think this is really great as a response to 404's post last
| week. I love 404 but I'm as annoyed by Magic Links as OP for the
| same reasons they mention.
|
| 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/
| gepeto42 wrote:
| Thanks for that link, I had not seen it and if I had known
| Ricky Mondello had written that, I probably wouldn't have
| bothered.
|
| I'm still used to Apple people being almost completely
| invisible publicly.
| filmgirlcw wrote:
| thanks for writing what you wrote -- I think it's important
| that we have this conversation as broadly as we can
| cmiller1 wrote:
| I'm confused, what's going on here? Is there a reason you
| wouldn't have bothered reading a post from that specific
| person?
| gepeto42 wrote:
| I meant Ricky's post is great and if I had known about it
| first I might not have written mine! Added a link to it at
| the bottom of mine.
| cmiller1 wrote:
| Ahh! Thanks for clarifying!
| lolinder wrote:
| Thank you, this is a better piece than TFA! Reading TFA I was
| rather confused at how passkeys are an alternative to magic
| links--it makes a lot more sense to view them as a complement.
| Magic links allow you access to passkeys, which are basically
| "Remember this Computer" on steroids.
| danudey wrote:
| I haven't had these specific issues with magic links
| specifically, but I do remember when Epic launched the Epic
| Games Store and they would e-mail you two-factor codes to log
| in. I consistently had issues where I wanted to log into their
| store, got prompted to enter the two-factor code they e-mailed
| me, got no email for several minutes, requested another code,
| didn't get that either, gave up and did something else, and
| then got both codes 30 minutes later.
|
| 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.
| cco wrote:
| As someone that does this for a living, 100%. Email OTP is a
| great alternative that splits the difference of magic links vs
| passwords.
|
| Agreed with some other folks that Passkeys is not a replacement
| for email verification.
| MrDunham wrote:
| Adding to the article:
|
| 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.
| Malcx wrote:
| Magic links are so useful in specific circumstances. We have a
| client with hundreds of users that infrequently need access to a
| bespoke tool. Setting up and managing user accounts for them is
| out of the question, but a magic link letting them sign in using
| an email of their corporate domain solves the issue easily.
___________________________________________________________________
(page generated 2025-01-07 23:00 UTC)