[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 : 668 points
Date : 2025-01-07 21:06 UTC (1 days 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
| billpg wrote:
| Because of the risk of auto-linkification, I'm of the
| opinion that browsers should put the entire dot-zip domain
| into the this-is-dangerous realm with big scary warnings if
| anyone follows a link. (Or at least any file downloads.)
| 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.
| finnh wrote:
| Wow - i even saw the words "default browser app" and did
| not even realize it was a setting choice. That works -
| thank you!
|
| wrt reason : I think that the webview has cookie
| isolation from the actual app, so using the webview is a
| bit more privacy-protective. Google being Google that
| seems unlikely to be the motivating reason, but who knows
| what good may lurk in the heart of men...
| 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.
| portaouflop wrote:
| I see - but then you can just use OTP instead - it works in
| the same way and you can even use it cross device
| 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.
| tacker2000 wrote:
| Also encountered this today and I didnt remember what email I
| used to login, so I tried both but now I seem to have 2 claude
| accounts, ugh...
| 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").
| apitman wrote:
| I feel like there should be a way to implement this in a
| phishing-resistant way. Maybe instead of a QR code some sort
| of video stream that updates dynamically? That would at least
| be much more difficult for attackers to pass through to the
| victim.
| 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.
| Macha wrote:
| > "Who doesn't use at least a few computers weekly?" > I don't.
| And many, many other people.
|
| 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.
| 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.
| justinator wrote:
| Automatic link pre-fetchers know JavaScript too and will
| trigger your JavaScript to post.
|
| I've had to implement a system where if the link was minted
| x minutes ago, the JavaScript on the landing page is
| disabled.
|
| It's just another arms race. It shouldn't be this hard, but
| in email it seems everything is additionally harder to do.
| adastra22 wrote:
| Why not just have a username & password. Why make
| everything so complicated? We just successfully got
| password managers deployed to most users, only to drop
| passwords entirely for a subpar system?
| cuu508 wrote:
| > We just successfully got password managers deployed to
| most users
|
| Source?
| adastra22 wrote:
| Every desktop and mobile OS has a built-in password
| manager perfectly adequate for this use case, with
| encrypted sync and backup capabilities.
| justinator wrote:
| One example is an unsubscribe link. Legally, it would be
| no bueno to have it behind any sort of login.
|
| Another is just counting if a link from an email was
| clicked. I want friction to be as little as possible.
| That's done by having some sort of redirect, but you have
| to use a JavaScript initiated post to weed add false
| positives. That's already ridiculous, but because of
| automated link prefetchers, you still need to disable
| that and show a f'n button.
|
| And then I have to answer to clients that want to know
| why their clickthrough stats are down precipitously and I
| don't honestly have the wherewithall to explain the inner
| workers of every filter that snoops their email before
| they read it.
| apitman wrote:
| If you want to do this without JS just add a page with a
| "Click here to complete login" button that does the POST.
| paxys wrote:
| Save a browser cookie when the login is initiated. When the
| link is clicked check if the same cookie is present. If not,
| ignore it. Expire the link and the cookie after n minutes.
| michaelmior wrote:
| After reading the other replies, this seems like one of the
| more effective approaches. Thanks!
| Macha wrote:
| Surely this breaks the "email is not on same device as
| login" use case? At least with normal magic links, they're
| merely incredibly annoying but doable (via e.g. typing in
| the URL)
| paxys wrote:
| That use case still works. In fact it works better
| because if you click the link on your phone you don't
| automatically get logged in on your phone browser (or
| your email client's in-app browser). You can then copy
| the same link on your desktop and it will work as
| expected.
| apitman wrote:
| I'm confused. How do you get the cookie from the original
| device to the other device?
| paxys wrote:
| It's the other way around. You copy the URL to the device
| that has the cookie.
| apitman wrote:
| How do you copy the link between devices? QR code?
| shakna wrote:
| As long as you also have a code to enter, then things
| will feel fine across devices.
| 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.
| js2 wrote:
| Also: Safari can autofill codes from both email and text
| messages on macOS and iOS. It then automatically deletes
| the message too.
|
| https://www.webnots.com/how-to-autofill-verification-
| codes-i...
| adastra22 wrote:
| Why not just support a password?
| ThePowerOfFuet wrote:
| Because [?]everyone reuses passwords and so accounts get
| taken over.
| sam_lowry_ wrote:
| So what?
| victorbjorklund wrote:
| 1) It means your users will complain that their account
| was hacked (even if it was their fault) and might cancel
| their service
|
| 2) hackers can exploit your system which hurts you (you
| are a VPS provider and someone mines crypto and you have
| to wave it for PR) or you run an email service and
| someone uses your app to spam (which hurts your email
| rep) etc.
| adastra22 wrote:
| A majority of internet users (>60% in 2024 and growing)
| use password managers and don't reuse passwords.
| wccrawford wrote:
| https://www.security.org/digital-safety/password-manager-
| ann...
|
| 36%.
| JW_00000 wrote:
| Do you have a source for that number? 60% seems extremely
| high based on non-technies I know.
| mooreds wrote:
| Agreed. I'd be thrilled if it were true, though! Because
| password reuse (esp without MFA) is a big problem.
| ctxc wrote:
| I'm surprised. >60% seems high even for tech literate
| software engineers!
| sebastiennight wrote:
| This is an extraordinary claim on two counts:
|
| 1. Sixty percent seems astronomically high, do you have a
| source?
|
| and
|
| 2. Most "normal" non-tech-savvy people I know who do use
| a password manager (which I've typically installed for
| them), are revealed a while later to still use a
| variation of password reuse : either storing the same
| password per _category_ of websites, or having a password
| _template_ they use on all sites, e.g.
| "IdenticalSecretWord_SiteName"
| lkbm wrote:
| I don't have the source, but don't think
| 1Password/LastPass/KeePass. Think the "would you like to
| save this login" built in to Chrome, Firefox, Edge,
| Windows, and iOS. These days, you have to opt-out of
| password management.
| schnable wrote:
| Right, use of a Password Manager does not imply they are
| using Password generation - it may just mean they click
| "Save this password" after logging in using a re-used
| password.
| dspillett wrote:
| In my experience 60% seems too high even for supposedly
| technical users (ref: I work in a dev firm), at least
| away from their jobs.
|
| I definitely don't believe it for the wiser population
| (my gut, again based on people I know, says the number is
| more like 10%, _maybe_ 15). Even the 36% figure on the
| report on security.org posted above seems dubious, I
| suspect they have some bias in their survey. Unless that
| is some people who use the iCloud password manager for
| some things and no password manager for everything else,
| so it isn 't claiming 36% _routinely_ use a password
| manager away from a few key accounts.
| matt-p wrote:
| Only having magic links gets you a _load_ of stuff for
| free,
|
| Higher level of security than just user+pass (w/ forgot
| password)
|
| Email verification
|
| Lifecycle management - in a SAAS when a user no longer has
| a corporate email, they can defacto not log in, wheras with
| a user+pass you need to remember to remove their account
| manually on each SAAS or have integration with your AD (for
| example)
| adastra22 wrote:
| It's not a higher level of security than password-based
| authentication. Why do you state that?
|
| One-time email verification is not the same as security
| model as magic links. Magic links require instant access.
| Many security sensitive sites require a time delay and
| secondary notification for password reset links, which
| you can't reasonably do for login links.
|
| Lifecycle management is an interesting point. There are
| some underlying assumptions that might not hold though--
| losing an email doesn't necessarily mean downstream
| accounts should be auto disabled too. Think Facebook and
| college emails, for example.
| mooreds wrote:
| > It's not a higher level of security than password-based
| authentication. Why do you state that?
|
| It _could_ be, depending on how the user has secured
| their email inbox access. I know I pay a lot more
| attention to my inbox than some random account. I don 't
| have data, but I think this is true of most people.
|
| I'm also more likely to enable MFA on my email account
| than I will on every random account I sign up for. And as
| far as the account providers, I trust the big email
| providers to be more secure than some random website with
| an unknown level of security.
|
| You raise some valid points about tying access to a third
| party and what makes sense. It's not a simple issue.
| michaelt wrote:
| _> It's not a higher level of security than password-
| based authentication. Why do you state that?_
|
| Personally I'm no fan of magic links.
|
| But the people who _do_ like magic links would say the
| typical 'forgot password' flow is to send a password
| reset magic link by e-mail. That means you've got all the
| security weaknesses of a magic link, _and_ the added
| weaknesses of password reuse and weak passwords.
|
| Of course you can certainly design a system where this
| isn't the case. Banks that send your password reset code
| by physical mail. Shopping websites where resetting your
| password deletes your stored credit card details. Things
| like that.
| matt-p wrote:
| It's not about 'liking' magic links;
|
| That means you've got all the security weaknesses of a
| magic link, and the added weaknesses of password reuse
| and weak passwords.
|
| Is objectively true. I don't really 'like' magic links
| but I think they're a very easy to implement and simple
| to use for infrequently accessed systems. Arguably easier
| than user/pass and certainly more secure.
| adastra22 wrote:
| Even with those assumptions (which I question), it is
| only a higher level of security if you assume that your
| users are reusing passwords, or using low entropy
| passwords. Neither would apply if they are using a
| password manager, which a growing majority of web users
| are.
| matt-p wrote:
| That's a fair point, but does time delay or secondary
| notification (the latter could be done for magic links of
| course) really outweigh the practical security risk of
| password reuse, attacks, leaks etc? I would argue not,
| unless the user had a insecure email account for some
| reason.
|
| Re Lifecycle management; Unless you're also linking a
| phone number or some other "factor" I think in a
| traditional user+pass scenario you're also SOL if you
| lose access to your $Email1 before you update your
| account to use $Email2, as changing your email to $Email2
| would usually send a email to $Email1 to confirm the
| action. In that case you're in the same position as magic
| link login + email change functionality. Similarly
| Lifecycle management only comes for free if you don't
| implement email change functionality.
| davidmurdoch wrote:
| One weird reason I've personal run into: when building on
| the edge, like with cloudflare workers, you can run into
| timeout issues because of how long password hashing takes.
| kentonv wrote:
| That should be only if you're on the free plan that has a
| 10ms time limit. Paid plan gets 30 whole seconds which is
| plenty of time to hash lots of passwords.
| mooreds wrote:
| Oh, we support passwords! (And passkeys, and social login,
| and OIDC, and SAML.)
|
| Just want to make sure magic links work as well as they
| can.
|
| Different folks have different requirements, and since
| we're a devtool, we try to meet folks where they are at.
|
| We actually recently added a feature which lets you examine
| the results of a login, including how the user
| authenticated, and deny access if they didn't use an
| approved method.
| presentation wrote:
| I've had success with sending a code, and the link takes you
| to a page where the input is pre-filled with the code, and
| you just have to click "Login".
| mooreds wrote:
| Yup, that's a good option. Any kind of user action like a
| form submission is less likely to run afoul of a link
| checker.
| lelanthran wrote:
| > I think that a link to a page where you enter a one time
| code gets around a lot of these 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.
| hackernewds wrote:
| one times codes are very vulnerable to phishing. users are
| prone to entering codes on any resembling website
| klabb3 wrote:
| I was gonna argue that you can fix this but I realized that
| you're right. It's a MITM attack where there's really no
| way to stop it, same as passwords. It's basically the same
| feature (sign in in a different browser) that also lets
| attackers in.
|
| That said, here's how I would mitigate it:
|
| - Like usual, time based limits on the code - Code is valid
| only for the initiating session, requiring the attacker to
| create a paper trail to phish
|
| If you do have a magic link & want to use code as backup
| for authenticating a different device/browser, you could:
|
| - Compare IP and/or session cookie between the initiating
| and confirming window. On match, offer login button. On
| mismatch, show the code and a warning stating how it's
| different, eg "You are signing in a different device or
| browser, initiated from $os $browser in $city, $country,
| $ip - $t minutes ago."
|
| It's not perfect though and may still be prone to phishing.
| paxys wrote:
| 3 isn't really possible, because the redirect needs to take you
| back to the browser session where you initiated the login from.
| o999 wrote:
| Not necessarily, some services would have the magic link
| verify the session that triggered it regardless of browser or
| device.
|
| I assume it generates a session on the post-login screen and
| authorize that session upon accessing link
| ydant wrote:
| That has the problem of opening up an attack where the
| attacker requests the sign-in link, the person receiving
| the link blindly clicks it, and the attacker now has
| access.
|
| People blindly click links all the time. It would have a
| low success rate, but would be more than 0%.
| pests wrote:
| I might receive a magic link on my phone but then sometimes
| I'll copy/paste that over to my desktop or another device.
|
| 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.
| duxup wrote:
| It seems like "prevent account sharing" and magic links are
| somewhat at odds by design.
| johnmaguire wrote:
| More than a shared password?
| pests wrote:
| The idea being the user(s) would then have to share a
| email inbox to share logins, not just a password. It
| might not be the most inconvenient - this is partly how
| Netflix did their "Household" lockdown. You can request a
| travel code and this gets emailed to the primary email.
|
| I feel the way Netflix did this broke the social contract
| of profile sharing on purpose - before, if you were a
| good tenant, you could freeload off another paid account
| without inconveniencing them at all. Memes and jokes
| formed of still being on an ex-partner's account or how
| people would rename themselves "Settings".
|
| Getting an email and being harassed for the code by all
| those account sharers? Much more open and open for
| annoyingness.
| Groxx wrote:
| It definitely does not.
|
| 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.
| renewiltord wrote:
| So I misclick a link in my email client and the evil guy
| who requested in is now logged in on his browser god knows
| where? Surely that can't be real. It sounds awful. TVs
| involve copying a code to make sure the right device is
| being authenticated, or the ones I've used have at least.
| Groxx wrote:
| Duo 2FA works the same way. In principle yes. And it's
| basically always accompanied by a "click this link" ->
| "are you trying to log in, and is this you? yes/no" page
| to resist that.
|
| Small code copying is also a very good answer though,
| yes. Roughly as easily manipulated, but nothing's
| perfect, and it's less "I didn't mean to click that
| button"-prone.
| renewiltord wrote:
| Yeah but I routinely click links in emails whereas
| logging in is the sole purpose of Duo. I could easily
| just intend to scroll the page and end up tapping the
| link.
| Groxx wrote:
| so have that open a site that says "confirm login? y/n".
|
| I don't mean to imply that _just_ visiting the link
| should be enough to complete a login. That 's a GET and
| there's a LOT of issues with doing anything important on
| GET. Just "do something on a different machine, then
| automatically complete login on the one logging in", and
| magic links to trigger that flow are a rather
| straightforward option.
|
| There's no reason _at all_ that it has to all occur on
| the same machine, and many reasons why attempting to
| require that doesn 't work out in practice even when it
| does happen on the same machine.
| renewiltord wrote:
| Ah I see. Yes, that makes sense.
| paxys wrote:
| No "tons" of systems do not do this. If you come across one
| that does it was built by a team that has no idea about
| security.
|
| TVs etc. are special cases because obviously there is no
| way to redirect to them, and even there developers will
| always have some kind of secondary checks like having you
| enter a code displayed on the screen.
| edoceo wrote:
| When I sign on to a bank it sends an SMS. Then my phone
| prompts me to share that code with the brower, on my
| desktop. It's a neat QOL "feature" - but kinda feels too
| automated to be secure.
| lupire wrote:
| That's because the server recognizes both clients, and
| you are prompted to approve the other client from the
| client that has the code. You are giving permission to
| the remote client, not taking permission from the remote
| client.
| edoceo wrote:
| The server recognized my device from the messenger/SMS
| app? That seems not correct.
|
| But somehow, the desktop browser and my mobile are tied
| together for this app. But no other sites have this
| magic.
| happyopossum wrote:
| If you have an iPhone and a mac, most sites that use SMS
| OTPs work this way
| edoceo wrote:
| Linux desktop, android phone.
| Groxx wrote:
| I've come across _dozens_.
|
| Google does it. Paypal does it. Duo does it. Lots of
| single-sign-on systems do it. All of those including not-
| TV scenarios, just normal computer-and-phone stuff, as
| well as sometimes other weird flows. Many of these are
| far beyond what most would label as "security competent",
| into "login security is a large part of their business
| and they have significant numbers of specialists hired".
|
| (it is probably safe to say none are "truly secure" or
| "actually security obsessed", but I doubt that's actually
| possible in large quantities. the requirements are too
| steep, for both implementers and users.)
|
| It's not the _most common_ , certainly, nor anywhere
| close. But it's very far from nonexistent.
| apitman wrote:
| Where does Google do this?
| Groxx wrote:
| Log in on browser -> push notification "is this you?" on
| your phone -> browser automatically continues when you
| say "yes".
| apitman wrote:
| But that's only as a second factor right?
| sunnybeetroot wrote:
| This seems dangerous:
|
| 1. Attacker starts a log in and triggers a magic link email
| 2. Email received and my browser client previews the link
| without my desire 3. Attacker is now logged in
| codetrotter wrote:
| That's why you combine it with a check for source IP and
| tell your user that they need to approve from a device
| that has same IP as the one they are logging in on. So if
| I'm logging in on my laptop, and approving with my phone,
| it will be rejected if my phone is using mobile data
| while my laptop is using landline, but will approve if my
| phone is connected to WiFi of the same network my laptop
| is connected to, or if my laptop is tethered via my
| phone, because then I have same external source IP on
| both devices.
| witrak wrote:
| This scenario is a solution only in simplest cases. It
| doesn't work when someone routinely uses a VPN on the
| phone (when often uses free public wi-fi in airports,
| railway stations, markets etc) because of possible MITM
| attacks.
| asddubs wrote:
| also some ISPs will give you a different IP every request
| apitman wrote:
| This has security and usability issues. NAT/CGNAT means a
| potentially large number of people can hijack your login.
| johnmaguire wrote:
| The links are one-time use so you need to take this into
| account anyway or users simply can't login. It's usually
| done with a required button click after following the
| magic link. Or you can try JavaScript techniques to
| detect a real browser.
| yieldcrv wrote:
| One thing I recently found annoying with Slack was that I
| wanted the company chat on my phone, but I didnt want the
| company's email on my phone given the overly broad control of
| my phone
|
| 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!
| tzs wrote:
| Would it have worked to forward the mail from your work email
| system to your personal email?
| sthatipamala wrote:
| If it's a big corp, they probably have strict data
| exfiltration policies for corp email.
|
| Maybe this one email would have been fine, but if it gets
| tripped, it's not worth the headache.
| k3lsi3r wrote:
| These same corps have opinions on where users can be
| logged into Slack as well. And ffiw most enterprises that
| have this kind of device management don't allow login via
| magic links via email anyways.
| yieldcrv wrote:
| Yes, accurate, I was able to access some slack workspaces
| but not the main one without putting the invasive
| management profile on my phone
| yieldcrv wrote:
| It wouldnt have worked any differently from the first qr
| code with quarantine, and been a flagged violation,
| eventually
| adastra22 wrote:
| Now your private email contents are subject to discovery.
| drsnow wrote:
| Genuinely: why? All that is related to the business email
| is already accessible, it's just been forwarded
| elsewhere. The info is already known. What's to discover?
| indeed30 wrote:
| To discover where else you then subsequently forwarded
| it.
|
| I'm not suggesting this is actually a problem, but that's
| how an argument could go.
| adastra22 wrote:
| It indicates that you used your this other email for work
| purposes. The point is that they don't know what's in
| there, and they want to see if you discussed stuff
| relevant to the case. The judge will deny such a request
| as a fishing expedition if there is no basis for
| believing that you used your personal email for work
| purposes. But if it is discovered that you started
| sending work emails to that address...
| tzs wrote:
| Assuming we are talking about discovery in a civil
| lawsuit involving your employer the party opposing your
| employer can ask for all documents you have that are
| relevant to the lawsuit. It is then up to you to turn
| over those documents.
|
| If they specifically ask for documents that are not
| relevant or if their request is too broad so will produce
| a lot of irrelevant documents your company's lawyers will
| tell them no.
|
| By the time someone is actually specifically giving you a
| list of things to turn over that includes your private
| email it will only be asking for things that are
| relevant. Most of your personal email will be excluded.
| tzs wrote:
| 4. Make sure the sign-in link on mobile works with your mobile
| app.
|
| 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.
| SOLAR_FIELDS wrote:
| I have heard that you are basically paying double what you
| normally would if you aren't hunting for deals in mcd's app
| these days. How much truth is there to that?
| red_phone wrote:
| The difference isn't nearly that dramatic, but there are
| definitely savings to be had via the app.
| packtreefly wrote:
| A lot. MCD corporate seems determined to get on the user
| data gravy train, and appears to be subsidizing it for the
| franchisees.
|
| Three large fries ordered at the counter costs over ten
| dollars.
| crazygringo wrote:
| Sure they want user data to observe people's purchasing
| habits. But they already have that if you always use the
| same debit or credit cards like most people do.
|
| But the more people use the app, the less cashiers they
| need and the less ordering kiosks they have to install.
| Plus customer satisfaction goes up because you can order
| ahead and your food is ready when you arrive. And getting
| used to the discounts means you probably won't switch to
| Burger King or Wendy's.
|
| I think additional user data is a relatively minor part
| of it.
| packtreefly wrote:
| > you can order ahead and your food is ready when you
| arrive
|
| That just sounds like a great way to get cold
| McDonald's...
|
| > I think additional user data is a relatively minor part
| of it.
|
| You're probably right about that, but I've always
| undervalued user data because I don't think it's ethical
| to exploit people like that.
|
| I'm sure that a well-timed push notification suggesting a
| personalized meal deal right around hungry-o'clock is the
| real goal of pushing this stupid app on their customers.
| crazygringo wrote:
| >> you can order ahead and your food is ready when you
| arrive
|
| > That just sounds like a great way to get cold
| McDonald's...
|
| The idea is to order 3 or 4 minutes in advance, not half
| an hour before...
| butterknife wrote:
| > But they already have that if you always use the same
| debit or credit cards like most people do.
|
| Don't they have only the last 4 digits and the issuer of
| the card? It is likely enough but there will be some
| noise.
|
| Not to mention any potential legal trouble if they used
| the card details without explicit consent. App contracts
| will get around that.
| crazygringo wrote:
| They have your name too. From what I understand, the
| tracking is generally done via something like the hash of
| the card number though. I've never heard of any legal or
| compliance issues with that, since the card number itself
| is not stored.
| butterknife wrote:
| Submitted a Subject Access Request to McDonald's here in
| the UK. I'll update here on progress.
| cardiffspaceman wrote:
| > your food is ready when you arrive.
|
| The food does NOT start cooking when you order it if
| you're picking up at drive thru. It starts cooking when
| you pull up to drive thru and give the magic code.
|
| In fact if the food is not easy to prepare you get put in
| a special parking space, where you wait for your order to
| be prepared. If it includes soft drinks they might serve
| those before they make you go park.
| andy800 wrote:
| Disagree on not going to BK/Wendy's. The "deals" game
| becomes a habit, switching costs are basically zero,
| people start to comparison shop each app for the best
| deal (like shopping for air travel). It's a bit of work
| because there is no single consolidator but it only takes
| a few seconds to scan each apps offers.
|
| At this point, being a fast food chain that doesnt have
| an app with deals is probably not viable - but I am very
| skeptical it generates any loyalty.
| mediaman wrote:
| It's not about data, it's customer segmentation. Frequent
| customers are more price sensitive, and are willing to
| use the app to get all the discounts, while occasional
| customers will not, so they can capture both the more
| price sensitive part of the market while getting higher
| margins from occasional buyers.
| andy800 wrote:
| As someone who spent many years segmenting customers and
| generating personalized marketing offers -- McDonald's is
| _awful_ at this. I was a 2-3x /monthly customer (USA
| based) for years (even more frequent a decade ago, but
| I'm talking about since the app), ordering the exact same
| core items every time (except during breakfast).
|
| When they began "value meals" last summer (which don't
| include their flagship items) they also removed the best
| deals from the app, the ones that did include Big Mac,
| QPC, 10-nuggets. I've placed _one_ non-breakfast order in
| 6-8 months, whenever they started this.
|
| I'm just one person, but if a customer declines from an
| expected 15-20 visits over a half-year period to 1, and
| you don't adjust your offer algorithm (and you're the
| biggest restaurant company in the world so no lack of
| resources), something is seriously wrong.
| MoreMoore wrote:
| They used to have great deals on the app in Germany. I
| used to go to McDonald's all the time. The deals suck
| now, and now I only go if I'm really craving a McMuffin
| Bacon & Egg.
|
| Whatever they're doing also isn't working for me.
| packtreefly wrote:
| > they also removed the best deals from the app
|
| They've captured the user base with the money that
| corporate was pumping into the app deals, and are in the
| process of enshittifying it by transferring the value to
| themselves instead of the users.
| andy800 wrote:
| This can work in a lot of industries - I am skeptical
| fast food is one of them. Switching costs are low,
| alternates are plentiful, and collecting information
| (reviewing deals/prices across companies) is relatively
| easy.
|
| If McDonald's enshittifies its deals while continuing to
| raise prices, it's way too easy for loyal customers to go
| elsewhere. I'm saying this as a huge fan and extremely
| loyal customer of McDonald's for decades... they are at
| serious risk of losing people like me. As I stated, I've
| gone from 15-20 visits to 1 since last June/July,
| whenever they made the big change.
| r00fus wrote:
| Whenever this happens to me I keep wondering how much I
| am of the A/B data test where I'm in the "less important
| group". Is it possible that their changes engaged (or
| profited from) the more active (daily/weekly customers)
| by making your situation worse?
| andy800 wrote:
| Perhaps. Let's assume that the value meals is a massive
| hit and they are collecting far more revenue from
| customers who like it, than they are losing from people
| like me.
|
| That's the whole point of data analytics and personalized
| marketing - even if the value meal works for _most
| people_ they can still go back to sending _me_ the offers
| and promotions I responded to previously, in an attempt
| to reverse my recent decline in spend /visitation. The
| app makes it possible to send individualized offers.
| There shouldn't be an entire "B" group where they just
| say, oh well.
| koolba wrote:
| > Three large fries ordered at the counter costs over ten
| dollars.
|
| Ask for a "bundle box" next time you're there. They're
| usually named after a local sports team.
|
| Two Big Macs, two cheeseburgers, two fries, and a
| 10-piece nuggets for $12-15 depending on the market.
|
| I think retail for just the Big Macs is that much these
| days.
|
| No app required.
| SOLAR_FIELDS wrote:
| > Three large fries ordered at the counter costs over ten
| dollars.
|
| This is kind of hilarious and depressing but I live in a
| high enough cost of living city in the states and I order
| mcd's rarely enough that I cannot tell contextually
| whether your statement indicates this is overpriced or
| underpriced.
| ChristianGeek wrote:
| It depends on how recently they came out of the fryer,
| how fresh the oil is, and the grease-to-salt ratio.
| packtreefly wrote:
| I will sadly admit that the high price of fries only
| angers me when they're not fresh.
| andy800 wrote:
| Much more - most McD's in USA charge over $4 for a large
| french fries.
| bpeebles wrote:
| It depends on order size. I think orders for one or two
| people over time you'd save close to 50% between deals and
| using points. For larger orders 20% off once a day is about
| the best you can do. (I'm my area/experience.)
| andy800 wrote:
| "Normally would" is more likely, prices from the
| mid-2010's. The order I used to pay about $12 and change
| for in 2015 (I know this because I ate there at least once
| a week), is now about $13, by using the app deals.
|
| However since the rollout of "value meals" last summer,
| they took away some of the better deals and now McDonald's
| is simply expensive (for McDonald's) even with the app.
| k4rli wrote:
| McD app is the absolute worst.
|
| 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.
| ctm92 wrote:
| These days there's also to consider that some Mail Threat
| Protection Tools (at least Microsoft Defender in Exchange
| Online does this) click links in Mails to check them.
|
| 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.
| aspect0545 wrote:
| What can you do to prevent automatic confirmation in that
| case?
| sandermvanvliet wrote:
| As far as I know there's nothing.
|
| The alternative is to send an OTP in the mail and tell the
| user to enter that.
|
| In that way there is no link to auto confirm.
|
| However, if you do that ensure that you have a way to jump
| straight to the page to enter the OTP because (looking at
| you Samsung) the account registration process can expire or
| the app is closed (not active long enough) and your user is
| stuck
| miohtama wrote:
| The link leads to a page where you need to press a button
| (HTTP POST).
| mixedbit wrote:
| I run an authorization service that allows to log-in using
| magic links and we managed to solve this. First approach
| was for the link opening GET request to do not log the user
| in, but to include an HTML page with JavaScript that issued
| a POST request with a code from the link to log the user
| in. This worked well for a long time, because email
| scanners were fetching links from emails with GET requests
| but did not execute JavaScript on the fetched pages.
| Unfortunately, some time ago Microsoft tools indeed started
| to render the fetched pages and execute JavaScript on them
| which broke the links. What works now is to check if the
| link is open in the same browser that requested the link
| (you can use a cookie to do it) and only automatically
| login the user in these cases. If a link is open in a
| different browser, show an additional button ('Login as
| <email address>') that the user needs to click to finish
| the login action. MS tools render the login page but do not
| click buttons on it.
|
| The issue that MS tools introduced is broader, because it
| affects also email confirmation flows during signups. This
| is less visible, because usually the scanners will confirm
| emails that the user would like to confirm anyway. But
| without additional protection steps, the users can be
| signed up for services that they didn't request and MS
| tools will automatically confirm such signups.
| szszrk wrote:
| > check if the link is open in the same browser that
| requested the link (you can use a cookie to do it) and
| only automatically login the user in these cases. If a
| link is open in a different browser, show an additional
| button ('Login as <email address>') that the user needs
| to click to finish the login action.
|
| Thanks for checking if it's the same browser. Some
| companies don't care about that ( _cough_ booking _cough_
| ) so harmful actors just spam users with login attempts
| in hope a user will click by accident. And _puff_ ,
| random guy gets full access to your account. I got those
| every day, if I ever needed to login this way I would not
| be able to figure out which request is mine.
| vanviegen wrote:
| Wouldn't that just log you in on the browser doing the
| clicking, instead of the attackers browser?
| szszrk wrote:
| You mean in the booking example? They logged in the
| browser that... requested access. So basically anyone
| that knew your login/email.
|
| I think it should check if browser requesting is the same
| as the one confirming, or just drop that whole dumb
| mechanism entirely.
| keskival wrote:
| Ok, what if an email has "click this link if it was you
| who tried to log-in", or "if it wasn't you"?
|
| Will Microsoft automatically authenticate malicious
| actors, or block yourself from services built with
| assumptions that the email client won't auto-click
| everything?
| mixedbit wrote:
| Login links from my service were automatically clicked
| and rendered and I know that other services discovered
| similar problems. Based on this I think that it is very
| likely the case with all the links in emails, but I don't
| know if there is any additional heuristic involved that
| would treat some links differently.
|
| See also this issue which suggests that all links are
| opened: https://techcommunity.microsoft.com/discussions/m
| icrosoftdef...
|
| Note that this doesn't affect all Outlook users, this
| Microsoft Defender for Office 365 is a separate product
| that only some companies use.
| pmontra wrote:
| > But without additional protection steps, the users can
| be signed up for services that they didn't request and MS
| tools will automatically confirm such signups.
|
| Indeed it's a bad thing but how bad?
|
| The admins of some web service get a database of emails,
| send them those registration links, make their mail
| software create the accounts and? They end up with a
| service with accounts that they could create without
| sending those emails, before they send some emails to
| solicit users to perform some action on their (long
| forgotten?) account. There is no additional threat unless
| I'm missing something.
|
| The admins have only an extra thin layer of protection
| because of the confirmation step but I think that any
| court can see through it.
| mixedbit wrote:
| The exploitation and potential damage would be service
| specific. Say a Dropbox like service for computer file
| syncing: An attacker creates an account for
| 'alice@example.org' and gets the signup email
| automatically confirmed. The attacker uploads some
| malware files to the account. After some time Alice
| attempts to create a valid account and resets password
| for 'alice@example.com'. Then Alice installs a desktop
| file syncing client provided by the service and malware
| files from the attacker get downloaded to her machine.
|
| Another example would be if a company hosted a web app
| for employees that allowed signups only from @company.com
| addresses. In such case an attacker could be able to
| signup with such an address.
| aftbit wrote:
| It defeats the email verification entirely. If that
| weren't necessary for something, why would the site
| require it?
| ku1ik wrote:
| That check for the same browser is a great idea. Thanks!
| robertlagrant wrote:
| That seems like a really thoughtless idea.
| devnullbrain wrote:
| I've had this problem as a user, accidentally previewing a
| link in iOS by tapping for too long.
| tuetuopay wrote:
| This is even worse for copying the link. On iOS the
| contextual menu comes with the preview, which will destroy
| the magic link.
| littlestymaar wrote:
| > These days there's also to consider that some Mail Threat
| Protection Tools (at least Microsoft Defender in Exchange
| Online does this) click links in Mails to check them.
|
| What an insane policy, why am I surprised Microsoft came up
| with it...
| sbarre wrote:
| It's not actually insane if the application hosting the
| link follows the principle that GET requests should not
| mutate state.
|
| This problem is ~20 years old from when CMS platforms had
| GET links in the UI to delete records and "browsing
| accelerator" browser extensions came along that pre-fetched
| links on pages, and therefore deleted resources in the
| background.
|
| At the time the easiest workaround was to use Javascript to
| handle the link click and dynamically build a form to make
| a POST request instead (and update your endpoint to only
| act on POST requests), before the fetch API came along.
| TeMPOraL wrote:
| Come to think of it, magic links by definition violate the
| principle that GET requests should not change state. Defender
| & preview tools are actually following the established norms
| here - norms that were established _decades ago_ precisely
| _because_ we hit the more broad problem with C, U & D parts
| of CRUD, and collectively agreed that doing destructive
| operations on GET requests is stupid.
| kragen wrote:
| You can GET a <form> which POSTs when you click the "log
| in" button.
| GTP wrote:
| Yes, but the GET itself isn't changing any state. The
| state changes only after clicking on the button. This is
| OP's point.
| kragen wrote:
| TeMPOraL said, "magic links by definition violate the
| principle that GET requests should not change state".
| That is a reasonable thing to think, but it is not true,
| because you can GET a <form> which POSTs when you click
| the "log in" button, unless you think a link to such a
| <form> page should be excluded from the definition of
| "magic link".
| Jolter wrote:
| In your example, it seems to me that the POST request is
| the action that changes the state.
| kragen wrote:
| Agreed.
| TeMPOraL wrote:
| > _unless you think a link to such a <form> page should
| be excluded from the definition of "magic link"._
|
| Yes. Linking to a form requiring user to press a button
| to submit an actual POST request _is_ one proper way of
| doing it, and won 't confuse prefetchers, previewers and
| security scanners - but it lacks the specific "magic" in
| question, which is that clicking on a link alone is
| enough to log you in.
|
| Can't really have both - the "magic" is really just
| violating the "GET doesn't mutate" rule, rebranding the
| mistake we already corrected 20+ years ago.
|
| (EDIT: Also the whole framing of "magic links" vs.
| passkeys reads to me like telling people that committing
| sins is the wrong way of getting to hell, because you can
| just ask the devil directly instead.)
| kragen wrote:
| Aha, then we agree on the facts, just disagree about
| nomenclature.
|
| Your theological analogy is hilarious!
| ku1ik wrote:
| This is the way.
| ThrowawayTestr wrote:
| Is 3 even possible?
| miki123211 wrote:
| One of the biggest advantages of magic links is that they're
| unphishable while still being easy to use (unlike passkeys).
|
| 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.
| tarxvf wrote:
| That would require I have my email on every device I might
| want to log in with.
|
| I don't like that for a number of reasons.
| hombre_fatal wrote:
| The conventional password system requires you to have a
| shared password manager on every device or that your reuse
| or memorize passwords. And that none of the service's users
| reuse passwords.
|
| It's all trade offs, else it would be easy.
| miki123211 wrote:
| Not to mention passkeys, which people seem to be so
| enamored with.
| KronisLV wrote:
| > 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.
|
| 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.
| 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?
| scott_w wrote:
| Pretty straightforward: you send an event for which variation
| your user saw and another when they login, attaching the
| login method to the attributes.
|
| You can use Mixpanel or Heap, which have mechanisms for
| mapping the non-logged-in user to your verified user on
| login, though you might need a bit of custom code to do it.
| sebastiennight wrote:
| Ah. We use June.so ; I'm assuming they might have a similar
| mechanism. We'll try and log login attempts so we can track
| this. Thank you!
| scott_w wrote:
| No worries! Our experience is that the hardest part (and
| it's not trivial) is associating the "anonymous user ID"
| to the newly logged-in user. Segment has an identify()
| function (I think Mixpanel has something similar), where
| you link the aliases, which then makes the reporting
| work.
|
| I've not tried June, so I can't say for sure, but it's a
| pretty common feature for product analytics. I'll be
| surprised if it's not possible.
| 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.
| pat2man wrote:
| Asking users to enter an emailed code does not protect against
| MITM attacks unfortunately
| yawaramin wrote:
| True, but pushing passkeys as the primary auth method reduces
| the risk to a great extent. It's a huge difference. As long
| as the user keeps using a relatively stable set of devices,
| they will 'approximately never' be exposed to MITM.
|
| 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.
| lolinder wrote:
| > As long as the user keeps using a relatively stable set
| of devices, they will 'approximately never' be exposed to
| MITM.
|
| As long as the user keeps a relatively stable set of
| devices and knows to be suspicious if they get asked for an
| OTP on a device that they know has a passkey. If they don't
| know to be suspicious (which let's be real, most people
| won't), they'll happily follow the instructions and fork
| over the OTP to a phisher who can use it to complete the
| authentication somewhere on their end.
|
| Magic links without an OTP fallback are more secure as the
| initial setup process because they can't be phished unless
| someone's actually MITM'ing their HTTPS traffic (at which
| point nothing can save you anyway). A phisher can get
| someone to send themselves a magic link, but it's much
| harder to get them to provide the link to them.
| yawaramin wrote:
| > Magic links without an OTP fallback are more secure as
| the initial setup process because they can't be
| phished...but it's much harder to get them to provide the
| link to them.
|
| It's not _that_ much harder. 'Due to security reasons,
| please copy and paste the _entire link_ that we just sent
| you into the following input box. If you don 't, your
| account will be compromised!'
| lolinder wrote:
| That's way harder than just asking someone to do _the
| exact thing that they 've already done over and over on
| your legit site_. Sure, some will still fall for it, but
| the bite rate will go _way_ down.
| yawaramin wrote:
| Phishing attempts by definition create artificially
| urgent abnormal situations whose job it is to convince
| the intended victim that they're legitimate. A difference
| in degrees like this strikes me as not really something
| to haggle about. Users who fell prey to the attack aren't
| going to be reassured on hearing how much more unlikely
| it was.
| 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.
| ejs wrote:
| Yeah - that's my thought too, the service I use them for is
| not something people often log into. Sometimes never.
| 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.
| hmof wrote:
| You stay logged in due to cookies. You don't need to keep the
| login link.
| ale42 wrote:
| Except that some people prefer to purge cookies when closing
| their browsers. And the session typically doesn't last
| forever, even if you keep the cookies.
| 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?
| avianlyric wrote:
| > how much easier/better/same is it to try and have your work
| computer work with your personal passkey from a laptop or
| something?
|
| 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.
| apitman wrote:
| What if the target device is a workstation or library
| desktop with no Bluetooth?
| superq wrote:
| Even if we assume that you're ok with connecting discrete
| and disparate devices together (and you always have your
| personal tracking device near you all the time), Bluetooth
| is basically comprised of a giant bag of vulnerabilities
| and weaknesses.
|
| > take 30 seconds to complete
|
| also, ouch.
| 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.
| notatoad wrote:
| >feel less comfortable for my parents/non tech-savvy
| friends, who already may not follow best-practices for
| email hygiene
|
| making people feel less comfortable is probably a good
| thing.
|
| i've managed to convince my dad to start taking his email
| security more seriously by reminding him a few times that
| if somebody gets access to his email, they can reset his
| password on every site where he uses that email address.
| it's good to remind people of why email security matters,
| and that it's not just about the personal messages from
| friends.
| adastra22 wrote:
| > 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
|
| Well, don't do that.
| lolinder wrote:
| Do you have an alternative proposal for letting users
| back into their accounts when they inevitably lose their
| passkey? Because if you don't, this isn't a serious
| answer.
| adastra22 wrote:
| Password, not passkey. Recovery codes should be setup on
| account creation, but recovery of the password manager
| itself is what is required, and that usually has its own
| recovery mechanism.
|
| Social key recovery is an underutilized solution as well.
| madeofpalk wrote:
| How do you do account recovery when you lose a password
| or MFA token?
|
| Of course, any website's auth system is as weak (or
| strong) as their recovery process. Different sites will
| implement this differently.
| lolinder wrote:
| Typically by email, which OP says "don't do".
| adastra22 wrote:
| > There are some positives about Magic Links for sure
|
| Like what? I'm failing to come up with a single benefit (for
| the user).
| apitman wrote:
| Not needing to remember passwords or use a password
| manager.
| adastra22 wrote:
| Password managers are now built into every operating
| system / browser, with trusted encrypted sync
| capabilities. The UX of using the built-in password
| manager is better than that of a magic link.
| 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.
| lolinder wrote:
| What does the final end state of passkeys look like? What
| happens if I lose the device I created the passkey on, if it
| gets bricked, or if I get banned by the platform that was
| supposed to be syncing my passkeys?
| Gigachad wrote:
| I'd think it's exactly the same as using a password
| manager. Yes in theory you could memorize 500 unique
| passwords or write them down, but no one is doing that.
|
| There are a few things unique to passkeys though. You can
| register multiple passkeys for the same account so you
| could in theory have a physical USB key and cloud synced
| passkeys. Not many people would do this I would think
| though it would be easier than memorizing every password.
| There are also data portability specs in progress right now
| that let you export/import passkeys between services.
|
| But at the end of the day I would suggest that it should be
| straight up illegal for a company to freeze your account
| without letting you export your data. It probably actually
| is by the GDPR. This problem also already exists for email
| too. If Google bans you, you'll find a lot of your accounts
| become unusable. Anything with email OTPs wont work, and
| some services like Discord won't allow updating your email
| without access to the existing one.
| lolinder wrote:
| It can't be the same as my password manager if email
| password reset flows disappear. If I lose access to my
| password manager but not my email, then I can go through
| and systematically reset all of the accounts that I
| remember exist. What you're describing with passkeys,
| though, would not allow me to do that.
|
| > But at the end of the day I would suggest that it
| should be straight up illegal for a company to freeze
| your account without letting you export your data.
|
| This would be great but it only addresses the least
| likely failure mode out of the ones that I brought up.
|
| And note that in many cases we're currently better off
| under the existing system if Gmail does ban you than we
| would be in your proposed world: only services that send
| OTPs on every login would be immediately inaccessibile,
| so you'll have time for most services to log in and
| switch to a new email address.
| Gigachad wrote:
| I think for most services you'd still be able to email
| reset your passkeys unless it's a particularly sensitive
| service, the kind which don't allow email resets of your
| 2FA tokens today.
| lolinder wrote:
| A password/passkey reset flow is semantically equivalent
| to an alternative login method and if done via email is
| semantically equivalent to a magic link.
|
| Which means that any service that claims to be passkey-
| only but supports email resets should just acknowledge
| that they support both magic links and passkeys as
| options--they're kidding themselves and their users if
| they pretend otherwise.
| Gigachad wrote:
| Passkeys are at least more convenient than magic links as
| they do not require opening an email or pulling your
| phone out for an SMS code. You're right though that they
| Passkeys + email reset is no more secure than email magic
| links, but I'd say email magic links are perfectly secure
| for most use cases. There really is no reason to continue
| using passwords these days and every website should
| switch to either magic links, Email OTP, or passkeys.
|
| For more sensitive accounts like bank accounts and
| government services. You'd probably have to go through
| some other reset process involving real ID and possibly
| an in person visit to a support location.
| Ajedi32 wrote:
| If your passkey manager account gets frozen the clients
| on all your devices should still have local copies of the
| passkey database that you could continue to use until you
| have a chance to export and migrate to another passkey
| manager.
| skybrian wrote:
| Passkeys are essentially an API for logging into websites
| that requires a password manager to use. The end state is
| that we become completely dependent on our password
| managers. To avoid a single point of failure, hopefully you
| own multiple password managers, and they're on independent
| devices, and there is a way to sync them.
| superq wrote:
| > 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.
| 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.
| digging wrote:
| Totally agreed - a correctly used password manager is many,
| many times easier and faster to use than so-called magic links.
| It's not even a contest.
|
| 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...
| Uvix wrote:
| Trying to explain to users of an unrelated site how to use a
| password manager sounds like a support nightmare.
| digging wrote:
| That is a very good point! You'd have to be careful to
| craft the messaging so that it doesn't imply you can help
| troubleshoot the password manager.
|
| But something simple could work. Already you usually have a
| note under a password field, "Must contain at least 8
| characters and at least one special character" or something
| to that effect. It could also have some note about "We
| suggest a randomly generated password from your password
| manager."
|
| I'm not building this out so I don't need every hole poked
| in the idea, just seems like it could work.
| yawaramin wrote:
| If someone is going to do this, 'At least one special
| character' etc. is not the way to do it. According to
| OWASP guidelines, a secure password must enforce a
| minimum length but _not_ any other specific criteria,
| because they actually end up _reducing_ password
| strength. Instead, the best option is to add a password
| strength indicator below the password entry field, to
| _encourage_ the user to create a strong password. The
| help text can also mention using a password manager but
| it 's difficult to do in a good way.
| grvbck wrote:
| One of my pet peeves is when rules counteract the purpose
| they are supposed to serve, usually because of
| incompetence. Two years ago, I worked for a few months
| for a company where time reporting was accessed through a
| specific web page.
|
| They required the password to be changed monthly, have at
| least 10 characters, at least one number and at least one
| special character. On top of that - they locked out
| password managers and pasting. "We need to make sure you
| are the one logging in and not a hacker that hacked your
| password manager" they explained when I asked.
|
| Out of spite I went for "Password12!" the first month and
| "Password123!" the month after, at which point I received
| an email from the IT department explaining to me that my
| choice of password was endangering the corporations
| security.
| normie3000 wrote:
| > I received an email from the IT department explaining
| to me that my choice of password was endangering the
| corporations security.
|
| Sounds like they were logging/storing passwords in
| plaintext.
| lmz wrote:
| Or offline cracking passwords using a wordlist.
| BenjiWiebe wrote:
| Isn't it nice that hackers give up as soon as they
| realize they can't paste the password in?
|
| And password managers (keepassxc anyways) have a pretty
| nifty auto-type feature that gets around that anyways.
| yawaramin wrote:
| Have you heard of the Cobra Effect?
| teeray wrote:
| You can tell them to write their password on a piece of
| paper in their drawer. Seriously.
|
| Many home users are pretty good about protecting important
| scraps of paper. The government gives us plenty to hold
| onto. Even if they're a grandma that doesn't understand all
| this password manager mumbo jumbo, they can deal with a
| notebook and be better off than using the same password on
| every site.
| 8organicbits wrote:
| Magic links breaking my flow is my top issue as well. My inbox
| is distracting: don't send me there. One affordance I've seen
| was a site that detected I was using gmail and crafted a link
| like https://mail.google.com/mail/u/0/#search/example.com,
| which brought me directly to the email I needed, while hiding
| everything else. I think it did a MX lookup to guess my
| provider.
|
| I wish magic links would go away, but if they need to stay,
| that approach was the least terrible.
| MrDunham wrote:
| Good point! I've seen this search link setup before and it
| was... somewhat palatable. Still more bad than good but at
| least better UX.
| babyent wrote:
| I use magic links for my enterprise application. In my humble
| opinion I believe magic links are fine.
|
| 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.
| 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.
| rubslopes wrote:
| I'm having a good experience with a recently implemented magic
| link system. I did it via WhatsApp instead of email, which is
| much more reliable. Of course, this is only possible because in
| my country every single person uses WhatsApp.
|
| I'm building something for a very tech illiterate audience, and
| everybody loves the simplicity of it.
| apitman wrote:
| I've wondered about doing this. Does WhatsApp let you send
| messages to arbitrary users via an API?
| aembleton wrote:
| Yes https://business.whatsapp.com/products/conversation-
| categori...
| apitman wrote:
| That looks even better than I hoped. Is this free?
| dpifke wrote:
| I've been a loyal Mercury customer for a while now, but their
| forced use of magic links as a third authentication factor any
| time my IP address changes ( _after_ authenticating with a secure
| password from my password manager _and_ after a valid TOTP) has
| me ready to move my company 's banking elsewhere.
|
| 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.
| MaxGabriel wrote:
| I'm the CTO of Mercury
|
| 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.
| dpifke wrote:
| Yes, I clear cookies every time I close my browser, as a
| layered approach to privacy on top of uBlock Origin and
| NoScript. There isn't a great way to exclude certain sites
| from this, other than setting up a dedicated web browser in a
| container just for Mercury.
|
| 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/eJxMzs1u4jAUBeCncXZB9vVfvPACZshoWIwYoi
| asdgkra2KV_JCGqPTpK-imq7xxx40vlO9IKia6ggL6zUlQHObdF6\ J
| I0alRHBWQvWKRuD4loLZxsJSRXZAwfNBQeQWozasdgeWsMyFZozE4RKZ4d151
| NOFtuq9w6IqLb-d5fGdyzaBmUIdx_NkzqBeacrqXkZaMxGSNQyQmf7_9GW7\
| Hf1cJ8zW9TshAwwba3ccLuN3u_r_PR9j_GkxxxmadDu32c59jMfkYFmKKP0ba
| IT0vzP4ynHN_-yyhZOTy9jmPPQn6gL-VLMfvvIA_XxbywRYhUbZUp0RpVCUC\
| qDsbasJHeObFMZ4YrFw1cAAAD__4XPZXw
|
| I have to manually remove the backslashes and re-combine the
| lines before pasting into my web browser.
|
| 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?
| jeremyjh wrote:
| You have to send emails through third parties or people
| won't get them, because you are also always sending them to
| third parties who host the recipients email and manage
| their spam. It might be a good reason not to send magic
| links but here we are talking about a tertiary
| confirmation, so its useless on its own right?
| dpifke wrote:
| The link in the email could be a direct link to Mercury's
| website, rather than one that passes through a third-
| party HTTP redirect service.
|
| Authentication tokens (even tertiary ones) usually are
| supposed to have pretty strong secrecy guarantees. I've
| done multiple security audits for SOC, PCI, HIPAA, etc.,
| and in every case the auditors would have balked if I
| told them signin tokens were being unnecessarily logged
| by a third-party service.
|
| (Also: I strongly disagree that the only way to get
| reliable delivery is via a third-party email service,
| especially at Mercury's scale, but that's a digression
| from the topic at hand.)
| MaxGabriel wrote:
| Oh good find, the link going through Mailgun as a
| redirect is a recent regression. We have a PR to fix that
| going live soon.
|
| That said, our security team and I agree there is no
| security issue here. Mailgun already can see the text of
| the emails we send.
| dexterdog wrote:
| How is there no security issue here? Email is not secure
| and it's even less so when you are sending it via a 3rd
| party. If this were a photo site or something that would
| not be a big deal but we're talking about a bank. SMS is
| not much better. Like somebody said elsewhere in the
| thread, you should allow people to opt out of insecure
| third-factor verifications since they are just an
| annoyance and are ultimately security theater.
| adastra22 wrote:
| It's not security theater. He explained above how this is
| used to defeat a specific phishing attack that they've
| actually seen in the wild. There are other, different
| threat vectors (e.g. compromise of the mail server) that
| it doesn't prevent. But that doesn't make it theater. as
| it does provide other value.
| dexterdog wrote:
| What does it stop? You already did a 2FA at this point.
| If an attacker has my 2FA he most likely already has my
| email so the 'value' being provided is at the cost of
| more complexity for the user. If this adds value then why
| not also do an SMS as well to be really, really sure that
| the user is legit? That would add even more value.
|
| And again, I wasn't saying that you can't do all of this
| nonsense, but users who see it as nonsense should be able
| to turn it off.
| edaemon wrote:
| Why would the attacker having your Mercury TOTP mean they
| most likely have access to your email?
| Jolter wrote:
| Again, see the post by MaxGabriel at
| https://news.ycombinator.com/item?id=42629109 where he
| explains how this measure actually defeated that
| particular pihishing/MITM attack.
|
| The attack wasn't that the attacker has my second factor,
| the attack was that the attacker tricked me into
| verifying a single login/transaction using my two
| factors, on their behalf.
|
| They probably judged that the inconvenience of the
| verification email affects few enough users that it is
| worth it. Most users don't switch IP addresses very
| often. And those that do, probably don't all clear their
| cookies after every session.
|
| Adding SMS in addition to email would be obviously
| useless, as you point out.
| apitman wrote:
| The emails in question are a third factor, not a magic
| login link.
|
| Even if they were, almost all email goes through third
| parties which are trusted implicitly. That's not great,
| but email is the only federated system in existence
| capable of implementing this type of decentralized login
| at scale.
|
| Maybe someday we'll be able to use something like Matrix,
| Fediverse OAuth, or ATProto OAuth instead, but those are
| all a ways off.
| mbreese wrote:
| _> passes through a third-party HTTP redirect service_
|
| The vendor might not be the only party to use an HTTP
| redirect service too! My email goes through a security
| screen by $EMPLOYER, which also rewrites links to get
| processed through their redirect service. Sure, it's for
| company-approved reasons, but it's still another party
| that has access to the login token.
| lyime wrote:
| What would be a more secure (yet reliable) method for email
| delivery for such emails?
| dpifke wrote:
| Make the link in the email https://mercury.com/something
| instead of https://mailgun.com/something (which then
| redirects to https://mercury.com/something). Or (in
| addition to, or instead of, a hyperlink) provide a 6-10
| digit numeric or alphanumeric code that could be copied
| out of the email message into a form field on the signin
| screen.
| MaxGabriel wrote:
| > 6-10 digit numeric or alphanumeric code that could be
| copied out of the email message into a form field on the
| signin screen.
|
| To be clear this is what we're trying to avoid. An easily
| typeable code like that can be typed into a phisher's
| website.
| dpifke wrote:
| How about giving me a setting to disable device
| verification: "I know how to type mercury.com into the
| URL bar and accept all risk of getting phished."
|
| I appreciate you guys are trying to protect people, but
| no other financial institution I deal with requires this
| level of annoyance, and at some point I'd rather switch
| to a less "secure," but more usable service.
|
| (I put secure in scare quotes, because some suggestions,
| like trading true 2FA, where I have two separate secrets
| on two separate devices, for a single WebAuthn factor,
| are actually accomplishing the opposite, at least for
| those of us who don't click links in emails and don't use
| ads on Google for navigation.)
|
| Edit to add: or maybe save the third factor for
| suspicious _activity_ , such as "new device adding a new
| payee," rather than every signin. It's been months since
| I onboarded a new vendor, and I'd be OK with only having
| to do the cut-and-paste-the-link dance a couple of times
| a year, rather than every single time I want to check my
| balance.
| sebastiennight wrote:
| My understanding (as CEO of a startup using Mailgun for
| magic links) is that you're seeing mailgun in the URL
| because they have click tracking enabled -- which, to be
| fair, is not super useful in the case of verification
| emails.
|
| They could use a custom subdomain for this click tracking
| and "hide" the mailgun url from you, but we're finding
| that for some reason Mailgun doesn't just use a let's
| encrypt certificate, so some users will complain that the
| tracking links are "http" (and trigger a browser warning
| when clicked).
|
| Anyway, even with click tracking disabled and links going
| straight to mercury.com, the security issue would remain
| the exact same (since Mailgun logs all outgoing email
| anyway).
|
| But my understanding is that the contents of that email
| and its link do not provide "login" capability but
| "verification" capability. As such, a Mailgun employee
| accessing your data, or an attacker accessing your
| Mailgun logs, would only be able to "verify" a login that
| they had already initiated with your password AND your
| OTP --which means that's effectively a third hurdle for
| an attacker to breach, not a one-step jump into your
| account.
| mhitza wrote:
| At the very least, you can be creative with workarounds for
| such issues. A bookmarklet can be convenient.
| javascript:void(window.location.href =
| window.prompt().replace(/\\\n\s*/g, ''));
| incompatible wrote:
| I set Firefox to delete cookies at shutdown, and also an
| add-on called Cookie AutoDelete, but they both have an
| option to whitelist a site.
| packtreefly wrote:
| > 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.
|
| I've seen passkeys support something like what you're
| after. The browser will produce a QR code you scan with
| your phone, and then you authenticate with the passkey via
| the phone, which then authorizes the original browser.
|
| I'm not absolutely certain that this is part of the spec or
| how it actually works. I'd like to know. It solves a couple
| different usability issues.
|
| You could always use something like a Yubikey.
| dpifke wrote:
| > You could always use something like a Yubikey.
|
| This is the option I prefer, but only on sites that allow
| me to enroll more than one device (primary, and backup
| for if the primary gets lost or damaged). AFAICT, Mercury
| only allows a single security key.
|
| I have an encrypted offline backup of my TOTP codes, so
| if I drop my phone on the ground, I don't get locked out
| of all my accounts. I keep this separate from the
| encrypted offline backup of the password manager on my
| computer, and as far as I know, neither has ever been
| uploaded to anyone else's "cloud." Malware would have to
| compromise two completely separate platforms to get into
| my accounts, rather than just iCloud or whatever
| credentials.
|
| I understand the desire for phish-proof credentials, but
| --given that I don't click links in emails--my personal
| threat model ranks a compromised device (via attack
| against a cloud service provider, or software supply
| chain attack against a vendor with permission to "auto-
| update," or whatever) much higher likelihood than me
| personally falling victim to phishing. I readily admit
| that's not true for everyone.
| MaxGabriel wrote:
| > AFAICT, Mercury only allows a single security key.
|
| We allow multiple security keys. You can add more here:
| https://app.mercury.com/settings/security
| dpifke wrote:
| Oh, nice! This wasn't obvious from the help text. Maybe
| add it to the FAQ on the "Adding security keys" sidebar?
| packtreefly wrote:
| > my personal threat model ranks a compromised device ...
| much higher likelihood than me personally falling victim
| to phishing
|
| I completely understand that. I'd actually be interested
| in reading anything practical you might have on that
| topic if you don't mind. I asked some experts who gave a
| talk on supply chain security last year ... they didn't
| have a lot of positive things to say. Developing software
| feels like playing with fire.
| dpifke wrote:
| It feels unstoppable, which is why the best I can do is
| try to mitigate its impact. Some mitigations that come to
| mind:
|
| The development environment where I'm downloading random
| libraries is on a completely separate physical machine
| than my primary computer. I generally spin up a short-
| lived container for each new coding project, that gets
| deleted after the resulting code I produce is uploaded
| somewhere. This is completely separate from the work-
| supplied machine where I hack on my employer's code.
|
| On my primary computer, my web browser runs in an
| ephemeral container that resets itself each time I shut
| it down. My password manager runs in a different,
| isolated, container. Zoom runs in a different, also
| isolated, container. And so on.
|
| Wherever possible, I avoid letting my computer
| automatically sync with cloud services or my phone. If
| one is compromised, this avoids spreading the contagion.
| It also limits the amount of data that can be exfiltrated
| from any single device. Almost all of the persistent data
| I care about is in Git (I use git-annex for file sync),
| so there's an audit trail of changes.
|
| My SSH and GPG keys are stored on a hardware key so they
| can't be easily copied. I set my Yubikey to require a
| touch each time I authenticate, so my ssh-agent isn't
| forwarding authentication without a physical action on my
| part. I cover my webcam when not in use and use an
| external microphone that requires turning on a preamp.
|
| I try to host my own services using open source tools,
| rather than trust random SaaS vendors. Each internet-
| facing service runs in a dedicated container, isolated
| from the others. IoT devices each get their own VLAN.
| Most containers and VLANs have firewall rules that only
| allow outbound connections to whitelisted hosts. Where
| that's not possible due to the nature of the service
| (such as with email), I have alerting rules that notify
| me when they connect somewhere new. That's a "page" level
| notification if the new connection geolocates to China or
| Russia.
|
| I take an old laptop with me when traveling, that gets
| wiped after the trip if I had to cross a border or leave
| it in a hotel safe.
|
| I have good, frequent backups, on multiple media in
| multiple offline locations, that are tested regularly, so
| it's not the end of the world if I have to re-install a
| compromised device.
| packtreefly wrote:
| > The development environment where I'm downloading
| random libraries is on a completely separate physical
| machine than my primary computer. I generally spin up a
| short-lived container for each new coding project, that
| gets deleted after the resulting code I produce is
| uploaded somewhere. This is completely separate from the
| work-supplied machine where I hack on my employer's code.
|
| Something like VS Code remote dev with a container per
| project? Just plain docker/podman for containers?
|
| > On my primary computer, my web browser runs in an
| ephemeral container that resets itself each time I shut
| it down. My password manager runs in a different,
| isolated, container. Zoom runs in a different, also
| isolated, container. And so on.
|
| Qubes, or something else? I've been looking at switching
| to Linux for a while, but Apple Silicon being as good as
| it is has made making that leap extremely difficult.
| dpifke wrote:
| Mostly Linux with systemd-nspawn, also some Kubernetes,
| plus the occasional full VM. (If I were setting this up
| from scratch, I'd probably try to figure out how to run
| my desktop as 100% Kubernetes, using something like k3s,
| but I don't know how practical things like GPU access or
| Waypipe forwarding would be via that method.)
|
| I live inside Emacs for most things except browsing the
| web, either separate instances via SSH, or using TRAMP
| mode.
|
| If you switch to Linux, I highly recommend configuring
| your browser with a fake Windows or MacOS user agent
| string. Our Cloudflare overlords really, really hate
| Linux users and it sucks to continually get stuck in
| endless CAPTCHAs. (And doing so probably doesn't hurt
| fighting against platform-specific attacks, either.)
| watermelon0 wrote:
| Is there a reason that TOTP cannot be used as a second
| factor when using Passkeys?
|
| Not sure why we suddenly went from 2 factors (password +
| TOTP) to 1 factor (passkey), even if passkeys themselves
| are better.
|
| TOTP should at least be an option for the users.
| adastra22 wrote:
| Pretty sure that is eMacs formatting, not the email itself?
| Can you kill-copy the URL?
| thefreeman wrote:
| So you are intentionally crippling your browser and ability
| to access email (you need to ssh to another computer and
| access via terminal). You also aren't able to handle emacs
| wrapping of long lines. And you are complaining that the
| security in place to prevent stolen credentials is
| "inconveniencing you".
| m463 wrote:
| I like the schemes that send a numeric verification code that
| you manually type in without an email link. can also use a
| text message. Maybe allow this to be configured.
|
| security = 1/convenience
|
| but also vice versa
| miyuru wrote:
| > IPv6 gets more traction IPs will rotate much more regularly
|
| 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.
| o999 wrote:
| Most internet users (who aren't tech savvy and will never be)
| will find magic link || mailed OTP way easier than passkeys
| accross devices, etc..
| lxe wrote:
| > I don't have my email on my gaming PC, nor do I have it on my
| work laptops.
|
| What? You have your email on literally every device -- be honest.
| dgrove wrote:
| Just because you make exceptions doesn't mean everyone else
| does
| mrweasel wrote:
| Nope, I don't have email on my phone. This breaks magic links
| all the time for me. In many situations I wouldn't even be able
| to configure my phone to show me my email, because I don't know
| the password, it's in my password manager and is lke 52 random
| characters.
|
| 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.
| gepeto42 wrote:
| I don't have my home email on work devices. I also don't have
| my email on my gaming PC (I agree this must be rarer). I don't
| have all of my work emails on my personal devices either. So
| now when I log in I need to DM myself links over Slack, or
| forward emails around...
| dandigangi wrote:
| Been saying this for a bit now. OTP/magic links have some upsides
| but the second your SMS or email provider doesn't deliver said
| thing your users are in trouble.
| n144q wrote:
| My data point as an edge case: on a certain website, I have a
| throwaway account registered with a throwaway gmail account. I
| don't use that gmail account for anything else, and in order not
| to affect my regular Gmail login, I use incognito window. Now,
| whenever I need to log in to the website on a new device, I have
| to also login gmail as well (since the login credentials are
| never kept between sessions). This has been very annoying, and
| would not happen with password with 2FA.
| sergiotapia wrote:
| Just use email and password, companies. Please. I have a password
| manager, I will stop using your service if it's a pain to login.
|
| Even something small thing like email -> hit enter -> then we
| show password input, will cause me to stop using your service.
| ivanjermakov wrote:
| I was surprised to learn how many people never save passwords and
| just reset it via email whenever they need to log in.
| lyime wrote:
| I don't like magic links but OTP code via email or sms has
| preferable set of trade-offs.
| paxys wrote:
| I'm okay with magic links IF the website using it doesn't
| invalidate my session for no reason after some random period. If
| I have to do the email song and dance every week I'm very likely
| to eventually not bother with the product (looking at you
| Claude).
| FriedPickles wrote:
| Calling these links 'magic' is an insult to magicians who spent
| years mastering actual sorcery. We're just passing around URL-
| encoded tokens.
| Halian wrote:
| I * _hate*_ magic links. Just let me use a damn password.
| theltrj wrote:
| Thank you for writing this! Getting users to implicitly trust
| clicking a link as a login mechanism....what could possibly go
| wrong?
| shoelessone wrote:
| I completely agree. I find magic links much more of a hassle than
| a password.
| tonymet wrote:
| Or the involuntary option. Here is an example from Lowes
|
| 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?
| perryizgr8 wrote:
| I once had an app send me a code in the email. But if I opened my
| email app to check the code, and then return to the app to enter
| it, it would lose context! It would ask me to enter my email
| again, and proceeded to send a new code. There was no way to log
| in using only my phone.
| shark_laser wrote:
| Nostr Login using NIP07 is amazing.
|
| 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.
| gregates wrote:
| I suspect a hidden "benefit" to the companies implementing this
| is that it makes it much harder to share your account. You are
| probably happy to share your Netflix password with your mom, but
| not your email password.
|
| They can present it as a "more secure" login method, obscuring
| the reason they actually like it.
| pcchristie wrote:
| I'm pretty sure Medium (who was the first implementation of
| this that I know of) uses it as a way of blocking pay wall
| bypassers (which on Medium I think manipulated/deleted cookies
| to get around the 3 article limit).
| gepeto42 wrote:
| Yeah that would not surprise me, in general. I don't think that
| would be 404's goal, since they provide full-text RSS feeds I
| could share with a friend easily, but I could see that
| happening with other services.
| rednafi wrote:
| Username and password combo works. All these ceremonies around
| OAuth, passkeys, and magic links solved one problem but
| introduced two more. My job as a service provider isn't to coddle
| people who can't be bothered to use a password manager.
|
| 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.
| tptacek wrote:
| Your job as a service provider is, in fact, to minimize the
| likelihood that you will manage to communicate the passwords of
| your users to outsiders, because those passwords are very
| likely to be shared. That passwords should not be shared
| doesn't reduce your responsibility.
| jerieljan wrote:
| Every time I see magic links, I always think: "I thought we
| weren't supposed to click links in emails in the first place?".
|
| When links in email come into mind, so does phishing.
|
| I hate these magic links a lot.
| crazygringo wrote:
| Is anyone confused by that? Password reset links have always
| been sent to email.
|
| 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.
| SV_BubbleTime wrote:
| Ok. So now my users get random login links for sites we may
| or may not use... sure, you Silicon Valley Cool Guy aren't
| going to fall for it, but my blue collar Detroit UAW guys
| might.
|
| 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.
| adastra22 wrote:
| I don't like password reset links either. Send me a code I
| can type in, but only to the original browser session.
| tylersmith wrote:
| Nobody is actually confused, it's just performative whining.
| gepeto42 wrote:
| As someone in the security industry, I find it amazing how
| much we've told people (in awareness training) to "not click
| things on the thing-clicking machine(tm)" while
| simultaneously having processes like password resets that
| require doing it.
|
| (tm)Kelly Shortridge 2021
| (https://x.com/swagitda_/status/1503751776134180873)
| makeitdouble wrote:
| Fake password reset links are also a common attack vector, so
| yes people are told to be also cautious of those.
|
| 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)
| m463 wrote:
| I don't even load images. email address -> ip address.
|
| apple's email privacy scheme seems interesting (apple always
| loads all images), but I don't know if there are drawbacks.
| muppetman wrote:
| Magic link are so, so stupid. Sure, make it an option for
| Grandma, but don't trot them out like they're amazing, they're
| terrible. God I hate the way the Internet is going - idiots
| making technical decisions.
| dmattia wrote:
| They are sometimes required. Say you are on a mailing list for
| some company you gave your email to at some checkout counter
| one time, and you want to unsubscribe. You probably don't have
| an actual account with a login with that retailer, they just
| have your email address.
|
| 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?
| ale42 wrote:
| There are many options where such links are a reasonable
| option. I'm okay to receive such a link to validate my e-mail
| for an account creation, or to unsubscribe from a mailing
| list at a place I don't have an account at, or to display an
| order status page at a shop where I ordered as a guest
| without creating an accoung.
|
| 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).
| mediumsmart wrote:
| What a good idea to get people used to clicking on a link in an
| email to login. Magic opportunities.
| albert_e wrote:
| Fun domain name.
|
| Unfortunately blocked on my (work) network -- classified as
| miscellaneous / unknown category.
| gepeto42 wrote:
| I have to admit I bought it mostly to annoy a few very specific
| friends, but then I kept using it. I would not recommend trying
| to host anything serious on such a TLD.
|
| If you check the early comments on the thread I posted the full
| content for someone else who could not reach .zip domains.
| ahmedhanks wrote:
| No issues for me.
| SV_BubbleTime wrote:
| Expensify.
|
| 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.
| adastra22 wrote:
| I refuse to use any service that only supports magic links for
| auth. It is _incredibly_ user-hostile, and absolutely worse from
| a security perspective than passwords (with a password manager).
| Most critically it simply _does not work_ in my personal setup
| where I do not have access to my email account from the machine I
| am using to login, precisely for security reasons and the safety
| of my accounts.
|
| 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.
| apitman wrote:
| Sadly not enough people use password managers for it to be
| worth it for companies to target those flows.
| adastra22 wrote:
| 60% of Internet users rely on a password manager, and that
| number is still growing by a significant amount each year.
| apitman wrote:
| A quick search is indicating more like 30%, which honestly
| is way higher than I expected. Where are you seeing 60%?
| adastra22 wrote:
| It is ~30% for personal use, and ~60% when you include
| personal + work. So 30% use it in both contexts, and an
| additional 30% just for work. A combined 60% use password
| managers in some capacity in their work or personal
| lives.
| apitman wrote:
| Cool, thanks. Do you have a link to these stats?
| budding2141 wrote:
| >absolutely worse from a security perspective than passwords
|
| Is it though? Majority (if not all) services I frequently use
| have email as recovery option for forgotten passwords.
| adastra22 wrote:
| It is certainly not all, and most security conscious sites
| offer other recovery options like one time use codes. Many
| also allow for time delayed account recovery, which aren't a
| usable option for magic links.
|
| 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.
| _tom_ wrote:
| Yeah, and everyone who did not flunk security training knows not
| to click on the links.
|
| Don't send me a link, tell me where to find it, after I log in.
| doener wrote:
| Oh I hate how Slack uses this. Because if extensive use of magic
| links I lost track about my two accounts and several spaces.
| Terr_ wrote:
| > Of course, as stated in the article, such email links are
| harder to phish than passwords
|
| 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.)
| sebastiennight wrote:
| We've been using Magic Links for a few years (and yes, one reason
| was to avoid the security issue of storing user passwords when we
| were just at MVP stage) and found the top problems with it are:
|
| 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.
| tjoff wrote:
| ... but the usability is a nightmare.
| graemep wrote:
| Absolutely. Users have to wait for the email before signing
| in, it does not work on devices without email without copying
| the link, etc.
| 255kb wrote:
| It's indeed interesting the number of people misspelling their
| email address, or having an inbox so full that it cannot
| receive emails anymore.
|
| 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).
| yvoschaap wrote:
| The number of support requests I got last year because of
| [hotmail|gmail|msn|yahoo].con > 30
| revicon wrote:
| I just auto switch any incoming .con to .com on the back
| end. 100% of the time it is a user typo
| andy800 wrote:
| Just a very small detail, but want to point out the
| distinction between these two comments. "Revicon" is
| demonstrating 10x thinking, it's not about being better
| at rewriting a linked list algorithm or some leetcode
| challenge.
|
| Player 1 gets the same support request over and over,
| does nothing about it, ("hey, that's what the user
| entered, they should be more careful!"), complains about
| it online, and who knows how many hours are wasted in the
| back and forth with the customers.
|
| Player 2 simply makes the necessary change on the
| backend, the users don't even realize they made a typo,
| totally seamless flow.
|
| Hat tip to you. Hope you screenshot these two comments
| and bring this up in every interview to exemplify the
| contrast between "technically correct" and high-
| efficiency problem solving.
| pixelsort wrote:
| A tasteful post and distinction well highlighted.
| Humorously, Yvo Schaap is no stranger to 10x thinking.
| For one thing, Yvo publishes diagrams on SaaS/dev topics
| that always seem consistently way ahead of their time in
| terms of their organization and completeness.
| 255kb wrote:
| Nice trick! I check on the frontend for all gmal, gmial,
| etc variations :)
| bshacklett wrote:
| > I check on the frontend
|
| This is the way. The user can benefit from feedback that
| they got something wrong, in addition to a helping hand.
| sebastiennight wrote:
| A couple of years ago I think I saw a frontend library that
| warned the user / auto-fixed those typos, but I can't
| remember its name, and all I can find now are SaaS offers
| for that kind of service.
|
| Which I'm not entirely enthusiastic about as it leaks all
| user emails to some random service.
| watermelon0 wrote:
| Wouldn't privacy aware users prefer passkeys or passwords,
| instead of any kind of SSO?
|
| 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.
| hackernewds wrote:
| Believe it or not, most users are not that privacy cautious
| 255kb wrote:
| That would be my guess too. I think convenience always win.
| wodenokoto wrote:
| > 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
|
| 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.
| lolinder wrote:
| > my password out of your system
|
| This shouldn't be a factor because your password should be
| a random series of characters that are unique to that site.
|
| > 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.
|
| To an absolute minimal extent: you can make it so Google
| won't tell them whatever it was they already told them
| again. But you can't make them delete the data that they
| already lifted from your Google account.
|
| For keeping surfaces out of your inbox, that's what email
| aliases are really good for. Register with an alias and
| then block that alias if they abuse it.
| kstrauser wrote:
| I have my HN username at a venerable webmail service. I check
| it about once a year, tops. My name isn't unimaginably rare,
| but neither is it "Smith".
|
| 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.
| jdhawk wrote:
| Same issue. I've had university professors put my email
| address in their sylabus instead of ____.edu, and been
| carpet bombed by assignments, excuses, and pleading
| diatribes.
|
| I'm listed as the email address for _many_ utility bills,
| doctors offices, and more political campaigns than I can
| count.
|
| Comical how many people mess up their own email address.
| kstrauser wrote:
| I just don't get it. A legitimate typo I can see, sure,
| but so many of the things I get looks like someone said
| "email address? I guess I can just pick one!"
| watermelon0 wrote:
| Email should not be considered a secure channel.
|
| 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.
| danenania wrote:
| With password reset, you are also trusting email.
| gepeto42 wrote:
| Even with passkeys or TOTP 2FA, we've decided email is the
| root, for better or for worse (for people with gmail, it's
| likely better than SMS would be on a crappy carrier, but it
| depends on so many factors, including how many hundred apps
| have Gmail read access via OAuth...)
| Jolter wrote:
| If you are storing sensitive information in the system, by
| all means, you should act accordingly and require higher-
| security login than magic links. But if you do, you really
| should not be accepting username+password either. You need to
| at least put some 2FA on there to step up one level of
| security. And not SMS- or email-based 2FA either.
|
| 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.
| flessner wrote:
| Also what's the reasoning behind not wanting to store
| passwords?
|
| 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.
| danenania wrote:
| The UX debate is valid, but magic links (and emailed one-time
| codes) are clearly more secure than password + password
| reset. Control of the email account gets you in either way.
| Passwords are an additional attack vector.
| Kiro wrote:
| In my country even the social security number of people is
| public information.
| gepeto42 wrote:
| To be fair to 404, they're trying to limit the amount of data
| they hold which IS good, but in the end they need to have the
| email address of subscribers.
| lolinder wrote:
| No, kudos to them for looking at a piece of data and asking
| themselves if it's worth storing--more companies should do
| that with more data. It's not that the rest of the data isn't
| valuable to some extent, it's that every piece you have makes
| the blast radius of a leak that much bigger, so why hold
| stuff you don't need?
|
| Planning for a breach doesn't make you more likely to have
| one--if anything it makes you less likely!
| skerit wrote:
| Magic links can be very useful, but for some users the issue is
| in _only_ supporting magic links.
| Helmut10001 wrote:
| Revolut [1] does this and while I like their service overall, I
| hate the login mails. My email box is full of these login mails
| and it feels like abuse of the email system to me. I have all
| kinds of alternatives, Yubikey, TOTP, Password Manager etc. -
| everything would be better than this magic login link.
|
| [1]: https://www.revolut.com
| usr1106 wrote:
| So in case of temporary email delivery problem no banking?
|
| 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.
| jackthemuss wrote:
| It's hard to do right. I made mailslurp for this reason to allow
| end to end testing of magic link flows using disposable email
| accounts.
| justin_ wrote:
| Related thread from September 2024: The "email
| is authentication" pattern
| https://news.ycombinator.com/item?id=41475218
|
| Some users use email flows, such as "magic links", instead of
| bothering with passwords at all.
| Jean-Papoulos wrote:
| Most users do live with a single device. If they have a work
| computer, they also have a work email (the client of which is
| unfortunately probably already opened for other reason when they
| want to login to the site).
|
| 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.
| wpm wrote:
| "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.
| timvisee wrote:
| I do have a good use case for magic links.
|
| 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.
| anotheryou wrote:
| get Mail on different device, copy link and send it to myself via
| some messenger, link preview uses up the login %)
| pwdisswordfishz wrote:
| > 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.
|
| 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.
| hackernewds wrote:
| What is an RSS reader?
| tzs wrote:
| An RSS reader is the client software for reading RSS feeds.
| Here's a description of RSS feeds [1]. Here is a list of some
| readers [2].
|
| [1] https://en.wikipedia.org/wiki/RSS
|
| [2]
| https://en.wikipedia.org/wiki/Comparison_of_feed_aggregators
| pcthrowaway wrote:
| Seriously, this needs to be ended by the harshest penalty of
| law.
|
| Throw every product manager responsible for forcing in-app
| browsers upon their users in jail.
| withinboredom wrote:
| Let me tell you about the time Epic's magic links were delayed
| six hours. I couldn't login to fortnite. It was absolutely
| tragic. /s
| j16sdiz wrote:
| Usability issue aside. ... Using SMTP as the only login factor
| sounds very insecure to me.
| victorbjorklund wrote:
| I really hate magic links. Only time I think they could be
| acceptable is if it is an app where you just log in once or maybe
| once every couple of years.
| buro9 wrote:
| The article doesn't even touch "people enter their email
| incorrectly when registering an account".
|
| 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.
| denismi wrote:
| This happens on my Gmail all the time.
|
| 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.
| gepeto42 wrote:
| You're right, I forgot to even cover that part because I was
| focused on how annoying they are to me as a user, not
| necessarily as a service provider. I also forgot to mention how
| they train people to click on links, how my inbox now consists
| of dozens of emails per day telling me to either click to
| login, or warning me that I logged in.
|
| 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.
| m4tthumphrey wrote:
| Good post. I chose to only implement magic links in a previous
| project and had an issue with users complaining that the (one-
| time) link would always be expired when they clicked. I could not
| reproduce it and just left it. Then this thread appeared and I
| instantly knew the problem: email client previews. Lesson learnt.
| jvanderbot wrote:
| I have a very personal reason to hate magic links:
|
| 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.
| littlestymaar wrote:
| While I agree with most he says, I really don't get why people
| would push for passkeys like this, it's probably the worse system
| in existence in terms of UX (as the more likely to get you
| locked-out of your account) while providing minimal security
| benefits (the account recovery mechanism is the weakest link in
| the chain, and as such it's not any better than magic links). The
| only ones benefiting from passkeys are Google and Apple (and
| app/website owners who can't avoid mismanaging user passwords,
| but they have little stake in this game anyway).
| methou wrote:
| I hate those tragic links, some of them were sent from third
| party and infested with tracking links. Worse, it looks like from
| the site I'm logging in to, but the href is a tracker with
| redirection to the actual link. I see this frequently because my
| dns blocks those trackers.
| openplatypus wrote:
| 404Media article about Magic Links: https://www.404media.co/we-
| dont-want-your-password-3/
|
| Our response to above: https://wideangle.co/blog/passwordless-
| authentication-magic-...
|
| Conclusions:
|
| Magic Links good? Yes.
|
| Magic Links the best? No.
| WaitWaitWha wrote:
| Just a pet peeve with passkeys (and other authN) that presses
| users towards biometrics -
|
| 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.
| gepeto42 wrote:
| What I'd recommend is if you're worried about this (or worried
| about it in certain instances), disable biometrics to unlock
| the device itself. Then, passkeys on it don't really matter
| anymore.
| WaitWaitWha wrote:
| This works if the event, which forces unlock, is expected.
| Often such events are not expected and there are but seconds.
| OKRainbowKid wrote:
| On my android phone, if I hold the power button I get the
| option to "lockdown", which immediately locks the phone and
| disables biometrics for the next unlock, requiring the
| PIN/password.
|
| I assume that would work for the situations you have in
| mind.
| jesseendahl wrote:
| Yup and iPhone has the same feature. Seems like parent
| may not be aware of this.
| OKRainbowKid wrote:
| On my android phone, if I hold the power button I get the
| option to "lockdown", which immediately locks the phone and
| disables biometrics for the next unlock, requiring the
| PIN/password.
|
| I assume that would work for the situations you have in
| mind.
| kdmtctl wrote:
| The event itself is often expected. Nothing happens out of
| the blue. The exact time of the event is unknown. So, extra
| precautions like disabling biometrics before leaving home
| is a normal risk mitigation practice.
| WaitWaitWha wrote:
| I beg to differ to those who write that such events are
| expected, just press a few buttons, disable, or something
| similar.
|
| Imagine you are _not_ in a a relatively "democratic"
| nation.
|
| (0) You are asleep. You phone is on the nightstand. At 4:00
| in the morning, you wake up with a rifle stuck in your
| face.
|
| (1) You are walking down the street, middle of the day.
| Your phone is in you jacket inside pocket. Two burly
| individuals grab each of your hands, tie them and then toss
| you into a van that just pulled up.
|
| (2) You are walking around, let wind on your face and feel
| it in your hair. Your cell phone is in your jilbab or
| burqa, you changed out of. A rock hits your head and you
| black out.
|
| (3) you walk into the public WC/bathroom in the bar, but
| you do not take your phone in with you because it is just
| ... ick. You come back out and the phone is in the hands of
| a local law enforcement agent.
|
| Each one of these have happened in real life. There are
| just a myriad of real scenarios where someone is not in
| reach of their cell phones.
| kdmtctl wrote:
| You have already described prerequisites. It is unwise to
| use biometrics if you are a person of interest in a "not
| so democratic country". And to get a riffle to your face
| they should demolish a door which is commonly steel in a
| "not so democratic country". This is loud and gives
| plenty of time.
|
| Nothing happens out of the blue. People don't get
| searched randomly except some rare places where an iPhone
| is the source of danger itself being a valuable
| possession.
|
| If someone feels that such events could happen it is
| mandatory to do OPSEC. If not, bad for this someone.
| Anyway, a proper torture will reveal the password in a
| "not so democratic country". Which also happens in the
| real life.
| beala wrote:
| On iPhone, you can quickly do this by holding down the lock
| button and either volume button until the shutdown screen
| appears. Once it appears, your phone is now locked and it
| will only accept the PIN (you don't need to actually shut
| down).
| minitoar wrote:
| Alternatively one can press the lock button 5 times
| quickly.
| aftbit wrote:
| On Android, pressing lock 5 times quickly automatically
| dials 911.
| TeMPOraL wrote:
| Thankfully, _it doesn 't_. It _asks you to confirm_ by
| sliding some on-screen control, and _then_ dials 911 /
| 112.
|
| If it dialed immediately, I'd be in jail already, going
| by the amount of times I managed to trigger the "call
| 911?" screen by accident in the last year or so.
| frantathefranta wrote:
| Would you happen to know what the rule is on Yubikeys and the
| like? I assume if it's PIN-protected, it counts as a password
| but what if it's just set up for tap-to-unlock?
| WaitWaitWha wrote:
| Not a lawyer and do not know your jurisdiction.
|
| I extrapolated this as anything that is in the mind (PIN,
| password, some secret) cannot be demanded, while anything
| outside of the mind, biometrics, geolocation, physical object
| (key) can.
|
| Again, I am just a hairless monkey smashing rocks together.
| Consult experts.
| HWR_14 wrote:
| In the US this is a pretty good nationwide summary.
| mminer237 wrote:
| Of course they can use that. The Fifth Amendment protects the
| right to not testify against yourself. You can keep silent.
| That's it about self-incrimination. The government can seize
| any physical object and do essentially anything it wants with
| it with a warrant. They can physically decap a TPM and read
| the security key if they really want to.
| hazmazlaz wrote:
| I agree, and I wish there was an option to always require both
| a passcode/password AND biometrics in iOS and MacOS. While it
| would become a hassle having to do it every time, it would at
| least guarantee that one could retain their 5th Amendment
| rights if the device were seized.
| circuit10 wrote:
| Having no backup to biometrics could lock you out permanently
| if it stops recognising you for some reason, so it would need
| to accept just the password, and at that point you can just
| turn biometrics off entirely
| philipwhiuk wrote:
| > There is similar legal stance in Canada, UK, Australia,
| India, Germany, and Brazil to name a few.
|
| 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.
| hiatus wrote:
| > In theory once you got out you could be re-served with the
| notice and face another 2-5 years. Rinse and repeat.
|
| Is there no concept of double-jeopardy in UK jurisprudence?
| jetpackjoe wrote:
| Not from the UK and not a lawyer, but if a new warrant was
| served, then not providing the password would be a new
| offense and double jeopardy would not apply
| BoxOfRain wrote:
| What happens in the case of plausibly-deniable keys? Say
| someone has an encrypted drive with a hidden volume, one key
| decrypts decoy files and one decrypts the true files. If the
| person gives up the key to the decoy files, is the onus on
| the prosecution to prove additional keys exist or on the
| defence to prove they don't?
| philipwhiuk wrote:
| Not a lawyer but I expect it would be on prosecution to
| convince a jury that they had failed to make "a disclosure
| of any key to the protected information that is in his
| possession"
|
| as per RIPA 2000 Section 50, 2 a)
|
| To do this, they'd likely need some evidence to persuade
| the jury, _beyond reasonable doubt_ , that the encryption
| system had such a feature.
| moffkalast wrote:
| The UK always surprises with how close their reality is to V
| for Vendetta.
| xerox13ster wrote:
| There's no doublespeak there. To regulate just means to make
| regular. If they make the reprehensible the regular way of
| doing things then they've still done the job they're
| nominally supposed to do. They could say all investigations
| have broad sweeping powers going forward and they would still
| be regulating investigatory powers.
|
| We want regulation to be for the benefit of all so we attach
| an emotional meaning to it but nothing about the word says it
| has to be beneficial.
| SkyBelow wrote:
| >but in most cases that's not going to be believed by a jury.
|
| Is there are least some argument of reasonability? I have an
| old Runescape account I would love to be able to get back
| into, but I don't even remember the email it was tied to,
| much less the password. I was a kid back then so even the
| card that paid for membership was my parents. Is there some
| expectation that the prosecutor has to show the account was
| accessed in the last X years, or is this effectively a
| backdoor to keep someone in prison indefinitely?
| injidup wrote:
| Biometrics then need a mix of non-testimonal and testimonial
| input. ie it only unlocks when it sees it is your face and your
| face blowing a rasberry. Can you be compelled to blow a
| raspberry?
| HWR_14 wrote:
| In the US, the answer would be yes you can be compelled to
| blow a raspberry.
| brightball wrote:
| I've always thought of passkeys as a good 2nd factor in
| conjunction with a password. Similar to the way you'd use a
| Yubikey or anything else with FIDO2/WebAuthn.
|
| Seeing passkeys as a dedicated login on their own is...strange.
| For all of the reasons that you indicate.
| joncrocks wrote:
| > There is similar legal stance in Canada, UK, Australia,
| India, Germany, and Brazil to name a few.
|
| 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.
|
| https://www.legislation.gov.uk/ukpga/2000/23/section/53
| joering2 wrote:
| I wonder what would happened if you willingly keep providing
| a wrong password. The possibility of your device
| malfunctioning IS and always will be > 0.
|
| Can the judge really throw you, and re-throw you multiple
| times to jail because the password you keep providing did not
| work?
| jesseendahl wrote:
| You can't unlock your iPhone with biometrics at first boot, and
| holding down the two side buttons will make it so your phone
| immediately disables biometric unlock, and instead requires
| your passcode for the next unlock.
|
| 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.
| hirvi74 wrote:
| You can also quickly press the lock button 5 times and then
| your iPhone won't unlock with Face ID until a passcode is
| entered.
| latexr wrote:
| > holding down the two side buttons will make it so your
| phone immediately disables biometric unlock
|
| Also pressing the lock button five times in a row.
| WaitWaitWha wrote:
| Thank you for the correction on the UK laws.
| Kwpolska wrote:
| I agree with magic links being bad, but passkeys aren't the right
| solution for multiple devices either, because it requires sharing
| the account or password manager they're saved in between devices,
| and I'd rather keep my private accounts and passwords away from
| work devices. With plain old passwords, I can open my password
| manager on a trusted device and type the password into an
| untrusted one.
| cratermoon wrote:
| From a .zip domain. Irony.
| gepeto42 wrote:
| Thanks for recognizing it, it was absolutely by design!
| shortformblog wrote:
| Feel like the solution to this problem is probably to offer an
| app that turns magic links into notifications. As well as to
| probably untether the magic link from the cookie in the browser,
| so that you are not required to hit the magic link in the same
| browser that you called the link from.
| albert_e wrote:
| Virtually all online streaming services in India now use a OTP
| sent to registered mobile number as the way to login to the app
| on any device.
|
| 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.
| chrisweekly wrote:
| I hate magic links. Being forced to switch applications to wait
| and hope an email will eventually arrive is a fundamentally bad
| experience.
___________________________________________________________________
(page generated 2025-01-08 23:01 UTC)