[HN Gopher] Are Magic Links Outdated?
___________________________________________________________________
Are Magic Links Outdated?
Author : mffap
Score : 121 points
Date : 2022-07-13 09:33 UTC (13 hours ago)
(HTM) web link (zitadel.com)
(TXT) w3m dump (zitadel.com)
| clement_b wrote:
| I hate them. Force me to go to my mailbox while I have a good
| password manager and just want to use that instead. I get the
| idea, but this should be an alternative, not a default. Also
| sends loads of single use emails that will remain for ever in
| users mailboxes.
| ajvs wrote:
| Yeah this is a huge turn off when using Notion especially.
| joe_fishfish wrote:
| If it's magic link or multi-factor authentication, I know which
| one I prefer. Try explaining to an MFA-loving service that your
| phone is out of action while it's being repaired.
| [deleted]
| dymk wrote:
| 1password and Lastpass both manage MFA codes and work cross-
| device. If your phone is your only way to get into MFA
| protected accounts, you're doing it wrong. What happens if
| you can't repair your phone?
| amacneil wrote:
| If you're storing your "multi-factor" authentication codes
| in the same place (ahem, "factor") as your password, you're
| doing it wrong.
| phphphphp wrote:
| I used to think this but I don't agree any more. A factor
| is a factor: your service password + your password
| manager password = 2 factors. Yes, if someone compromises
| your password manager then you're in a bad position but
| that's not what service-level multi-factor authentication
| protects against.
| amacneil wrote:
| > that's not what service-level multi-factor
| authentication protects against
|
| I don't understand your point. This is exactly what
| multi-factor authentication protects against if you don't
| store your MFA codes in your password manager.
| waihtis wrote:
| A password may be compromised via other routes than just
| through a password manager hijack, which is probably far
| down the probability scale of all of the possible ways to
| do so
| az_reth wrote:
| Except you're still protected whenever a website gets
| breached and all their passwords are dumped. Sure it's
| still a single point of failure but at least it's with a
| company dedicated to password security.
| zhfliz wrote:
| how?
|
| standard TOTP MFA (which is what most password managers
| would offer in terms of MFA) uses a shared secret, which
| you would just dump from the same database you get the
| dumped passwords from.
|
| unless you use asymmetric crypto e.g. in webauthn this
| doesn't benefit you at all.
| acdha wrote:
| This is why you need to start with a threat model. For
| example, if your concern is password reuse or weak
| passwords simply using a password manager to have unique
| per-site passwords solves that problem for almost anyone.
|
| If your concern is phishing, storing the code on the
| device (especially on a modern phone) is really moot
| since all forms of one-time codes are vulnerable -- you
| should be working on how to switch to FIDO2/WebAuthn.
|
| If your concern is a temporary exploit of the user's
| browser, using an out-of-process password manager is
| likely to prevent exfiltration of the entire password
| list but in practice this is already probably a disaster
| scenario unless you're using sites which require a strong
| FIDO2 challenge for sensitive operations since the
| attacker already has your cookies for everything you use
| regularly.
| acdha wrote:
| Here's what that's like with WebAuthn:
|
| 1. Use my Yubikey with a different phone via NFC or a
| different computer using USB 2. Login using my other iPhone
| or Mac because the WebAuthn passkey is synced via iCloud
| (this is in the progress of coming to Chrome & Windows)
|
| The nice thing is that all of those are more convenient than
| using email in addition to being more secure.
| Macha wrote:
| Does your email not use MFA? So the choice not between magic
| links or MFA, it's between magic links and MFA or just MFA?
| movedx wrote:
| Microsoft Authenticator - syncs your codes to the Cloud so
| you can pull them elsewhere (which your phone is out of
| action.)
| lostmsu wrote:
| Doesn't that defeat the purpose to a degree?
| gorjusborg wrote:
| I use MS authenticator, and had the same thought.
|
| I came to grips with the idea that I really don't care
| all that much if a single factor has risks as long as the
| other factors have orthogonal lists.
| rakoo wrote:
| There needs to be a way to sync everywhere _except_ the
| device you 're connecting from
| WorldMaker wrote:
| Microsoft thinks it is fine for most user's threat models
| because these use two stacked layers of encryption: your
| Microsoft account and either Apple's cloud backup
| encryptions or Google's. To move these codes between
| devices you have to login in both your Microsoft account
| and also your Apple or Google account in quick
| succession. I know on Apple devices it works in the same
| (iCloud) backup layer that disables other device keys so
| doing this on a new device will "break" access on the
| previous device (only one device at a time has access).
| (I'm not sure about Google's ecosystem.) You can't easily
| switch ecosystems with this. Microsoft seems to think it
| unlikely enough that both your Microsoft account and your
| device ecosystem account will be compromised at the same
| time that there is enough security in this depth.
| contravariant wrote:
| Last time I tried that I still had to reactivate all the
| accounts.
|
| Storing them in Bitwarden is more convenient by far, but
| storing TOTP is a paid feature.
| postalrat wrote:
| They should be the default because they are more secure than a
| password plus a email password reset.
| codingdave wrote:
| I'm mildly surprised that one of your complaints is that these
| fill your email. It seems simple enough to delete them?
| sp332 wrote:
| Once I click the link, it takes me away from my email inbox.
| That means I have to go back and clean them up later. That's
| extra work for something that should be ephemeral. No thanks.
|
| I can't quite put my finger on why it's different from having
| SMS 2FA codes in my Signal inbox, but it _feels_ like more
| clutter.
| IggleSniggle wrote:
| SMS clutter is worse for me. Harder to delete in bulk.
| sn0wleppard wrote:
| My SMS inbox is almost entirely login codes and other
| automated stuff so I'm quite happy just to leave it all
| there
| corrral wrote:
| Ditto my non-work email, really. Humans are in chat apps.
| Text, email, phone--overrun by transactional messages
| from computers, and spam.
| 8organicbits wrote:
| Gmail app buries delete in a couple places in favor of
| archive. I routinely find I need to open a message to delete
| it, although the notification has an "archive" quick action
| button. Gmail made delete extra steps.
|
| I have virtually unlimited space for email, but they still
| show up in searches, and I'm certain I'll never want to look
| at them again.
| twistedpair wrote:
| Just hit "#". That wasn't buried very deep.
| tebbers wrote:
| The problem is that most users still don't have password
| managers and actually magic links are more secure for them
| because they're not vulnerable to password stuffing.
| mmikeff wrote:
| I also hate them, my email is slow and mobile internet is
| almost non-existent at my house, so now I am waiting for an
| email to arrive in my inbox before I can login, or I am waving
| my phone around trying to get reception to receive a code.
|
| I'm sure I am not the only one with those issues. As said
| above, this would all be fine if Magic Link was an option
| rather than the only way to sign in.
| notnotjake wrote:
| It would be really interesting if 1Password or another could
| have an "email client" that just looks for these codes/links
| the same way iOS/macOS look for messages 2FA codes
| Spooky23 wrote:
| Magic links are great for low trust model applications where the
| user is required to use the app but is a limited stakeholder.
|
| Case in point: SportSignUp, which is a platform/app that allows
| you to manage your little league/basketball/soccer team, etc.
|
| The use cases for parents are basically figuring out where
| games/practices are, telling coaches that they will be/not be
| there, checking scores, and signing up to volunteer for various
| tasks.
|
| Life is complex. You have non-custodial parents, nannys, older
| siblings, etc helping out. The easiest path is to send the magic
| link to the family text group.
| timwis wrote:
| If you're concerned about the security aspect of this, keep in
| mind that _most_ web applications have this feature, but instead
| of calling it a magic link and for signing in, it's called
| "forgot password." It generates a short-lived code and emails the
| user a link that lets them access their account.
|
| There are, of course, challenges with this being the _only_ (or
| default) way to sign in, but the security concerns with it (e.g.
| weak email password) probably aren't new!
| astura wrote:
| >Though no official record of the first use of this method seems
| to exist, research suggests that their concept dates to the early
| 2010s.
|
| Early 2010s? Craigslist has been doing this since the 90s.
| ajsnigrutin wrote:
| Another account to lose, when google bans you, because your kid
| liked something on youtube on a family account.
| dangus wrote:
| They're yet another way for logging in to suck for people who use
| a password manager.
|
| Another example of this is consumer apps that insist that you
| should login with your phone number and make you click an extra
| button to change to the email login option.
| jarsbe wrote:
| It depends. I used magic links for a system where the user would
| log in every 6-12 months. It didn't make sense to force them to
| make a password.
| kevincox wrote:
| Why not? Most browsers are slowing pushing password managers on
| users and the experience is lovely.
|
| Register:
|
| 1. I click the password field.
|
| 2. I click "use autogenerated password"
|
| 3. Sign up.
|
| For login:
|
| 1. Click "login".
|
| The magic link experience is comparatively awful:
|
| 1. My email address never auto-fills so I need to click the
| field and select the completion suggestion. This is even worse
| if I am using a per-site email address.
|
| 2. Click login.
|
| 3. Go to my email.
|
| 4. Most often wait a few seconds.
|
| 5. Click the link. (add extra steps if I want to open in a
| private window or container tabs, or tons of pain for a
| different device)
|
| 6. Delete the email.
|
| 7. Find the new tab.
|
| 8. Maybe drag it to the right location in the tab bar or the
| right window.
|
| And that is assuming that my email providers likes your email
| and it doesn't get greylisted, put in spam or even outright
| rejected.
| jarsbe wrote:
| This is a perfect HN user response. You are a power user;
| "This is even worse if I am using a per-site email address" -
| no one does this. The majority of people are normal.
| kevincox wrote:
| Sure, but that barely changes the equation. Just a minor
| improvement over the power-user case.
| joshstrange wrote:
| Need some more straw for your strawman there? I can't take
| this comment seriously when you misrepresent both approaches
| so badly.
|
| There are legitimate downsides to magic links but this isn't
| realistic. Do you not have to enter email on register? Where
| is the email confirm step for password signup? Finding the
| tab you just opened and dragging it... really? All of that
| happens on first signup as well. And the comment you are
| replying to is talking about a 1-2 times a year process, is a
| magic link really so difficult to use twice a year?
| kevincox wrote:
| > Do you not have to enter email on register?
|
| Yes, I have omitted this from both workflows.
|
| > Where is the email confirm step for password signup?
|
| Good point, most websites will want to confirm the email
| address. I didn't include that.
|
| > Finding the tab you just opened and dragging it...
| really?
|
| Yes, I like to keep my tabs organized. I'm not even a tree-
| sytle-tabs user but at least want to get the right window.
| The point is that magic links disrupt my in-browser
| workflow with switching between apps and opening links in
| new tabs.
|
| > is a magic link really so difficult to use twice a year?
|
| No, but it is still more difficult than a password multiple
| times a year. Neither of these have a yearly cost so it
| doesn't really matter how often you do them. I wouldn't use
| "only twice a year" to justify that people can come to our
| office in person to authenticate over a magic link.
| joshstrange wrote:
| > > Do you not have to enter email on register?
|
| > Yes, I have omitted this from both workflows.
|
| You specifically complained about having to enter your
| email on the magic link flow:
|
| > 1. My email address never auto-fills so I need to click
| the field and select the completion suggestion. This is
| even worse if I am using a per-site email address.
|
| > > is a magic link really so difficult to use twice a
| year?
|
| > No, but it is still more difficult than a password
| multiple times a year. Neither of these have a yearly
| cost so it doesn't really matter how often you do them. I
| wouldn't use "only twice a year" to justify that people
| can come to our office in person to authenticate over a
| magic link.
|
| Yearly costs to who? The user? I guess there isn't really
| a cost to them other than storing/keeping the password
| but there is absolutely a cost to the developer and I'm
| not talking about the cost of storing a hashed/salted
| password in the DB itself. There is a cost to build and
| maintain a password-based system. It means implementing
| and maintaining a number of things like your salt,
| password complexity requirements, password reset flow,
| and more like you going to use something like
| HaveIBeenPwned's hash list to make sure people aren't
| using known passwords?
|
| Passwords are not zero-cost and have ongoing concerns.
| I'm not saying magic links are always or even often the
| best choice, just that they do have a perfectly valid
| use-case.
| DocTomoe wrote:
| > but there is absolutely a cost to the developer and I'm
| not talking about the cost of storing a hashed/salted
| password in the DB itself. There is a cost to build and
| maintain a password-based system.
|
| Seriously ... if today's developers are unable or
| unwilling to learn about basic hashing/salting and
| database storage/value comparison, and consider such
| concepts 'costly' ... we may have passed the zenith of
| technological advancement, and are in a 'downfall of the
| Roman Empire' phase. Have some pride in your work.
|
| > It means implementing and maintaining a number of
| things like your salt, password complexity requirements,
| password reset flow, and more like you going to use
| something like HaveIBeenPwned's hash list to make sure
| people aren't using known passwords?
|
| Do you reinvent the wheel whenever you need to drive
| somewhere? these things mostly are already baked into
| most frameworks, and if they are not, most developers
| build something like this once, and reuse.
|
| > [Magic Links] they do have a perfectly valid use-case.
|
| Annoying customers and forcing them out of your business
| into the willing hands of your competition?
| joshstrange wrote:
| It's amazing how you, knowing nothing about my stack/use-
| case can speak with such authority. Going as far as to
| assume that we must be in a "'downfall of the Roman
| Empire' phase" because I see value in magic links and
| because I don't want to implement password support,
| again, in a product you know nothing about.
|
| I have a very good reason for picking magic links, also
| the codebase for my project does not ruse a framework
| (there exist no good ones in the space I'm in) but
| instead of being curious you decided to be condescending.
| Cool.
| kevincox wrote:
| > You specifically complained about having to enter your
| email on the magic link flow:
|
| For logins yes:
|
| > My email address never auto-fills so I need to click
| the field and select the completion suggestion. This is
| even worse if I am using a per-site email address.
|
| My email always autofills for regular login forms. Maybe
| this is a bug in my browser but either way it is an
| inconvenience that I face.
|
| > implementing and maintaining a number of things like
| your salt, password complexity requirements, password
| reset flow
|
| If you are using any halfway popular language there is a
| library that does all of this for you. In fact it is
| probably easier to use a pre-packaged library than for
| magic links, but I'm sure those libraries could appear if
| magic links become more popular.
| mffap wrote:
| If you'd take a passwordless login with FIDO2 (now promoted
| "Passkeys" by Apple and Google) it would mainly require to
| use FaceID / Windows Hello / Fingerprint / PIN ... or
| whatever your devices deem necessary. Could be used on any
| and cross-device.
| kevincox wrote:
| This may be a good future. But it seems like this isn't
| available to most people on most browsers yes. Especially
| if you want to sync across ecosystems.
|
| I like how tangible passwords are. Even with a password
| manager I can write them on a piece of paper, store then in
| a vault and enter them into a new computer. My grandmother
| understands this process.
|
| The key-based systems are basically magic. Magic that works
| great as long as you are inside the defined parameters on
| supported devices. I think it will be years after the
| "first baked release" before we see relatively user
| friendly manual backup and restore. Something this is
| second nature in most password managers.
| mffap wrote:
| I'm glad that your grandmother uses a password manager.
| We actually had a lot of feedback from teens and children
| and the concept of MFA/2FA seems to be hard to understand
| for less technical people. We were surprised by the
| actual understanding after some user research.
|
| Yes, availability on all browsers and devices is not yet
| up to 100%. I hope to see a fast adoption, but agree that
| it could actually take some time. I use Passkeys on a
| daily basis for the last ~1.5 years wherever possible and
| won't go back anytime soon :)
| withinboredom wrote:
| Chrome supports a webauthn solution built-in if you don't
| have windows/platform authentication support. I think
| Firefox does too, and probably even Safari on really old
| machines. If you are targeting semi-modern browsers and
| devices made in the last 5-10 years, you should be fine.
| mffap wrote:
| Yes. To my knowledge WebAuthN works great on Chrome,
| Safari, Firefox (most times) on MacOS/iOS and Windows
| devices. Linux is still an issue unfortunately as it
| seems.
| aaaaaaaaata wrote:
| Opposite of what I'd expect.
| DocTomoe wrote:
| > Why not? Most browsers are slowing pushing password
| managers on users and the experience is lovely.
|
| Most browsers in 1996 had "save this password"
| functionality... it's not a new thing.
| kevincox wrote:
| I think it has gotten more aggressive with popups to use a
| generated password appearing any time you focus a password
| field.
| sborsje wrote:
| There's a near-infinite amount of not-so-small gotchas when
| implementing magic links:
|
| - If magic links are the only way to sign in, authentication
| success rate is now directly tied to your email deliverability
| rate.
|
| - Single-use tokens (immediately expiring after clicking) can be
| followed by spam filters, and thus immediately become invalid for
| the actual user trying to sign in.
|
| - MTAs using greylisting can cause unexpected delays in email
| delivery.
|
| - If a session audit trail is implemented, malware scanners
| following links might cause sessions from unexpected locations
| showing up.
|
| etc.
| matsemann wrote:
| Also, they only work if I have an e-mail client on the device
| I'm trying to log in from. Otherwise having to transfer this
| link becomes a burden.
|
| Additionally, even if I do have the e-mail on my device,
| clicking the link on mobile often opens it up inside some
| alternative web-view. Thus the session is tied to my e-mail
| client, not my actual browser.
| pritambaral wrote:
| This wouldn't be a problem if the Magic Link was used only to
| authenticate your original login session, and not to start a
| new session wherever it was opened. Like I mention here:
| https://news.ycombinator.com/item?id=32081608
| timwis wrote:
| Great points! The deliverability (and delay) issue is the one
| I've found most challenging. For the others, here are some
| mitigations I've come across:
|
| - instead of single use tokens, set them to expire within 60
| mins
|
| - to prevent spam/malware checkers signing in when following
| the links, have the magic link take you to a page with a sign
| in button to 'complete' the sign in process. And, optionally,
| add some JS that clicks it for you on page load. This is the
| same approach used for unsubscribe links.
| kazinator wrote:
| The magic link is basically using "forgot my password" e-mail
| recovery flow to just friggin' log in.
|
| If you've served the user a link which takes them to a session
| where they can change their password, that session must be
| authenticated, by definition; you would not allow an
| unauthenticated visitor to change an account password!
|
| And so, if that password change session is authenticated, then
| just treat _that_ as fully fledged session. Don 't force the user
| to go back to the login screen and use their new password.
|
| The next logical step after not forcing the user use their newly
| minted password is to just remind the user their forgotten
| password is still in effect, and that they can change it in their
| account profile settings.
|
| From there to "magic link" authentication is just some minor UI
| tweaking.
|
| I've always thought that asking the user to log in with a newly
| set password was an incredibly poor and unnecessary user
| experience, which just amounted to punishing the user for having
| forgotten their password and to train the user to believe that
| password recovery is inconvenient and should be avoided.
| postalrat wrote:
| Many of my accounts I use the password reset feature then enter
| a long and secure password and never store the password. Next
| time I log in I reset my password again.
| kazinator wrote:
| Thus, if that password recovery continues to be a painful,
| multi-step process, rather than streamlined into an easy
| alternative login mechanism, those providers are basically
| not attuned to the way users are accessing the system.
| appleflaxen wrote:
| This is just an advert by a competitor.
| Kiro wrote:
| I use Magic Links because I don't trust the security of my hobby
| app and don't want to deal with storing credentials.
|
| What I would like is a service like Firebase or OAuth but that I
| communicate with through my backend. So a user sends in
| username/password to my server and I relay that to a service
| which returns a token or something. I've had too many issues with
| the Firebase front-end JS that I no longer trust it to handle the
| whole flow.
|
| Anyone know a service like that? Basically just an API that is
| specialized in auth/security that I can outsource the data to
| without having to store it myself.
| BoorishBears wrote:
| Auth0 via Universal Login essentially fixes the crappy frontend
| JS problem, JS-free login page driven by an HTML template that
| you redirect to and get back a code
|
| There's also "dbconnections" endpoints where you can post raw
| sign-up data though if you're looking strictly for the backend
| piece
| zonotope wrote:
| I haven't used it in a while, but it sounds like Auth0
| [https://auth0.com/] is what you're looking for.
| parentheses wrote:
| the problem with using this technique alone is it's basically 1FA
| all over again. hacked email means everything is hacked.
| excluding the need to remember a password, how are magic links an
| improvement?
| apeace wrote:
| Anyone have advice for creating easy-to-use-yet-secure login
| solutions for users who are less tech-literate?
|
| My company is an ISP, and most of our customers are not very
| "good" at using technology. Any yet, they do sometimes want to
| log into our dashboard for one reason or another, and it tends to
| be a lot of trouble.
|
| We've found that:
|
| - _Many_ people do not have an email. Some people don 't have a
| phone number. Many people have only one or the other, but not
| both.
|
| - People typo their emails... a LOT. I initially had some very
| simple validation for email addresses, until I started getting
| droves of emails that were one character off. I'm at this very
| moment working on a feature to alert users if they type
| "gmail.co", "gmail.con" or "gnail.com", which are all very common
| (and two of which are completely valid domain names by the way!).
|
| - Some people get confused by "creating a new account" or dealing
| with multiple accounts in general. They'll say "my email login
| didn't work." Well, to me it's obvious that they have a different
| password for different accounts, but to them it's not.
|
| - Building on that, they are not great at password resets. The
| "send a password reset to email" thing is confusing to them,
| because from their perspective their email _is_ the account. Am I
| resetting my email password?? They don 't like it so they don't
| want to do it.
|
| - Since we are an ISP providing customers with WiFi, there is
| also confusion between the WiFi password and the dashboard
| password. I've had people successfully reset their dashboard
| password, expecting it to also set their WiFi password.
|
| - Literacy can also be less than ideal. I once reset a customer's
| WiFi password over the phone, and the new password contained an
| exclamation point. She didn't know what an exclamation point was.
| I got her to do SHIFT-1 eventually, but it took a while. (I found
| out later that nobody else sees an exclamation point as an
| "upside-down i", which is what I've always seen it as. The proper
| way to describe it to someone who doesn't know is "line with a
| dot underneath".) Now my password generator only uses A-Za-z0-9
| (but not 0 or O).
|
| So, I have been learning the hard way that not every person in
| the world is an avid Hacker News reader who knows what accounts
| and password hashes are and how everything works. And yet, these
| people deserve to be empowered by technology just like the rest
| of us.
|
| The thing is, many of these folks _are able to use software just
| fine, it 's just that they have trouble getting logged in_. It
| really is the logging in that trips everything up.
|
| So I've been thinking lately that I want to fix this for my
| company, but I'm unsure what to try.
|
| I had the thought of trying Webauthn, but that seems unusable for
| me as per this comment I wrote a few weeks ago[0]. If I could
| solve the problem in that comment, I think a lot of my customers
| would use "Login with TouchID", "Login with FaceID", etc.
|
| Anyway, my point is that no, I do not think magic links are
| outdated. We use a lot of magic links. Need to update your credit
| card? We'll text you a link. Want to reschedule your install?
| We'll text you a link. This is the best way we've found to
| actually get our software into the users' hands.
|
| [0] https://news.ycombinator.com/item?id=31850471
| revskill wrote:
| I think yes, because people hate magic ? Change it to Simple link
| might work.
| mooreds wrote:
| Another issue that I don't see covered here is that some email
| clients (looking at you, Outlook) pre-fetch links to see if they
| are security risks. If you build a magic link system which
| handles plain old GETs, the one time code gets used up before the
| user can actually log in.
|
| We ran into this at FusionAuth and had to do implement some
| workarounds, documented here:
| https://github.com/FusionAuth/fusionauth-issues/issues/629#i...
|
| Edit: https://news.ycombinator.com/item?id=32081192 mentions this
| and some other issues.
| ethotool wrote:
| Somewhat related:
|
| https://news.ycombinator.com/item?id=31892299
|
| This is very, very concerning and makes "magic links" a security
| threat to any platform that utilizes them.
| pjc50 wrote:
| "Opening an email and clicking on a link" is one of the most
| risky things you can do with your computer; it's a critical stage
| in many successful security breaches. Why would you train people
| to do it?
| bamboozled wrote:
| Are you serious?
|
| I'm signing into a website, I get an email when I'm about to
| sign-in from said domain, I click the link in the email, I'm
| signed in.
|
| What is this training me to do exactly?
| roelschroeven wrote:
| Some third party detects you're trying to sign into a
| website. The third party sends you an email, that email
| happens to arrive first. You click the link in the email. Now
| you're on a website that looks like the one you expected (if
| the third party has done its homework) but is completely in
| control by the third party.
|
| Apparently things like this do happen, for example when
| people are buying or selling things on the internet. They get
| redirected to a pay processing site that looks just like the
| one from their bank, but steals their money and/or identity
| instead.
| pritambaral wrote:
| > Now you're on a website that looks like the one you
| expected (if the third party has done its homework) but is
| completely in control by the third party.
|
| A simpler attack would be to for the third-party attempt a
| login on their end into your account, and if you happen to
| click on the Magic Link generated by their login attempt,
| you wouldn't be signing yourself in, but them.
| rambambram wrote:
| > Some third party detects you're trying to sign into a
| website.
|
| And this third party can find out how, exactly?
| daveoc64 wrote:
| I'm not sure what actual security risk you're talking about
| here.
|
| I click the magic link, expecting it to sign me in, but
| instead it takes me to a fake copy of the website which
| then asks (again) for login details?
| pritambaral wrote:
| > but instead it takes me to a fake copy of the website
| ...
|
| This is fine, but ...
|
| > ... which then asks (again) for login details?
|
| This is where the trick lies. The third-party copy
| doesn't have to ask you for login details. As your parent
| states: They get redirected to a pay processing site that
| looks just like the one from their bank, but steals their
| money and/or identity instead.
|
| The fake site doesn't have to show you details of your
| account. It has to look just similar enough that enough
| people will think it's a legit payment site and submit
| their payment details.
|
| ----
|
| There's also a simpler, alternative attack I mention in a
| sibling comment:
| https://news.ycombinator.com/item?id=32081724
| OJFord wrote:
| Yes, a lot of people will fall for that.
| robrobrobrob wrote:
| MagicLinks are a mobile nightmare. Mobile email clients use their
| own browser and cookie jar which consume the session cookie
| you're trying to put into the user's main browser. This results
| in users 'never staying signed in' and a lot of frustration.
|
| Sending a one-time code via email fixes this, and is in practice
| about as easy to use as a link on desktop.
|
| In our app (Loomio) we default to magic/codes, but let users use
| passwords if they prefer.
| amacneil wrote:
| They don't need to be - this is a limitation of how the site
| has implemented magic links. When implemented best, clicking
| the magic link in your email should simply confirm the
| authentication, and your _original_ browser window/tab should
| be signed in.
|
| That way, you can be signing in on a desktop browser, click the
| email link on your phone (or a different browser sandbox), and
| the desktop window will be signed in.
| cameronh90 wrote:
| How I handle this is as follows, within a B2B context. The
| email sent to the user contains both a magic link and a code.
|
| If the user clicks the magic link from the same device that
| they initiated the login from, it just opens straight into the
| app.
|
| If the user clicks the magic link from a different device, it
| confirms the token and then the browser waiting on the original
| device logs in. It uses a generic browser/server messaging
| library to achieve this, based on whichever of HTTP SSE,
| WebSockets and polling is available.
|
| If the user can't do either of these for whatever reason, such
| as email virus scanning or whatever, the bottom of the email
| also contains a code which can be entered onto the waiting
| login form, along with some information about never giving that
| code out to anyone else on the phone and checking the URL.
|
| The magic link also has an interstitial page with an automatic
| POST form to deal with browsers and other things pre-opening
| links. There are also various points along the way that it
| attempts to check for phishing and perform additional
| interventions, such as if the magic link is clicked from a
| different country to the login request, or if the request is
| coming from a suspicious location, etc.
|
| After all this is complete, it then does 2FA using SMS. The
| magic link login is only needed the first time you log in on a
| given browser as it saves a persistent cookie, but the SMS 2FA
| is needed every time. We don't support persistent sessions due
| to legal requirements.
|
| We are also working on adding webauthn authentication, but
| early testing suggests most users find it very confusing.
| Mobile devices tend to handle it acceptably, but Windows'
| implementation in particular is currently very user hostile and
| often users worry they are being hacked. It also doesn't
| replace the email/SMS-OTP flow, because if the user is logging
| in from a new device, we still need a way to validate that it's
| them before they can subsequently authenticate with webauthn.
| We also support SAML SSO.
|
| Most users are not interested whatsoever in carrying around a
| Yubikey. Even just using SMS-OTP got a lot of push back for
| being inconvenient. I think FIDO2 will work better for users
| when there's a good way of automatically synchronising their
| keys across all of their devices in a vendor-neutral.
| dijonman2 wrote:
| It's just like anti-CSRF tokens, lots of edge cases and it's
| hard to get right.
|
| I don't have a pw manager on my mobile device nor do I want
| one, getting a 35+ char into an input field on my phone is a
| PITA.
| cranekam wrote:
| Does a password manager and browser extension not fix this? I
| use 1password on iOS and almost never have to copy and paste
| or (worse) type a password in. I just FaceID then pick the
| credentials I want to use to log in and the extension fills
| in the relevant form fields.
| acdha wrote:
| > It's just like anti-CSRF tokens, lots of edge cases and
| it's hard to get right.
|
| Do you have an example of the problems you've encountered?
| This is normally a turn-on-and-forget setting which is only
| slightly harder if you're using JavaScript to submit forms.
|
| > I don't have a pw manager on my mobile device nor do I want
| one, getting a 35+ char into an input field on my phone is a
| PITA.
|
| What's your threat model for using long passwords but not
| using a password manager? I can understand why you might not
| want to store it on a cloud service even if it is encrypted
| but local storage is going to be more secure than entering it
| by hand if for no reason other than that it's harder to
| shoulder surf and harder to phish.
| hardware2win wrote:
| Whats so hard about anti csrf tokens?
| bsid wrote:
| At Clerk, (https://clerk.dev, auth SaaS) we did a ton of work
| to get magic links to play nice with multiple devices, it's
| certainly a pain, and there's tradeoffs.
|
| The crux of it is, do you sign in the "originating" device
| (where the magic link was sent from), or the "consuming" device
| (where it was clicked).
|
| Because it's veryyy common for people to be on a website on
| their computer, then click the link on their phone, but still
| want to be logged into their computer. We opted for the
| "originating" device. But this has security concerns.
|
| (you also need to worry about multiple tabs on the same
| browser, but cookies make this easy to deal with)
|
| But, what if an attacker just sends a link to loads of email
| addresses, and one of the receivers clicks on it by accident?
| Their account now has been taken-over.
|
| So, this needs to be combined with the notion of "trusted
| devices", and of course, not breaking what the user expects.
| All in all, a TON of work to get some marginal gains in some
| sectors, mainly B2C. IMO, B2B should always have passwords as
| an option. 1Pass is too widely used to ignore.
| inopinatus wrote:
| Never do this. Automated email scanners may fetch the URL.
| For example, Hotmail's mail delivery process is notorious for
| triggering magic links.
| nly wrote:
| You can defend against this a little bit by having the
| magic link load a page with a button (which submits a POST
| action) that you have to click.
| [deleted]
| kaichanvong wrote:
| yeah on Discord this is almost magic.
| Lorin wrote:
| I really like the QR code system they implemented, pretty
| handy
| wahnfrieden wrote:
| one time code is far, far easier when apple is able to
| autocomplete it
| mooreds wrote:
| Lots of issues with magic links. And yet, and yet. For a
| certain class of accounts, I'm okay deferring to my email
| inbox.
|
| From a security perspective as a user, it's no different than
| deferring to a social provider like Google, but has the benefit
| in that it gives a user more control over the third party they
| choose to delegate control to.
|
| You allow username/password access and that's great too. I'm a
| fan of giving users options, but I don't know if anyone has
| done studies and found that a single login option actually is
| better for conversion. I'd be interested in seeing some numbers
| around that.
|
| I wouldn't recommend a magic link for high value accounts, but
| I have pretty easy access to my mailbox, from everywhere (in
| contrast to my password manager, which is cumbersome to use
| from different accounts). I can also forward the email with the
| link to any device where I have email.
|
| If it is a low-value account that I use infrequently, I'm a
| fan. The alternative is to just use 'forgot password' to get a
| link that resets my password. That is pretty much the same
| functionality.
|
| I guess the hard part there is that no one building software
| thinks their app is 'low-value'. :)
| adrr wrote:
| If the high value account does password resets via email a
| magic link email is no less secure. Even banks do password
| resets by email but combine it with private info like SSN
| which really isn't private due to all the breaches like
| equinox.
|
| Email is the master key to most of your accounts.
| ninkendo wrote:
| > Email is the master key to most of your accounts.
|
| I've been mulling over ideas for this in my head for a
| while, about fully standardizing the magic-link-to-login
| approach as a full single-sign-on implementation.
|
| Sites could craft an email with a specific header scheme
| that denotes what it's trying to do, for what website, and
| what the magic link key is. The body of the email would
| still look like a regular magic link email as it does
| today, as a graceful fallback behavior.
|
| The website login screen could detect if the user agent
| supported magic links (best way to do this detection is
| TBD...), the requirements being be that (a) The OS has an
| email account configured for the user (like via Mail.app or
| similar), and (b) the OS can broker the security
| information of the magic links to the browser so that it
| doesn't need "full" access to your email, just a
| standardized API for the browser to get the magic link
| header info.
|
| If everything checks out, the UX for the login page would
| be:
|
| - User: enters email address to log in with, hits submit
|
| - Webpage: renders a quick loading spinner
|
| - Website: Sends a magic link email to the email address
|
| - OS: Sees the special magic link email and notices that
| the browser is in focus on the same origin (using an origin
| policy that requires the magic link's headers matches the
| same origin as the page)
|
| - Browser: Gets magic link/token from the OS
|
| - Browser: Submits token to website
|
| - User sees the login succeed.
|
| - (Optional:) The mail client puts the email itself in a
| trash folder or some other place so the user doesn't even
| notice it (although they should be able to dig it up if
| they want.)
|
| The graceful fallback if the browser/OS setup is not
| supported would be that the website just renders the same
| "check your email for a link" page it would have normally
| sent.
|
| Apple has enough integration to easily implement this on
| iOS and macOS, it would be great to see this happen. They
| already implement autofill for security codes sent to SMS
| or email, so they already have a similar level of
| integration, it just needs to be made seamless and not even
| require user input. It could also be a totally open
| standard so that any OS/desktop environment/etc could
| implement it.
| mooreds wrote:
| What is the win of this over webauthn (if the website
| supports it)? I guess the big win is that the graceful
| fallback is smoother.
|
| Seems like a lot of moving pieces that only an OS vendor
| (who controls both the browser and the email client and
| could build the integration between them) could
| implement.
| adrr wrote:
| Webauth authenticates the device. Still need a way to
| authenticate the user then you can use webauth going
| forward on the device. This is assuming you're using the
| TPM chip on the device and another FIDO2 device. Standard
| user won't have a FIDO2 device like a yubikey but if
| their phone or computer is relatively new, they will have
| a TPM chip.
| lkbm wrote:
| I was recently thinking something similar for
| implementing a 2fa similar to how Google and Apple do it:
| pop up a notification on your phone asking "Is this login
| you?"
|
| Throw some structured data into the email. Email clients
| can detect and do the popup that hits a callback
| endpoint. Clients that don't support it still get the
| code via regular email.
|
| I avoid the OS-layer implementation at the expense of the
| user having to confirm it's them, but this also means it
| works cross-device, which is what I'd want for 2fa
| anyway.
| nisegami wrote:
| >I guess the hard part there is that no one building software
| thinks their app is 'low-value'.
|
| I know the things I'm working on are low-value and appreciate
| it. In fact, I genuinely dread ever working on something
| high-value.
| wongarsu wrote:
| From a security perspective, most passwords can be reset by
| email, so sending a magic link or code to the email has
| approximately the same security properties.
|
| The only real difference is if the password reset forces you
| to change the password and logs you out everywhere, then you
| can at least detect the break-in more quickly with the
| password approach.
| mffap wrote:
| Interesting - thanks for sharing!
| patwolf wrote:
| I worked on a project where we used magic links (using
| Firebase) for users to checkin at an event using an app. It was
| a disaster.
|
| For a lot of users the link didn't open in the app the way it
| was supposed to. Another surprisingly large subset of users had
| two phones, but the app wasn't on the phone they used for
| email. A one-time code definitely would have been better than a
| link.
| andybak wrote:
| > MagicLinks are a mobile nightmare. Mobile email clients use
| their own browser and cookie jar which consume the session
| cookie you're trying to put into the user's main browser.
|
| It might be howling into the void but the conclusion I reach
| from this is that "Mobile email clients are a nightmare".
|
| Generally speaking, embedded browsers in mobile apps are a
| terrible idea and break user expectations in multiple ways.
| gfaster wrote:
| On the flip side, I find that opening links in isolated
| sessions very valuable, if not just because I don't want
| links sent by others to affect the Algorithm's perception of
| me. 80% of the time, I want to be a blank slate when
| interacting with in-app browsers.
| pbronez wrote:
| I really want the choice. I hate that most iOS apps want to
| open links in their own webview instead of my default
| browser. Of course, when they DO use the default browser, I
| would like to have control over what context that browser
| uses to handle the link. Default? Private? Task-specific
| tab/container group? Ask me, please.
| jakub_g wrote:
| On Android, if you have more than 1 browser, and no default
| browser app (settings / apps / default apps / browser app),
| clicking a link will ask you which browser you want to use.
| For random one-time-usage links, I use Firefox Focus for
| that purpose. When it's closed it wipes all history,
| cookies etc. automatically.
|
| Meanwhile if the stupid app decides to hijack the link and
| use in-app browser, you can't do that. And IAB typically
| means you can't have app and browser in parallel and switch
| between them from app launcher, which would be sometimes
| useful. Slack does that, and it's annoying. But at least
| you can right click> copy URL and open it manually in
| preferred browser.
| lkbm wrote:
| > It might be howling into the void but the conclusion I
| reach from this is that "Mobile email clients are a
| nightmare".
|
| This is true, and as a user I want something better, but as a
| developer I need to build for what our users use.
|
| I don't put "Site best viewed in Netscape Navigator", and I
| don't tell users they can only login on desktop.
| rurp wrote:
| Totally agree. Same apps have an option to disable this
| behavior, but it's a chore to track down and update
| everywhere. I would love it if Android had an OS level
| setting to disable these and send every request to the
| default browser. That might cost Google some data/money so
| sadly it'll probably never happen.
| fvaldes33 wrote:
| Totally agree with this statement. In my apps, I have used
| magic links for desktop usage but on mobile apps, I opt for
| an OTP approach. Solves the same problem without the mobile
| email client issue.
| anon23anon wrote:
| Back in the day on the web site the marketing team always
| insisted links open in a new windows b/c customers won't ever
| come back if you direct them away. Eventually browsers let
| users override that nonsense. The insistence by our marketing
| team on all these embedded browsers reminds me of the same
| mindset in 2020.
| tryauuum wrote:
| I also believe links should open in the same window, but
| I've met people who religiously believe otherwise and they
| are not a part of marketing team
| pritambaral wrote:
| > Mobile email clients use their own browser and cookie jar
| which consume the session cookie you're trying to put into the
| user's main browser. This results in users 'never staying
| signed in' and a lot of frustration.
|
| The earliest Magic Links I remember using didn't have this
| problem, and this was before smartphones. The Link, back then
| at least, was only to authenticate that you can receive emails
| at a certain mailbox, not to authenticate whichever browser you
| used to open it. Your login attempt would keep the login (not
| logged-in) session open wherever you attempted to login from,
| while waiting for the Magic Link to be clicked on in the
| background. Whenever the Magic Link was clicked, irrespective
| of where it was clicked, your original browser session would
| stop waiting and log you in.
|
| This also avoids the tedium of having to copy a link or code
| from one device/app to another. Just click, a browser
| tab/window opens for a short time, and then closes
| automatically after doing its job; you go back to wherever you
| attempted to log in, and simply proceed. This also simplifies
| post-login flows (like visiting a specific page you tried to
| access before being forced to login) in that such flows don't
| need to be tied to the Magic Link itself.
| ncallaway wrote:
| I just recently implemented a magic link flow for a project
| I'm working on, and "authenticated in the originating
| browser" was a high priority item for me.
|
| I think it's just so much nicer of an experience to not have
| to worry where you go check the email or which browser opens
| when you click the link there.
|
| The site you used to login was clearly where you intended to
| be, so that should definitely be one of the authenticated
| sessions when you click the link.
| thdxr wrote:
| The issue I ran into with this was I could initiate a login
| for anyone and if they accidentally hit the link I could
| remote login.
|
| Switched to pin code entry, less fancy but achieves all the
| desired UX
| ncallaway wrote:
| I think that's totally fair. The site I'm working on is
| pretty low stakes from a security perspective (a private
| personal blog), with less technical people in the
| audience, so I was willing to make that trade off for the
| UX outcome I wanted, but that was specific to the damage
| of a breach in my specific use case.
| IggleSniggle wrote:
| As a user the problem I run into with some frequency is
| passwordless login where the waiting session loses its
| "waiting" status because I switched the active application in
| iOS from my browser to my email and back again. When I get
| back, the page for whatever reason (refresh after being
| backgrounded?) requires a new auth attempt.
|
| A wrinkle in this complaint is that in most scenarios I don't
| especially _want_ a browser tab to be able to hold onto a
| persistent session while it's closed due to privacy reasons,
| regardless of where that session state is held (and I realize
| there are a number of options).
| londons_explore wrote:
| > (refresh after being backgrounded?)
|
| This is a problem on low memory devices - the page gets
| forced to refresh because the system ran out of RAM. The
| iPhone 13 only has 4GB of RAM, and with many apps requiring
| 2+GB, it is frequent a web page can't stay loaded in the
| background.
|
| Most android devices have 8GB plus RAM, so shouldn't hit
| that issue, although it still happens on very low end
| devices.
| IggleSniggle wrote:
| They can take my iPhone 7 and its 2GB of RAM over its
| dead body.
| couchand wrote:
| A simple workaround for the implementation is to redirect
| you to a URL with the code hashed as a query parameter.
| IggleSniggle wrote:
| Yes, I was thinking about that, as something like a TOTP.
| But that needs to be done via DNS-over-HTTPS or DNS-over-
| TLS or else the code can be sniffed by a MITM since the
| URL is sent in the clear, at which point you're back to
| the problem of persistent TLS anyway.
|
| Edit: In fact, nevermind. My thinking on that was flawed.
| I think you're right, that should be fine, as long as the
| DNS is encrypted.
| SkeuomorphicBee wrote:
| That seems extremely unsafe, email being what email is, there
| are many layers of automation that may access that link
| unprompted: a spam/virus filter on the server or the client
| may access it to verify it is not some malware, a email
| client may access it to preload assets, etc. So if a
| malicious actor starts a login on one of my accounts, and
| somewhere along my email chain-of-custody/stack a helpful
| software access that link for some reason, then the malicious
| actor will be authenticated.
| yesbabyyes wrote:
| A site could mitigate this by responding with a form to be
| posted, asking the user to click a button to verify. Only
| the POST request after user interaction would verify the
| email address.
| londons_explore wrote:
| You have to deal with 'email antivirus scanners' which click
| every link in a mail sent to every user in some sandboxed
| browser.
|
| If your user has one of those, then their account effectively
| has zero security since an attacker can attempt to log in,
| and the web security software will click the link, and the
| attacker (in the originating browser) is now logged in.
| bombcar wrote:
| Those destroy the links anyway; I can never reset a
| Salesforce password because the link is always "expired".
| [deleted]
| daveoc64 wrote:
| I think this is an important point that is often overlooked.
|
| I can quickly access email on my phone - that doesn't
| necessarily mean I want to log in on my phone.
| RulerOf wrote:
| >Your login attempt would keep the login (not logged-in)
| session open wherever you attempted to login from
|
| While I generally agree that this behavior is correct from a
| usability standpoint, it's not safe. That design allows a
| user to do a one-click account compromise when they receive a
| magic link that was sent in response to the login attempt of
| an attacker that happened to know the user's email address.
| silversmith wrote:
| So add a step that requires "knowledge transfer" between
| the login device and confirmation device. Microsoft does
| this in their authenticator app showing essentially three
| confirmation buttons with different numbers on them, and
| requiring you to press the one being shown on the login
| screen. Worst case you now have one-in-three-clicks account
| compromise rater than one-click. And hopefully this also
| causes the user to ask why they are being required to log
| in if the app is not displaying the confirmation data.
| Joker_vD wrote:
| It's actually pretty insane: there is a setting on Android to
| always use the main browser (Chrome) to open links, I've turned
| it on, and yet the Gmail app _still_ opens the links in the
| embedded Chrome browser -- which has different cookies,
| different history that apparently is not synced with my other
| Chromes, and even looks sli-i-ightly different than "normal"
| Chrome, somehow.
|
| I've no idea why it is so difficult for apps to open links in
| the user-selected browser. Isn't it just "xdg-open
| https://example.com/"?
| tshaddox wrote:
| That's odd. I have used the Gmail app on iOS for many years,
| and as far as I can remember it has always just opened links
| directly in Safari.
| code_duck wrote:
| I get a choice of Chrome, Google app (which isn't even
| installed) and Safari. I mainly use Firefox, though, and
| that isn't an option.
| delecti wrote:
| The setting you're talking about is probably the OS level
| setting. There's an additional setting in the GMail app to do
| the same thing.
| snovv_crash wrote:
| Uninstall chrome and use Firefox, and it works for me with
| full cookie sharing. There is even an "open in Firefox" in
| the hamburger drop-down which transfers the page to the
| browser app without reloading.
| eru wrote:
| As an added bonus, Firefox on Android also support ublock
| origin.
| jsmith99 wrote:
| I get that with Kiwi browser's custom tab as well. Kiwi is
| a fork of chrome for Android with extension support. Is it
| not in stock chrome?
| dont__panic wrote:
| Can you uninstall chrome from most Android phones? I think
| I've tried in the past but failed.
| cercatrova wrote:
| Go to Settings, apps, search for Chrome and click the
| disable button.
| JamesSwift wrote:
| > I've no idea why it is so difficult for apps to open links
| in the user-selected browser. Isn't it just "xdg-open
| https://example.com/"?
|
| No, theres implementation differences across API levels and
| the "shared cookie jar" implementation is newer and had some
| quirks. Its been a couple years since I was deep in this so
| it might have changed, but that was my experience back then.
| maccard wrote:
| > I've no idea why it is so difficult for apps to open links
| in the user-selected browser.
|
| It's not, it's a conscious decision to open links in chrome
| from gmail.
| Fnoord wrote:
| > It's actually pretty insane: there is a setting on Android
| to always use the main browser (Chrome) to open links
|
| That is quite insane indeed.
|
| And on top of that, Android keeps using Chrome as embedded
| browser. Even if you installed another one. MSHTML all over
| again.
| jsmith99 wrote:
| Many browsers such as Firefox and Kiwi let you enable them
| for 'custom tabs' which is the term for popup browser
| windows that you may be thinking of as embedded browsers. I
| think the setting is usually within the app's settings
| rather than the general android settings.
| jakub_g wrote:
| Before that (Android <5.0 times), you'd have a WebView
| strictly tied to the OS version and not upgradable if OS
| goes EOL. Even if device had Chrome 60, webview was based
| on Chromium 28-30 (depending on manufacturer). With no
| flexbox etc. As a dev, it was a MASSIVE pain to develop
| webview integrations with this. On par with IE8. Being able
| to have the webview upgraded without upgrading OS is a
| major win.
|
| [Note there are two things: 1) stupid apps putting a
| generic in-app browser inside the app - that's annoying;
| and 2) apps using a webview with a bridge between native
| app and a website, injecting some stuff and properly
| integrating the embedded website; something impossible to
| do by opening a website in regular browser]
| joshstrange wrote:
| A totally unbiased article for sure /s
|
| These guys sell a auth/login system, it's no surprise they are
| anti-magic-links.
|
| I understand the annoyances for the more tech-minded among us,
| myself included, but I've implemented this before and for your
| average user it's a pretty good system. With Universal Links/App
| Links you sidestep a number of the issue with email clients
| having their own in-app browser. Also this makes your
| signup/signin process the same flow (and only 1 step) which is
| easier for people who aren't as technically minded.
|
| I used this method for a food festival (you buy the festival's
| currency to spend on food/drinks, it's just a digital version of
| the paper/ticket/token-systems a lot of a festivals use) and we
| only had 1-2 people who had issues (email took a few minutes to
| get to them for some reason) out of thousands.
|
| It's all about knowing your customer base, in the future I might
| implement the ability to set a password but I'd be the number of
| people who use that option will be vanishingly small (again,
| based on the demographics of people using my platform).
| tomc1985 wrote:
| Fuck magic links. What a horrible login flow. Am I the only
| person taht doesn't have my email open in another tab?
| smt88 wrote:
| > _Am I the only person taht doesn 't have my email open in
| another tab?_
|
| Magic links aren't targeted at the type of user you seem to be.
|
| Most users of most products are: 1) on mobile devices, and 2)
| use a native email client.
|
| They also don't have password managers, so magic links become a
| way to assume the security level of their personal email (which
| is what "forgot password" ends up doing anyway).
| tomc1985 wrote:
| It doesn't matter. Crap like this makes the web worse. We
| cannot keep catering to people who refuse to learn better
| practices.
|
| If the industry got itself together enough to start teaching
| people good internet hygiene we'd all be much better off. But
| instead we strip away OK security for horrible security, and
| inconvenience nearly everyone in the process.
| jjoonathan wrote:
| My favorite is when a vacation or network change triggers what
| amounts to a cascade of security audits. Site A sends magic
| link to Email B, which in turn sends text to phone C but it
| never arrives, so everything times out. On the next go, Email B
| can be persuaded to send magic link to Email C which now wants
| a ubikey or password you haven't used in years. A simple login
| turns into an hour long slog -- with landmines!
|
| So far, I have been careful enough, but it's only a matter of
| time until this bites me.
| TekMol wrote:
| I wish there was a way to read all cookies of the current site
| and create a bookmarklet that sets them again.
|
| So I could log into GitHub and save the cookies in a bookmarklet.
|
| Then every time I want to use GitHub, I click the bookmarklet and
| it sets the cookies, so I am logged in.
|
| I dabbled with the idea a bit, but it seems not straight forward.
| Maybe due to some metadata that cookies carry. They are not just
| key:value pairs.
|
| For example here on HN, when I type "document.cookie" into the
| console, I get back an empty string.
| vgel wrote:
| You might be running into issues with session cookies and
| HttpOnly cookies: https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Cookies#re...
| spicyjpeg wrote:
| That would not work for a number of reasons, the first one
| being the fact that virtually every service now uses HttpOnly
| cookies for session management (to make it harder for e.g. XSS
| injected code to steal sessions). In addition to that session
| cookies are usually rotated very frequently, with servers
| occasionally updating them even if you stay logged in; it goes
| without saying that if you log out and back in you will almost
| surely get a different session token each time.
| capevace wrote:
| Magic links can be very helpful when needing to authorise people
| from an external system without API access, and they recently
| saved our asses from having to process over 10.000 refunds
| manually. Let me explain:
|
| I work as a web dev for my local students union, and we recently
| had to develop a system to process refunds for basically every
| student there (9EUR ticket related).
|
| However, our university wanted nothing to do with that process,
| so we couldn't use existing student login infrastructure to
| verify refund claims and limit them to one per student.
|
| Luckily, each student gets a @stud.leuphana.de mail address. So
| all we had to do was send them a login link - if you weren't a
| student or entered an invalid address you simply never received
| that, so you couldn't apply.
|
| The system worked great and with few issues, thanks to magic
| links!
| mojuba wrote:
| Another relatively new problem with magic links specifically on
| mobile is that your email client will likely open the link in an
| embedded browser which is typically isolated from the main
| browser app and doesn't share the cookies with it.
|
| There are some workarounds for this but they don't seem very
| secure, plus they add some complexity. E.g. once the backend
| validates the magic link click, it logs the user in also in the
| browser that initiated the email send. I think a sort of a
| phishing attack is possible here. Also the page that initiated it
| should periodically refresh itself to see if the session was
| validated somewhere else.
|
| I haven't been able to find any more secure or simpler solutions
| to this problem. Any thoughts?
| ammmir wrote:
| The way I've implemented in one of my own projects [1] but that
| I'm not fully happy with (and the way that Amazon.com does it)
| is to do what you suggest: create a record on the backend when
| the login attempt begins and have your frontend keep checking
| that record until there is a result like email verified/not-
| verified/timed-out. When the user clicks the magic link in the
| email, update that record with their choice to approve or
| reject the login, or ultimately time out and invalidate the
| login attempt. This avoids the separate cookie jar problem.
|
| The phishing scenario is a real one, though. People have been
| conditioned to click Yes on everything. Coinbase's magic links
| implementation, for example, requires you to click the magic
| link in the same browser session that initiated the login. This
| is a bit more secure, although annoying from a UX perspective
| if you're in an embedded WebView like you mentioned.
|
| The middle ground is something like instead of sending a link,
| send a code via email that you enter on the website, but that
| just removes the _magic_ of magic links and is no different
| than what it was before!
|
| [1] https://loginwith.xyz
| notahacker wrote:
| > The middle ground is something like instead of sending a
| link, send a code via email that you enter on the website,
| but that just removes the magic of magic links and is no
| different than what it was before!
|
| Wouldn't an even better middle ground option be defaulting to
| magic links, with the magic link destination both logging in
| and notifying the user that if they user want to switch
| [back] to a different web browser or device they can use
| their email and $TIMELIMITEDCODE? (Perhaps with the
| notification disabled if the browser which opens the magic
| link shares a cookie jar with the browser session which
| requested the magic link, and perhaps including a "You
| recently tried to access using $RequestOriginatingBrowserName
| on $DeviceID" to hint they might want to get out of their
| mail client)
|
| Offers both the magic bit and a non-magic way to escape from
| the sandbox that is less likely to be a vector for
| speculative phishing attacks.
| mffap wrote:
| > Also the page that initiated it should periodically refresh
| itself to see if the session was validated somewhere else.
|
| I guess the link must be disabled / invalidated after first use
| and your auth server and client obviously must verify if a
| given link is still valid.
| mojuba wrote:
| Of course the link should be invalidated, but that doesn't
| protect from a situation where an attacker initiates a login,
| then the user receives an email and clicks. The chances are
| slim but some people might get confused and click without
| much thinking - and voila, the attacker has a valid session.
| pritambaral wrote:
| Simply opening a Magic Link doesn't have to authenticate
| the initiating login. The user can be asked to interact
| with the page, being shown the source of the link (time,
| browser, device, IP/Region, etc.), to authenticate the
| login. This adds a little bit of friction to legitimate
| cases, but then again having to open your email and find a
| link and click it is already plenty of friction that this
| additional step can be considered a negligible addition to
| that.
| amacneil wrote:
| It is strange to me that both this article and commenters in this
| thread complain about "email security" as being a limitation of
| magic links, given that the vast majority of password
| authentication websites allow an email-based password reset flow.
| Magic links aren't any more or less secure than allowing email-
| based password reset.
| planede wrote:
| A lot of people brought up scanners that auto-click links. How do
| these scanners deal with verification email links or unsubscribe
| links in general?
|
| I mean unsubscribe links are commonly two-stage (you have to
| click a button on the target website), but now always. Never saw
| a similar two-stage verification link though.
| bob1029 wrote:
| I think magic links have some give/take depending on your
| product/platform/audience.
|
| One major use case that comes up more frequently is onboarding an
| untrusted device with a trusted one. WhatsApp seems to have
| mastered this class of problem using the QR code. Typing in codes
| and clicking emailed links is nice until you feel your phone's
| camera instantly log you in on your laptop by scanning its
| screen. The obvious downside is that this is a chicken-egg
| situation and you have to already have one chicken (or egg) to
| make it work.
| amadeuspagel wrote:
| I've been thinking about magic links using QR codes rather then
| email.
|
| EDIT: The idea here is that on a device where you're already
| logged in you generate a QR code, you photograph that code on
| another device, and then you confirm on the first device that
| it's really you who photographed the code on the other device.
| Mordisquitos wrote:
| I don't understand. What would the QR encode? Surely not the
| magic link itself, as that would defeat the purpose.
| amadeuspagel wrote:
| Yes of course the magic link itself. How would that defeat
| the purpose?
| dspillett wrote:
| _> How would that defeat the purpose?_
|
| If it is just the magic link then anyone, someone shoulder-
| surfing as you access the site/app for instance, could scan
| that code and get in by following the link.
|
| If it is being used as a single factor then even worse:
| anyone can get the QR code to scan without you even being
| present.
|
| QR codes will work in this sort of context, but more work
| is needed to prove the device scanning the code is the
| user's device and not some random's - you can't just use a
| straight single request following the magic link as
| credentials.
| amadeuspagel wrote:
| Yeah. So one possiblity would be to confirm on the other
| device, where you're already logged in, that you're the
| one who photographed the QR code.
| Mordisquitos wrote:
| If you need to be already logged in the device that reads
| the QR code, then the QR is no longer encoding a magic
| link. It is more similar to doing the 2nd part of 2FA
| (after skipping the 1st) but adding unnecessary
| complexity in between. If we expect the user to be
| already logged in on a device that they have at hand, why
| give them a QR code instead of simply a PIN code or a
| notification to confirm the new login?
| amadeuspagel wrote:
| No, you already need to be logged in in the device that
| generates the QR code.
| dspillett wrote:
| If the user's phone's browser knows a relevant secret (a pre-
| shared key or the private half of a key-pair the other side
| has the public half saved in), then the QR code is a magic
| link. Scanning the code opens the page in the browser, that
| page reads the secret (client-side only obviously) and uses
| it to sign a second request.
|
| Requires a setup step first that the magic link doesn't
| (getting the secret stored in the browser).
|
| Also no use if the user is trying to login with that
| particular device.
| theginger wrote:
| I think the idea is to stop mail providers automatically
| scannings the link, which would work until they start
| scanning the images for QR codes and scanning the links.
| withinboredom wrote:
| I don't understand how this would work if you are getting
| emails on the device you are trying to sign in with. Most
| devices (other than Android?) don't let you scan a code
| from a photo.
| Mordisquitos wrote:
| I don't know, GP comment said "rather than email" and not
| "rather than a link".
|
| Even so, the potential problem caused by email providers
| automatically calling links in received emails is trivially
| prevented by having a _" Confirm login"_ button at the
| destination, as displayed in the visual example in the
| article. Also, using a QR would then rely on the user
| having _yet another_ device at hand to log in, perform the
| often awkward scanning procedure instead of an ordinary
| couple of clicks /taps... to then finally log in on their
| phone and not on the original device they were aiming to
| (as well as making it less secure in a public surrounding
| against covert attackers in close proximity, but that's a
| bit of an edge case).
| Fnoord wrote:
| Existed earliest in 2010? No way. Earlier. I remember in the 90s
| forgot your password link from e-mail signed you in, after which
| you could change the password.
| ghostly_s wrote:
| "Not device-dependent" is a false assumption. They are entirely
| dependent on you having convenient access to your email on the
| device. I have yet to to encounter one that was smart enough to
| authorize my session on the _original device_ if I open the link
| on a different device (and there are probably good security
| arguments for not doing that).
|
| Even in the ideal scenario where I have a proper mail client, the
| alternative they present is:
|
| auto-filled password from my PW manager: 1 click
|
| magic link: click to initiate the login session (1); click to
| focus my email client (2); [wait for email client to launch if
| not already open]; click on the email (3); click the magic link
| (4) click to close the superfluous second browser tab (5); click
| BACK to my mail client (6); click to delete the now-useless email
| (7); click BACK AGAIN to my browser (8).
|
| Hate these things.
| MrDunham wrote:
| > Email Security: ...Should someone gain access to another user's
| inbox, they simultaneously receive the keys to logging into
| profiles that run on magic links. Therefore, a single cyber-
| attack on your email could lead to unwanted activity on many of
| your utilized virtual services
|
| This statement only partially covers the problem.
|
| I once had a cofounder leave my company on bad terms. He had
| access to the bank accounts, I had email admin.
|
| It took me 5 seconds to get full bank account access and lock him
| out with access to his email ("forgot password").
|
| It's astounding how much of a skeleton key our inbox has become.
| This community doesn't need reminding, but our families do.
| pastage wrote:
| I hope you do not use banks that use just email for
| authentication anymore. Horribly insecure.
| aaaaaaaaata wrote:
| What bank due you use that's MFA key only, with no easy
| fallbacks?
| bamboozled wrote:
| I think a lot of the complaints here are "nerd problems".
|
| For customers they seem like a super convenient thing, I was just
| implementing them in my app. Yes magic links have problems and
| it's probably making me lean more towards the "emailing a code"
| option now, some of those problems outlined aren't easy to
| ignore.
|
| The app I'm working on, users would login probably once or twice
| a year. I just can't imagine they want to deal with passwords,
| especially because my app is very niche, they'd use it once a
| year for one thing only. What I can imagine them having to do is
| constantly use the "forgot my password" feature anyway.
|
| For conversion easy logins are really important.Anyone have any
| better ideas than magic links, passwords or one time codes in
| email?
| wohfab wrote:
| I mean, the magic link could be an addition to the "forgot
| password" screen, then? As in "reset password or login via
| magic link"?
| joshstrange wrote:
| I'm in the same boat. People login 1 time a year (it's for an
| event) and using magic links means I don't have to deal with
| password management, forgot/reset password flows, and more. It
| also means signing up is as easy as entering your email (the
| web/app prompts you for the other required info on first
| login).
|
| Out of thousands of people who used the system I only had 1-2
| people who had issues. One was using their work email (why do
| people do this?) and I think it was being filtered and the
| other was using Yahoo but for some reason the emails were slow
| to deliver, 2-3 minutes (far from the only Yahoo user, only one
| that had issues).
| DocTomoe wrote:
| I quit using services that have magic links as their only
| authorisation method - and so does my 65 year old, very non-
| nerdy mother (she complains about 'having to wait for a damn
| email' all the time)
|
| > Anyone have any better ideas than magic links, passwords or
| one time codes in email?
|
| Passwords. Password managers are not a new concept, they have
| been around for decades by now, have deep browser integration
| (either because they often are part of the browser, or in the
| case of Apple, the OS), and are easily understood by users.
| zinekeller wrote:
| > I think a lot of the complaints here are "nerd problems".
|
| Not really.
|
| - Email deliverability is a serious issue - some well-known
| providers (Apple and Microsoft) can delay email up to five
| minutes because they're scanning it, and that's assuming that
| it didn't went to spam. Compared to 2FA login, that's an
| eternity.
|
| - Also, speaking of scanning emails, some do "click" them to
| check that it's not a harmful page (Microsoft, Google Workspace
| if admin enabled it, Barracuda which is common on enterprise),
| rendering the link invalid.
|
| - Not everyone keeps their email logged in (or uses a different
| app/client to keep them logged in), which results in worse
| experience.
|
| - Most mobile email clients (Mail on Apple, Gmail, Outlook) by
| default launch a different window, meaning you're logging into
| the mail client and not the browser.
| capableweb wrote:
| Article fails to mention that "Magic Links" are not only possible
| via email, but any out-of-band method, so you could use Whatsapp,
| Telegram or IRC even. Obviously, the user is assumed to have a
| secure setup regarding whatever method you send the link via.
|
| Which the "Email Security" section kind of hints to as well, that
| it's important users have a secure email setup. What they fail to
| mention, is that this is important not only if you use "Magic
| Links" but also if you have username+password login with "Reset
| my password" functionality, as otherwise intruders will be able
| to change your password anyways.
|
| In conclusion, the article seems to have been written with the
| goal of saying "Everyone is using Magic Links, how can we get
| them to use Zitadel (their product) instead?", rather than an
| honest look on how "Magic Links" can be made more secure.
| nibbleshifter wrote:
| Great, now I'm going to spend the evening designing a login
| system that uses IRC private messages to deliver a magic link
| (or something, maybe ask for TOTP via the IRC chat?) for fun.
| mooreds wrote:
| > "honest look on how "Magic Links" can be made more secure"
|
| Challenge accepted. Here's my best practice list. (I should put
| this into a blog post!)
|
| * Prefer them for accounts that are infrequently used or low
| risk.
|
| * Test for conversion or goal uplift if possible with this.
|
| * Offer the user choices; some people will prefer
| username/password, some magic link, some social sign-on.
|
| * Ensure that users understand that whatever the destination is
| (email, whatsapp, slack, etc), the security of their app
| account is now tied to the destination's security. Understand
| that most folks care far more about their email or other
| destination than they do about access to your app.
|
| * Understand the UX tradeoffs (around mobile browser issues).
| Document them if possible
|
| * Make sure everything is over HTTPS. (Duh :) ).
|
| * Set timeouts for links appropriately and communicate that to
| your users. ("This link is good for X minutes." "This link
| expires at HH:MM.")
|
| * Warn users that access to the link is the same as access to
| the account. "Don't forward this email".
|
| I think that's everything I'd say. I would love to hear if I
| missed something.
| mffap wrote:
| How should an honest look at the topic include for your, that's
| lacking in the article? You mentioned the focus on email
| instead of other channels. Anything else? Thanks for the
| feedback.
| [deleted]
| pottertheotter wrote:
| One of my healthcare providers uses this and I abhor it. With
| their website I can see appointments, billing, etc., but instead
| of simply going to the website and logging in with 1Password, I
| have to go to the website, enter my email and click log in,
| switch to my email and wait for the email, open the email and
| click the link which takes me back to my browser.
|
| It drives me nuts.
| yababa_y wrote:
| They don't seem that outdated to me, given the evidence
| presented. email provider security is a real problem but is
| usually considered the root of trust for persons...
| nnx wrote:
| Also a possible way for magic links to be secure _even if email
| is compromised_ is for the requesting browser to create a
| secret client side so that only that browser can actually
| proceed with the magic link.
| joosters wrote:
| If the email is compromised, the hacker can just go to the
| front page in their own browser and generate a fresh login
| email, so there's no extra protection in client-side browser
| secrets.
| xxs wrote:
| It'd be ok, if there is (yet) another factor for doing
| this, e.g. SMS, time based tokens, and you'd need 2 of them
| to reset the 3rd. Cumbersome to put it mildly.
| DocTomoe wrote:
| One of the first things I learned when I got onto the internet
| was that "consider (RFC822) emails to be postcards analogs,
| readable by anyone who stumbles over them, they are not like
| mail which hides its content in an envelope." That was in 1994.
| Shirts reading "I read your email" were popular with the IT
| guys up to until about ten years ago (and they are still being
| offered).
|
| Email is an inherently insecure, non-trustworthy system.
| Considering it the "root of trust" sounds scary.
| yababa_y wrote:
| and yet, it is! for many webapps, and not long ago almosy
| all. pop someone's email and suddenly you have access to
| gazillions of account recovery flows. despite email's flaws,
| it's the defacto decentralized user namespace and
| authorization fallback. in the case of modern email, t only
| the sender, receiver, and a chain of usually-authenticated
| intermediates actually can see the contents of mail. it's not
| completely plaintext anymore, i don't think it's as scary as
| you would think in 1994. and if modern email transports don't
| count, then isn't it true that _any_ messaging system could
| be considered as postcards in that whoever stumbles across
| the message contents can read it?
| usrn wrote:
| Magic links are half factor auth. They're probably good enough
| for apps that no one actually cares about though.
| postalrat wrote:
| Does that make a password + email password reset a quarter
| factor?
| usrn wrote:
| Password plus email is one factor. So that would be 3/2
| factor auth.
| postalrat wrote:
| Email reset isn't any different than a magic link. Adding
| an additional password option for login only lowers the
| security.
| ricardo81 wrote:
| The article doesn't seem to cover a potential issue- updating an
| email address associated with an account (2FA aside).
|
| If you've somehow lost access to email, a typical pattern is that
| you can login to your account, update the username and receive a
| validation email at the new address to confirm its validity.
| bamboozled wrote:
| "Contact support to update your email"?
| bradgessler wrote:
| I wrote a Rails plugin for magic links at
| https://github.com/rocketshipio/nopassword that doesn't suffer
| from many of the problems I'm seeing in the comments.
|
| The big thing is I only use a 6 digit numerical code that people
| have to copy and paste or type into the browser which they're
| authenticating. I looked at stuffing a token into a URL, but it's
| not a good idea because the email client may try opening the link
| to preview it or it may try opening the link in the wrong
| app/browser, such as an in-app browser.
|
| That may sound super insecure, but the 6 digit code is half the
| secret that's needed to authenticate. The browser that the person
| is using to login has a much longer complex secret that must be
| included with the code. Additionally, this combination must be
| authenticated within a set number of attempts, 3 by default,
| within a certain timeframe, 5 minutes by default.
|
| My motivations for creating this, instead of using something like
| devise with passwords, is because I have seen soooooo many non-
| technical people get tripped up by passwords. I know there's
| sign-in with Google, MS, etc. via OAuth, but I wanted to give
| people a way to login to web applications without being under the
| watchful eye of big tech.
|
| I'm currently using it in production for all of my Rails apps,
| like https://legiblenews.com/email_authentication/new
|
| A better description of why and how it works at
| https://github.com/rocketshipio/nopassword
| smt88 wrote:
| You should take this nopassword repo down. It's a good example
| of why you shouldn't "roll your own" in InfoSec, and it would
| honestly make me skeptical of any of your other security work.
| It looks like you may not be using it for anything sensitive,
| but I'm worried that someone else might try to.
|
| As an alternative, there are many hosted services (e.g. Auth0)
| that are well-regarded, and I'm sure there are some self-hosted
| options. There seems to be at least one way to do magic links
| on top of Keyclock[1].
|
| 1. https://github.com/p2-inc/keycloak-magic-link
| aaaaaaaaaaab wrote:
| Yep. Promoting shit like this on a public forum is borderline
| malicious.
| [deleted]
| aaaaaaaaaaab wrote:
| So if I have 700k usernames I can pwn one of them with 50%
| probability. Cool!
|
| With 3 attempts allowed I only need 230k usernames, even
| better!
|
| The "secret" stored in the browser doesn't protect you from
| this, since I'm not stealing someone's code; I'm logging in
| from my own browser. (Of course I'm doing this via a botnet, so
| you won't notice it by IP address)
| Isinlor wrote:
| With passwords you will get even higher probability if you
| just try 100 most popular passwords allowed by the service on
| hundreds of thousands of users.
|
| Try making password creation too difficult and now password
| reset will be the default authentication for a lot of users
| anyway.
| aaaaaaaaaaab wrote:
| The 100 most popular passwords should already be
| blacklisted during registration, so it wouldn't be possible
| to set them as your password.
|
| I have nothing against password-reset-as-authentication aka
| "magic links", when done properly. And by properly I mean
| not using an ultra-low entropy auth code, like the parent
| is proposing (6 decimal digits, aka 20 bits of entropy).
| joshstrange wrote:
| I'm pretty sure you are missing how they implementing this.
| It sounds like at time of the request to send the code the
| browser either generates and sends to the server (or gets
| from the server) a longer/more-complicated secret. Both that
| secret (which is probably account-specific, the one you
| requested login to) and the 6 digit code are required. You
| can't just guess the code, the code has to be combined with
| another account-specific token.
|
| By regenerating longer token each time a 6-digit token is
| required and only allowing something like 3 guesses per
| longer token (Before regenerating and sending a new 6-digit
| code) you have a secure system.
| aaaaaaaaaaab wrote:
| No, actually I'm pretty sure _you_ are missing why their
| system is insecure.
|
| But sure, let me explain it:
|
| Step 1: acquire a list of 230 000 usernames/emails.
|
| Step 2: for each username/email, launch a browser and
| request a login code. The login code is sent to the users'
| email address, and the super-ultra-secret token is stored
| in the browser.
|
| Step 3: for each username/email, do 3 random guesses from
| their respective browsers.
|
| Each guess is a Bernoulli trial with P = 10^-6. Thus the
| probability of at least one success is 1 - (1 -
| 10^-6)^(230000 * 3) = 49.8%
|
| I hope this made it clear for you. I think the fallacy in
| your reasoning was assuming that only legitimate users can
| get the "secret" token, which is false. It is true for
| things like debit cards, where the token is stored on the
| card itself, hence the 4-digit PIN with 3 tries allowed is
| sufficient. In this case however a "secret" token is handed
| out to anyone who requests a code. It protects you from
| someone peeking into your mailbox and stealing your code,
| but it fails against brute forcing codes on a large number
| of users.
| mszary wrote:
| You're over complicating this. In fact it might provide a
| similar kind of protection the physical chip provides for
| debit cards. Let me explain:
|
| 1. Someone (anyone) initiates the login flow
|
| 2. The user record in a DB gets enriched with
|
| - the 6-digit OTP (sent via email)
|
| - the "secret" (shared with the initiating browser)
|
| - the current session failed attempts counter (default:
| 0, max: 3)
|
| - the total failed attempts counter since last successful
| login (default: 0, max: 20)
|
| Let's assume that you've initiated the session (hence own
| the "secret"), but have no access to the OTP - you will
| always have 3 attempts to guess the OTP before the
| session gets reset (a new "secret" + new OTP). So after
| the 3rd unsuccessful attempt you start from scratch. And
| at that point other means of protection might come into
| play based on the second counter (throttling the auth.
| requests on the WAF/fronting server, blacklisting IP
| addresses, etc.)
|
| The number of accounts you're targeting does not matter -
| in fact it may help other systems mentioned catch your
| malicious attempts sooner.
| aaaaaaaaaaab wrote:
| >In fact it might provide a similar kind of protection
| the physical chip provides for debit cards. Let me
| explain:
|
| You didn't explain how this gives you any protection akin
| to a physical chip on a debit card...
|
| Let me illuminate the problem with a real-world analogy:
| this system is like me walking into a bank with a list of
| account names, and the bank issuing me debit cards for
| those accounts with random PIN codes, no questions asked.
| I'd have 3 attempts to guess the PIN, then the ATM
| swallows the card. Same as in OPs login system!
|
| Still, don't you think banks would be silly to do this?
|
| >So after the 3rd unsuccessful attempt you start from
| scratch.
|
| You don't start from scratch. You do 3 attempts per user,
| period.
|
| >The number of accounts you're targeting does not matter
|
| It does matter. The entropy of their six-digit OTP is
| small enough that pwning at least one account from a pool
| of users is feasible. As I've shown above, the number of
| users necessary for pwning at least one account with 50%
| probability is log(0.5)/log((1 - 10^-[digits])^[attempts
| per user]). In our case digits = 6, and attempts per user
| = 3, which gives us ~231000 users. Which isn't too many
| for a website.
| mszary wrote:
| > You didn't explain how this gives you any protection
| akin to a physical chip on a debit card...
|
| In both cases you (an admin) control how many attempts
| you wish to accept before sacrificing the usability over
| security (temporarily disabling the card and forcing you
| to call the bank and disabling 6-digits OTP in favour of
| ie. 12-digits OTP).
|
| Your real-world analogy is, this time, too simplified :)
| Let me counter-argument with my example:
|
| You are in a a possession of 1 million user emails and
| request OTPs for all of them (let's assume no other
| security measures are in place). If you hit all of the 1M
| records with 3 attempts of OTP - according to my simple
| experiment - you might hit (on avg) 3.18 accounts.
|
| Of course, in real life, your attack would be mitigated
| on other (non-application) level.
|
| Please find my ugly code for that experiment:
| https://pastebin.com/S2ufabhU
|
| PS. When OTP size is increased to 7 digits - the avg
| account hit drops to 0.33. For 8 digits - it drops to
| 0.02. (please mind I'm using lousy RNG :)
|
| PS2. What I'm trying to emphasize is that there's nothing
| wrong with OTP-auth like this if properly implemented
| with other basic anti-bruteforce techniques. You could
| get "better" results with simple password spraying.
| aaaaaaaaaaab wrote:
| So you actually agree with me.
|
| 1. I don't have any problem with OTP-based magic links,
| if they're implemented carefully. As you've just
| demonstrated, a 6-digit OTP with 3 retries allowed is not
| sufficient at scale.
|
| 2. I've also demonstrated that OP's proposal to augment
| the 6-digit code with a "secret" token gives you no
| additional security. It can only protect against someone
| peeking over your shoulder to snatch your OTP.
|
| 3. As you've just demonstrated, increasing the OTP length
| will mitigate the problem, as it increases entropy. For
| peace of mind, I'd recommend 64 bits of entropy, which
| can be achieved with a 13-letter alphanumeric code (case
| insensitive), or with 5 words from a dictionary of 10
| 000.
| mszary wrote:
| Seems like it :) but I would be more pragmatic and didn't
| bash the system for the reasons you brought up :)
|
| ad 1 - IMO, it's still sufficient at scale with some
| basic infra. hardening
|
| ad 2 - AFAIK the "secret" was never meant to protect from
| brute-force, but rather mitigate threats from actors
| controlling the email part
|
| ad 3 - again, let's be more pragmatic - no one would use
| it if it required typing 13-letters OTP :) there are
| other ways to mitigate the potential attack you've
| described.
|
| Best.
___________________________________________________________________
(page generated 2022-07-13 23:02 UTC)