[HN Gopher] Ask HN: Why aren't one-time sign in links more popul...
___________________________________________________________________
Ask HN: Why aren't one-time sign in links more popular for
authentication?
Tying a OTP to an email appears to be more secure than the cluster
that is remembering and managing passwords.
Author : phenkdo
Score : 134 points
Date : 2021-01-04 07:56 UTC (15 hours ago)
| yowlingcat wrote:
| Really fascinating subject that I've been thinking about a lot
| lately. At $FewCosAgo, I inherited a codebase which used
| passwordless login via SMS. SMS has a ton of intrinsic security
| flaws because of SS7 so there are obviously risks with this
| method. But with that said, it worked very well for the exact
| same reasons email doesn't here: SMS delivers nearly
| synchronously, and it was rare to end up in a situation where the
| login text didn't send to a user. After going through the flow a
| couple of times myself, I was shocked at how much more I felt
| inclined to test my own software just because logging in was so
| much lower friction.
|
| Regrettably, the issues with passwordless email/SMS login mean
| that for now, if there's no OAuth provider you can/want to use,
| the ol' password is probably still the best way to go.
| beh9540 wrote:
| We tried this on a b2b SaaS product I worked on where we had a
| lot of "third party" users (volunteers for a customer) who were
| only going to use the application once a year at most. One of the
| biggest hurdles we had was explaining it to enterprise customers
| - when they were doing their due diligence, it didn't "check the
| box" and we had to change it pretty early on in order to
| accommodate this.
| pchm wrote:
| Described my (negative) experience with magic links in my SaaS in
| another thread recently:
| https://news.ycombinator.com/item?id=25465021
| z77dj3kl wrote:
| We implemented a passwordless, OTP-to-email login system, and
| doing user research, people just complain it's too complicated.
| They don't like logging in to their Gmail and (as others have
| mentioned) waiting a few moments. It's especially bad on
| something like mobile. People like to use passwords, apparently.
|
| I see passwords as reducing security (we have a low-security
| product so people can reset with an email, so security-wise, the
| upper bound is your email security), hence we used it. But people
| prefer the "remember the secret" shortcut!
| radu_floricica wrote:
| I'm assuming you intend those links to be single-use only and
| expire automatically, in which case what I'm writing below
| doesn't apply. Nevertheless, the problem is big enough to be
| worth repeating and re-repeating:
|
| Any link that ends up in a browser address bar should be treated
| as public.
|
| And no, it doesn't matter if you use HTTPS. Ways to leak it are
| many, but the gist is that it's treated as "meta-data" and,
| rightly or wrongly, subject to much lower expectations of
| privacy. A recent scandal was that several common browser
| extensions collect this meta-data and sell it to marketing
| companies.
|
| Which marketing companies offer searchable subscriptions (for
| hefty prices, true, this isn't a $9.99 service), where somebody
| could for example search for "yourcompany.com", or even worse,
| "yourcompany.com/authernticate?token=". Yeah, meta-data.
| squiggleblaz wrote:
| How do you advise we handle email address confirmation and
| password resets?
| aaronhayes wrote:
| Automatically expire the links
| squiggleblaz wrote:
| Apparently I completely ignored the first comment in the
| original post. Apologies.
| squiggleblaz wrote:
| Yeah but you can do that with login token URLs as well. The
| person I replied to said "you can never do that", not "you
| can do that only if you exercise suitable caution". I am
| asking for an alternative that fits with the "you can never
| do that" perspective, not a way to backpedal.
| PedroBatista wrote:
| Because when I want to login I WANT to login - It's amazing how
| much it's spend on shaving milliseconds yet having such an
| indirection doesn't ring a bell as a problem.
|
| Also, having such a critical part of your system depend on email
| delivery and access? Looking at most frontend development
| practices I understand the blindside/YOLO attitude these days but
| it's still a bad idea anytime of the day.
| marcus_holmes wrote:
| Honestly, having a password manager makes this so much easier.
|
| I still like the OTP process, but it is more hassle than using
| the password manager.
| raxxorrax wrote:
| Another name of OTP in E-Mails are capability URLs and they are
| used quite frequently.
|
| https://www.w3.org/TR/capability-urls/
|
| There are some problems though and the authentication could be
| called weak.
|
| Problems is that URLs aren't regarded as secret and the
| irrational tendency to log everything doesn't help, as these OTP
| will be visible after a while.
|
| So these OTP have to be invalidated at some point as they tend to
| become revealed. If expiration is necessary, you still need some
| form of auth to regain access.
| minitech wrote:
| Compared to saved passwords in terms of usability: it adds extra
| steps, potentially several, which is annoying.
|
| Compared to passwords in terms of security: you have to consider
| that the client visiting the link might not be the client with
| the session being authenticated, at which point there might be
| confusion over multiple authentication requests of mixed
| legitimacy around the same time. I don't know how this is
| typically solved.
|
| I think better than either for security and usability is
| passwordless WebAuthn with a local factor (e.g. Touch ID for
| Apple devices, or even a master password for a simple improvement
| over existing password-unlockable saved passwords), if
| implementing something outside the status quo.
|
| (edit: starbugs's point about latency is also very important.)
| Sirikon wrote:
| Email sometimes takes too much to be received by the user, but
| the approach could be handy in other contexts.
|
| For example, some time ago made a Slack bot with a web dashboard.
| The authentication method was based on introducing your Slack
| username and the bot would send you an OTP. The latency problem
| didn't exist here.
| sgoto wrote:
| https://twitter.com/samuelgoto/status/1346145032663756805
| Abimelex wrote:
| There is basically not much difference than sending "reset your
| password" email like all the time you want to log in. Keeping
| this in mind it seems ridiculous using SSO via email.
| sneak wrote:
| Email is not a secure delivery mechanism.
|
| Everyone has an HSM in their pocket these days. The fact that we
| are having these discussions at all is ridiculous.
| eeZah7Ux wrote:
| > HSM in their pocket
|
| If you refer to the typical smartphone, it's an HSM without the
| Security, and also it's not truly Hardware.
| max1truc wrote:
| The problem there is that if your email password is found
| (cracked, leaked, etc.) your account is pwned. However, due to
| the "recover password" options, your other accounts are pwned
| too.
|
| Finally, if you ever loose your email password, you won't be able
| to access any of your accounts anymore...
| ytch wrote:
| How about scan QR code on login screen by authenticated APP on
| phone.
|
| Many companies in China use this way. does there have any
| possible exploit/disadvantage of this method?
| gruez wrote:
| Disadvantages I can think of:
|
| * requires app: This is the main killer. I'm not going to
| install some random SaaS vendor's app on my phone just so I can
| log in
|
| * requires internet access on phone: sucks if your phone
| doesn't data, cell reception is spotty, or wifi isn't set up
|
| * less phishing resistance: one time sign in links are
| impossible to phish, and passwords have mitigations that
| protect against phishing (eg. password managers that only auto-
| fill on the correct domain) and users are generally aware to
| "check the address bar before entering password". scanning a QR
| code has neither of these.
| kevincox wrote:
| 1. I don't want to install you app. 2. I don't want to find and
| pick up my phone. 3. How do you log in to the app? This has a
| bootstrapping problem.
| sethammons wrote:
| Why not use some federated log in like Okta? Not as many issues
| as email on the delivery side.
| runako wrote:
| Passwords are free, Okta is not. Also creates a ton of friction
| for users, most of whom will not have any federated login
| installed.
| searchableguy wrote:
| Substack and scaleway use email link as their primary
| authentication system.
|
| Wonder what the impact of that has on both of them?
| compsciphd wrote:
| In Israel a lot of services are tied to an SMS based OTP
| (including government services), so one doesn't even leave the
| app. the app reads the token out of the SMS and fills itself in
| (of course if that fails, you can still enter it manually).
| sgt wrote:
| On the Mac, Safari has that built in, if you get an SMS
| (delivered to the same Messages app as iMessage), the browser
| knows about it and you just select "Use 1234 from Messages".
| shaicoleman wrote:
| The biggest downside is email isn't reliable - it's slow, it gets
| filtered, and sometimes it doesn't get delivered at all.
|
| For example, I've been locked out of my Patreon account for the
| last couple of weeks since Gmail decided to return 550 errors
| (address doesn't exist) [1] and they require an email to log in
| when the IP address changes. Most likely my email address has
| been added to the suppression/bounce list of Mailgun.
|
| * https://news.ycombinator.com/item?id=25435916
| sirodoht wrote:
| I used to add this functionality to all my projects, as it's much
| better not to have a password. Now I don't like it at all. It's
| very inconvenient to have to switch to your email when you could
| just auto-fill with your password manager.
| hestansy wrote:
| A lot of OTPs are implemented in insecure ways - e.g. using the
| "recover password" functionalities you can often figure out
| patterns the websites are using to create these OTPs. Some
| websites / apps do not implement account lockout and OTP
| expiration mechanisms and have 3-digit codes, which allows for
| brute-force attacks. Others with these mechanisms can lead to
| DDoS. Also, some web apps log these OTPs directly in the URLs. In
| general, I agree with minitech in that WebAuthn with a physical
| factor would be better, both in terms of usability and security.
| szundi wrote:
| So many nice insight. Thanks.
|
| What about a use case when it is inconvenient to create another
| password for a new user base at a company and this way you have
| users without calling support all the time.
| Brajeshwar wrote:
| Fedex have a login with an OTP via email. The OTP expires in
| 15min, while the email came 30+ minutes later. I exhausted the 5
| tries because I keep hitting the button. I had to wait another
| days for an International delivery!
|
| Imagine that.
| asutekku wrote:
| It's inconvenient. That's the primary reason why it won't gain
| mass adoption since any obstacle to your service will lower the
| registration / engagement metrics.
|
| With password managers built into all modern browsers, casual
| users (which, lets be honest here, are by far the most of the web
| users) do not have to worry about typing passwords. Security be
| damned. If it is not invisible to the user, they will reject it.
| _carl_jung wrote:
| Password management is better, not worse, for security.
| elwell wrote:
| What is your argument for that? That people will choose
| better passwords (unique and long) since they don't need to
| remember them?
|
| The Achille's heel of password managers is if someone
| accesses your computer (physically or remotely) they can
| probably access all your accounts. <-- and I've seen this
| happen (not to me)
| kevincox wrote:
| If they can access you computer they can probably also
| access your email and get the sign-in links.
| andrewzah wrote:
| It's much more difficult to compromise someone's computer
| than it is to obtain/get one of their passwords thru
| phishing/guessing and then try the combination on a bunch
| of sites.
|
| It's -vastly- better for casual users to have secure,
| single-use passwords instead of what most casual people do:
| have 1-2 insecure passwords with variations. Thus allowing
| any phisher to get access to everything anyways.
|
| Just because something isn't perfect doesn't mean it is not
| an improvement.
| _carl_jung wrote:
| This is not possible if your password manager itself
| requires a password. Unless you mean "password managers
| don't work because someone might know the master password"
| which is true, but realistically the alternative is just
| using the same weak password all over the web, which is way
| worse.
| jitl wrote:
| If a customer loses access to their email (because they left the
| job or graduated, say), in the email/password world they can log
| in and update the email. In the OTP world the user is screwed.
| lacker wrote:
| The California DMV does this as part of their "upload documents
| ahead of time" system, and it is a terrible experience, because
| they often tell you to wait for an email and then no email
| arrives. What happened - is there a problem with my spam filter?
| Is there a backed-up queue in the DMV software? Do they simply
| consider it acceptable if the email takes an hour to be
| delivered? If you use this method then you really need to care
| about your email deliverability and that is harder than just
| maintaining a regular login process.
| topherhunt87 wrote:
| Tried this recently on a small SaaS app; users complained nonstop
| about the inconvenience of having to switch to their email
| client. One key thing I overlooked is that the service is often
| used in academic presentation situations, where you're trying to
| log into the service on a 10-year-old lectern computer where you
| aren't logged into your email account. I reverted to the generic
| UN/PW approach and the complaints disappeared; passwords aren't
| perfect, but at least they're compatible with sticky notes. Plus,
| users prefer the familiar.
|
| I won't try the one-time-link approach again unless the app's
| specific use case makes passwords extra painful.
| nickjj wrote:
| I think it depends on what the sits is for and how cookies are
| handled.
|
| If your login mechanism sets a cookie after they verify the link
| then they can continue to be logged in for 3 months or however
| long you want. This is similar to what you would do with a
| password.
|
| Also the site type and your audience makes a big difference. I
| wouldn't do it on a site where folks aren't technical.
|
| But for example what about an ecommerce site where customers need
| to register an account + put in credit card details to place an
| order and then they get access to digital goods?
|
| In the above case the lack of password is a benefit because it
| simplifies the payment form. Now they only need to put in an
| email address + card details.
|
| And for getting access to what they purchased a slight delay
| isn't the end of the world. You could even give them access to it
| immediately in some type of unverified way (limited features
| until they verify). Also it's a slight deterrent for account
| sharing.
| mjl- wrote:
| i'm using this approach for a project (for a customer) where they
| don't want their users sharing their login details
| (username/password) with others. so it's a way to keep some
| control over who is accessing the system. the assumption is that
| people won't share credentials for their mailbox with others.
|
| email is still mostly sent as plain text over the internet,
| that's certainly a downside.
|
| email delays haven't been a problem in practice for us.
|
| we also send users notification emails with links going directly
| to the right page, automatically logging the user in. i would
| like that from other services as well, as i'm browsing with
| ephemeral browser containers. having a clean browser environment
| triggers some website (eg github) to verify my login with a
| unique code sent by email. that indicates email delays aren't a
| showstopper in practice at big scale either.
| bronson wrote:
| Some people use mail clients that either preview or spam-check
| links. Every OTP you send them shows up as "already used." Then
| they blame you and not their mail client.
|
| Related, I've consulted for a company that downloads and caches
| every link in every email passing through their corporate server.
| CodesInChaos wrote:
| Since HTTP GET requests are specified as not having any
| significant side-effects, I'd blame your app as well.
| [deleted]
| runako wrote:
| Because it's awful. A normal flow for me is credentials stored in
| browser/password manager. Login is more or less seamless, and
| typically takes under a second.
|
| OTP login is multiple steps, involves me doing a copy/paste (or
| remembering the code), and requires a mandatory delay while I
| wait on the email. If I wanted to login incognito, or in a
| different browser, I may have to copy/paste the URL etc.
|
| A better question is why anyone uses them at all given how bad
| they are. I've stopped using at least one site because it
| exclusively uses OTP links.
| weeboid wrote:
| To truly advocate a position here, first the LCD must be
| reasoned for, which is, "my grandmother", or "cool and always
| drunk uncle", or "xyz frat bro/sorority sis"
| aikinai wrote:
| If you make a new account on Yahoo Japan these days (not really
| related to original Yahoo and extremely successful in Japan),
| they don't even let you set a password; you get an email link
| every time.
| lol768 wrote:
| Monzo do this as their primary authentication mechanism.
|
| No complaints with it.
| habosa wrote:
| Besides what many others have said, I'll add that many low-end
| Android phones are likely to kill your app when the user leaves
| it to go check their email. Which is fine, you can handle it, but
| many apps add a flow like this and aren't ready to be killed in
| the middle of their sign-in flow because this never happens on an
| emulator or a high-end test device.
| code-is-code wrote:
| This. Same happens with the sms verifcation in microsoft teams.
| On older devices switching to the sms app will restart the
| teams authentication process. So you have no chance in every
| typing the correct 2 factor sms key.
| robertlagrant wrote:
| I'd rather that auth apps with a push notification prompt became
| more popular instead.
| jedberg wrote:
| There is a service that I use that uses these. About 90% of the
| time what happens is I go there to use it, get the thing that
| says "check your email!", and then get distracted on my way to my
| email.
|
| By the time I finally get to my email, the link is expired and I
| just give up.
|
| Consequently, I almost never use that service.
| tarun_anand wrote:
| Wow... amazing response to this questions. We have been
| researching this as well for a product.
|
| I am surprised to see that so many people have issues with email
| delivery. Though email delivery can be delayed and in theory
| there are no guarantees.
|
| Have you considered using SMS or a 2FA App like Duo? They should
| be near instantaneous.
|
| The idea of sending this over telegram or signal is a good
| approach though the costs of Whatsapp messaging would be
| prohibitive. Even SMS will not work at scale. So really boils
| down to 2 things
|
| (1) Speed - can you service live with delays or provide an
| alternate? (2) Cost - this cannot be tied to the per message cost
| like transactional or promotional email/SMS. A different pricing
| model help.
| asiando wrote:
| I recently used Vercel's awesome magic link login. The feature
| was so awesome that I just needed to open the link in whatever
| browser.
|
| Unfortunately that also means that if I click the link by mistake
| the bad actor now has full access to my account. All just a
| misclick away.
| dewey wrote:
| > Unfortunately that also means that if I click the link by
| mistake the bad actor now has full access to my account. All
| just a misclick away
|
| Doesn't clicking the link set cookies in your browser that then
| authenticate your session? How would you clicking the link
| somewhere give access to an attacker?
| daveoc64 wrote:
| The link in the email may or may not work that way - that
| would be down to how the authentication system has been
| designed.
|
| Some of them recognise that users aren't always signing in on
| the same device that their email account is set up on, so the
| link in the email just confirms that the login attempt is
| genuine.
|
| This is similar to how Google/Apple/Microsoft/Blizzard/Steam
| handle login requests with their respective authenticator
| apps. You attempt to log in on device X (which can be
| anything), then confirm that the login request is genuine on
| device Y (your personal device).
| GTP wrote:
| From a cryptographic perspective, when dealing with
| authentication the different methods fall in one of the different
| categories:
|
| 1) Something you know (e.g. a password)
|
| 2) Something you have (e.g. a token)
|
| 3) Something you are (usually biometric authrentication, like
| your fingerprint, a retina scan...)
|
| Real OTPs fall in the second category, because you have some
| device/application that is able to generate the same OTP code as
| the server handling authentication _without communicating_ with
| the server. Now there are some popular solutions that are still
| being called OTPs that instead of something you have is something
| that _is sent_ to you, like SMS OTP. This isn 't just quibbling,
| because sending something each time authentication is needed,
| opens up the possibility for some attacks that wouldn't be
| possible with proper OTPs, e.g. SIM swapping. So to answer you
| question:
|
| - Just having to click on a link sent via email has the problems
| outlined in other comments
|
| - having to both enter a password and having a link sent to your
| email address is safer than just enter a password, but
|
| - having a true OTP, like the TOTP standard, is what provides the
| best security (in the category of OTPs, I'm not talking about
| protocols like FIDO2 and similar, because I don't know them).
|
| EDIT: formatting
| squiggleblaz wrote:
| Every system that relies on passwords also provides a password
| reset facility. The facility typically sends a token to your
| email address and allows you to set your password that way.
|
| Doesn't this mean that a system which relies on an token sent
| to you is no worse that a system with a password? With a
| password, you can guess that GTP used the same password on
| Hacker News and BigBank, and if that fails, you can try and
| have their token redirected to you. Without a password, you
| have to rely on getting that token. So if your argument is that
| email and SMS are insecure channels, I mean yeah okay; but it
| doesn't make a system more secure if you can get in with a
| password _or_ an email/SMS vs the only option is an email/SMS.
|
| I hate passwords; my password manager (the one built into
| Firefox) will generate passwords on my desktop, but most of the
| time I need to generate a password it's on my phone (where,
| oddly, they have not included the capacity to generate a
| password). So my password is crap, perhaps not stored, and I
| forget it. I rely entirely on the password reset facility. But
| most of the time if you tell me "please just sign up, think of
| a unique username and a secure password" I'm just not going to
| bother.
| hnlmorg wrote:
| I'm not going to defend passwords, they are a usability
| nightmare. But I'm yet to see a solution that consistently
| works better.
|
| Regarding your problems, it sounds like you're in need of a
| better password manager. I personally use LastPass. I'm not
| saying it's the best out there but I've been using it for a
| few years and haven't felt the need to jump ship yet. The
| advantage of having a 3rd party password manage is that it
| can run on your phone, tablet, laptop and any browsers you
| want.
| squiggleblaz wrote:
| I can run the builtin Firefox password manager on my phone,
| tablet, laptop and any browsers I want :p It would just be
| nice if it supported password generation where I need it
| most.
| hnlmorg wrote:
| Which just emphasises my point that you need a better
| password manager which does support password generation
| on every device. LastPass being one such example.
| squiggleblaz wrote:
| I meant my first comment in jest. I will consider your
| advice, but I imagine switching from one password manager
| to another will only certify me as a genuine and eternal
| password hater. (Also, a password stored in a password
| manager is something you have, not something you know, so
| it's completely inconsistent with the principle of MFA. I
| mean, the reasons to hate passwords just increase as long
| as I think about it. That probably only hurts the
| _theory_ of passwords though, not the practice of them.)
| hnlmorg wrote:
| There is another option if you wish to adhere to the
| principle of "something I know" and that's to generate a
| base64 key. eg SITE="www.example.com"
| SALT="passphrase" printf "${SALT}${SITE}" |
| shasum -a 512 | base64 | cut -c -25
|
| (Though you're better off using some online tool that
| converts SHA 512 to base64 directly since the example
| above converts the ASCII string of a hex representation
| of the SHA 512 hash into base 64. So use that example
| above more as a visual representation)
|
| This will generate a non-reversible password with an
| entropy of 25^64 but it is re-creatable on any system
| that can display a web page and the password is not
| stored anywhere (so it's firmly "something you know"). If
| the password becomes compromised then you change your
| salt and a new unique password will be generated. Thus
| you only need to memorise a small subset of salts rather
| than a password per site.
|
| This was how I used to do passwords several years ago
| before I gave into the convenience of password managers.
| squiggleblaz wrote:
| Yes, I guess that theoretically works. As you say, it's
| much less convenient than abandoning "something I know"
| and just going for a password manager. Which I do.
| usrusr wrote:
| The difference is that the password works as a shortcut for
| situations where the email approach adds lots of friction
| (working on a "guest" device, latency, the entire world spam
| countermeasures). Friction is very much acceptable for
| password recovery (arguably even desirable), but not so much
| for conventional login.
|
| A nice middle ground would be allowing to opt out of
| passwords, for people who are happy with the combination of
| device token plus email OTP. This would work even better if
| device tokens were not binned with all those junk cookies: I
| think it could be valuable to have a class of "qualified
| cookies" that can only be written on user prompt and have
| reads optionally protected by additional local authentication
| requirements (configured on the user prompt), basically
| something that sits right in the middle between the streaming
| heap of cookies a browser stores and the browser's password
| store that allegedly nobody uses. I believe that this could
| be a major win for web privacy, "delete all cookies except
| for those which the store considered important enough to
| depend on a user prompt" (obviously, the client needs to
| include a "pretend to store, but actually keep only for the
| session" option to prevent abuse)
|
| You could almost implement this for a site already using the
| web storage API, except for the unclear client prompts and
| lack of fine-grained tying into additional client side
| authentication measures (e.g. like how you might want a
| password manager to maintain very different master key
| freshness requirements for different entries)
| squiggleblaz wrote:
| > The difference is that the password works as a shortcut
| for situations where the email approach adds lots of
| friction (working on a "guest" device, latency, the entire
| world spam countermeasures). Friction is very much
| acceptable for password recovery (arguably even desirable),
| but not so much for conventional login.
|
| That's a general response to the question of why passwords
| might be nicer than email OTP.
|
| But it doesn't answer my question - namely, any security
| problems that might be attributed to email/SMS OTP also
| exist almost invariably with almost all in-the-wild
| password implementations, and therefore, isn't email OTP
| only more secure than password plus an email OTP called
| "password reset". This question is purely a rebuttal of the
| claim that passwords are more secure than email/SMS OTP.
|
| In the wild, there are a few sites where an email account,
| and therefore password reset, is optional. Hacker News and
| Reddit are examples. But these are in the extreme minority,
| and almost never secure anything worth securing. Bank
| accounts are another class of exceptions, where they secure
| something so valuable it is worthwhile going through a
| human verification process before you can do a password
| reset. But almost everything else - online stores,
| newspaper comment columns, much social media, web apps used
| for work, phone apps that let you monitor your robot vacuum
| cleaner, email accounts - almost all of them expect you to
| have an email address and use it for a password reset
| hnlmorg wrote:
| > _3) Something you are (usually biometric authrentication,
| like your fingerprint, a retina scan...)_
|
| I've always considered them to be more like user names, albeit
| with a larger entropy than your average user string.
|
| Completely agree with your points though. Particularly with
| regards to OTP. I'd further expand on that and say hosting your
| TOTP codes in the same password management tool as your
| passwords themselves (as some tools are now offering) is also
| really bad idea.
| starbugs wrote:
| We have tried this for a while and the following reasons made us
| kill it:
|
| 1. Email delivery latency: depending on the service you use, the
| time it takes to deliver emails to the user can vary. Worst case
| I encountered was up to 20 minutes delay when there were issues
| with Mailgun.
|
| 2. Usability: you have to leave your current app and switch to
| your mail client. You may be on a device where you don't have a
| mail client installed at all, so you have to provide a password
| login option as well.
|
| 3. The sign in dialog gets more complicated and it's hard to
| explain to users how it works as it is not all that common. This
| also had effects on sign up/sign in dialog design which we found
| to have a negative impact on conversion rates.
| krageon wrote:
| From a user standpoint the delivery latency is really what
| kills it for me. I use one or two websites that still have one-
| time sign in links and it's always a tossup whether or not I
| can actually get in within a few minutes. If the email arrives
| an hour later I've moved on with my life and I can't imagine it
| is any different for other people.
| ketamine__ wrote:
| I've experienced that too.
| krageon wrote:
| Then you haven't used it for very long. Besides that, more
| exists than some tech giant's gambit to gather and exploit
| as much user information as they can. Nobody should use
| gmail, unless they are forced to by their job (in which
| case they should try to change it if they are in a position
| to).
| AlchemistCamp wrote:
| What email service do you recommend?
| [deleted]
| jacoblambda wrote:
| The issue isn't with the user's email. The issue is with
| the site's email provider. If the email server sending out
| the one time links is under heavy load or for some reason
| has a backlog, it may take a while for the links to
| actually get to the user.
|
| This usually happens because whatever service the site is
| using to handle sending out emails is under heavy load,
| having issues, or is rate limiting the site due to a sudden
| spike in logins.
|
| If this happens for any reason, it failure cascades because
| the more people try to log in, the longer it will take for
| everyone to get a valid link.
|
| At least with a standard TOTP token or the like, if the
| service is under load it will eventually work if you keep
| trying (versus not working for longer the more people try).
|
| Hell this method also runs into the issue of getting
| flagged as spam or getting blacklisted due to ~~the
| algorithm~~ for one reason or another. This is doubly
| likely if a sudden burst of traffic to a site results in
| them sending out a mass wave of near identical emails.
|
| Now non-tech users can't log in at all since they "never
| get the email at all".
|
| Email is a wonderful thing but it is painfully fragile and
| doesn't handle time sensitive stuff well at scale (due to
| queuing, routing issues, and spam filters).
| gog wrote:
| > The issue isn't with the user's email. The issue is
| with the site's email provider. If the email server
| sending out the one time links is under heavy load or for
| some reason has a backlog, it may take a while for the
| links to actually get to the user
|
| That is not completely true. I've been operating my own
| mail server for almost a decade, since I am the only
| person using it the volume of email I send out is almost
| none.
|
| I've observed on more then one occasion that sending an
| email to my gmail or my fathers gmail account can
| sometimes take 20 minutes or more to show up in gmail
| inbox although I know that google accepted the email as
| soon as it was sent.
| jacoblambda wrote:
| You'd have to look at your logs when it happens but
| google has a habit of tarpitting(i.e. repeatedly delaying
| email receipt) emails from servers they don't necessarily
| "trust". For large providers (i.e. those that would be
| used for handling one-time link emails), this normally
| isn't a problem however for small or self hosted email
| servers it can be from time to time.
|
| I'm not sure what all goes into ~~the algorithm~~ that
| google uses to decide to tarpit emails from a server but
| I'd make sure that you have your SPF, DKIM, and DMARC all
| set up properly to give google as little of an excuse to
| dislike your server as possible.
|
| It's not a great solution but I've long since given up on
| any attempt at self-hosting email and just use my own
| domain with protonmail at this point since the industry
| seems to be so hostile to self-hosting.
| gog wrote:
| Thank you. I've checked my logs and everything looks
| normal on my end and I do suppose it is some kind of
| tarpitting, but it doesn't show in the logs.
|
| I do have DKIM, strict SPF and DMARC policies, MTA-STS,
| SMTP TLS Reporting, latest TLS support and valid
| certificates, there is nothing else I can do on my end.
| jacoblambda wrote:
| One other thing you might be able to try is to try
| reaching out to Google about it if it's a consistent
| issue. There is a contact form floating around somewhere
| for mail server operators to reach out to the GMail infra
| team about this kind of thing but IDK where it is or if
| they even still check it. I wouldn't put to much faith in
| it though, particularly considering Google's reputation
| wrt support.
| leesalminen wrote:
| It's true, we send millions of mails per month and Google
| doesn't give 2 shits about anyone's email deliverability
| issue. All avenues of contact are black holes on that
| front regardless of how much you pay them.
| [deleted]
| medmunds wrote:
| > The issue isn't with the user's email. The issue is
| with the site's email provider.
|
| Actually, it could be either. Postmark (the email
| provider for a bunch of sites) monitors "time to inbox"
| for several user email services:
| https://status.postmarkapp.com/. Apple, in particular,
| seems to frequently add 2+ minute delays on the receiving
| end. (The "source" link above the charts describes how
| Postmark collects the data.)
| conductr wrote:
| > The issue isn't with the user's email
|
| As an email layman, I don't fully buy this, can you
| explain? I've sent emails with multiple CC's and most get
| it quick while one or two people have to wait for it to
| hit their inbox for multiple minutes. I assume they all
| leave my service at same time and the delay is caused by
| the receiving mail server.
| jacoblambda wrote:
| So I'll preface that I'm by no means an expert.
|
| The issue can occasionally be the user's email provider
| but for the most part issues with implementing one-time
| links will be the site's responsibility/a problem on
| their end.
|
| As for email occasionally being super slow, Google and
| Microsoft (to a lesser extent) will tarpit(repeatedly
| delay the acceptance of emails from a specific address or
| entire domain) emails arbitrarily. This normally isn't
| anything meaningfully repeatable and is essentially ~~the
| algorithm~~ arbitrarily deciding it dislikes some certain
| email, email address, or server. Those emails will
| eventually get to their recipient but effectively get
| frozen in time for a bit before getting delivered.
|
| For normal person to person emails, this boils down to
| bad luck and occasional inconvenience however for any
| heavily templated email (like say an email containing
| one-time links), this means something on the site's side
| is causing the emails to appear as spam or spam-like to
| the recipient server. So technically it is the user's
| email server causing the delay but it's usually due to
| something in particular on the site's side be it a domain
| or server configuration or something about the email
| contents.
| [deleted]
| sam_lowry_ wrote:
| Gmail does it to external mail servers as one of many
| mitigation strategies.
|
| I mean, when you send batches of mails to gmail, it lets
| them through first, then depending on its whim it starts
| throttling or outright blocking them.
|
| Once in a while, it changes its handling of DKIM or SPF or
| god knows what and the only thing you can expect from them
| is an SMTP error message.
| justusthane wrote:
| Yeah. In theory it's a neat idea--in practice I hate it.
|
| There's one service that I literally can't log in to because
| the link has always expired by the time I receive it.
| wruza wrote:
| >sign up/sign in
|
| Why were clear terms like login/register/logout replaced with a
| "sign ..."? I get confused twice a week by these, especially
| because the difference between "in" and "up" is so subtle (and
| overloaded, like "sign up for a meeting at friday", unrelated
| to registration routine). Sorry for offtopic, but it is really
| annoying. Is it more linguistically correct or just a hipster
| thing?
| jjoonathan wrote:
| > "sign ..."
|
| Sometimes literally that, with an ellipsis hiding the part
| that would otherwise distinguish between alternatives, so you
| just have to click and guess.
| combatentropy wrote:
| Interesting. I've always liked "sign up", "sign in", and
| "sign out", because they were older and more widely used
| before computing. "Sign up" was used to refer to subscribing,
| for example, to a magazine. "Sign in" and "sign out" were
| what they said for the guestbook at a hotel.
| gjvnq wrote:
| I usually prefer the terms "sign up" and "log in" as they are
| different enough to avoid confusion.
| samb1729 wrote:
| I'm not sure they were ever replaced; the terms co-exist. I
| believe the terms all stem from the general concept of
| writing a name on a piece of paper.
|
| To "register" your interest in an something, you might sign a
| piece of paper, or instruct a person to "sign [you] up".
|
| To show that you entered a physical event, you would sign an
| entry log on a piece of paper, then having "logged in" or
| "signed in", and then do the opposite on your way out.
|
| Similarly you might refer to reproducing your physical
| signature as having "authenticated" yourself, if there's
| something to compare it to.
|
| What makes one particular set of terms the right set given
| the apparent origins?
| codingclaws wrote:
| I researched this several years ago and for various reasons
| it's best to use: sign up, log in, and log out.
| appleflaxen wrote:
| can you elaborate on the basis for this? it sounds
| interesting, but the rationale isn't obvious.
| nwienert wrote:
| One more: Gmail app on iPhone forces you to open links within
| the app, meaning you can't actually login with Safari proper
| (the session/cookies aren't shared).
|
| Super frustrating, and something Apple should clamp down on
| (any app that opens web links needs to provide a full "open in
| Safari" option that isn't an in-app browser).
| skohan wrote:
| regarding point 3, I feel like familiarity bias is such a
| difficult thing to overcome sometimes with UX. However poor the
| experience of the standard signup/auth process is, users have
| already learned the complexity, and the risk is super high when
| you're showing people a totally new type of hurdle they have to
| jump to access your product. Even if it's less complex
| objectively, if they fail the first time there's a high chance
| that user is never coming back.
|
| But I think authentication in general is a problem which really
| needs to be solved, and in a standards-based way. For instance,
| with connecting to public wifi networks (i.e. at an airport),
| it's absurd to have to go through a web page every time to log
| in. Also with the proliferation of IoT devices, it's always
| painful to go through the process of connecting it to my
| bluetooth and/or wifi. There should be some kind way to handle
| trust systematically through my smartphone without having to
| manually type a bunch of passwords.
| jeswin wrote:
| 4. Gmail (atleast on Android) will try to open the link in a
| sort of Webview, which is never ideal. All the browser options
| are gone, plus I don't need to trust Gmail with the ability to
| read screen contents.
| p49k wrote:
| This is exactly the reason why I hate sites that use one-time
| email sign-in links. The link opens in Webview, then you have
| to click a separate button to reopen the page in Safari, but
| by that time the token is marked as used, so you can't login
| except in this temporary window that is going to immediately
| disappear the second you perform any other action.
| codethief wrote:
| If I may add:
|
| 4. Some email clients still break links in emails
|
| 5. Proper links require HTML; otherwise you rely on the email
| client recognizing a URL as such (which brings us back to 4).
|
| 6. The email might mistakenly get recognized as spam.
| roseway4 wrote:
| (1) is tractable. A number of email sending providers offer
| SLAs around delivery latency. Some also provide significant
| deliverability resources to help senders mitigate the risk of
| spam foldering.
|
| Source: I work for SparkPost and we do all of the above.
| codethief wrote:
| > 1. Email delivery latency
|
| This is particularly true when the recipient has enabled
| Greylisting[0] and delivery has to be attempted multiple times
| (which is perfectly fine from the point of view of the RFC
| standards). In view of this, email delivery rather resembles
| real-world postal package delivery (and not so much the
| instantaneous delivery of, say, phone calls).
|
| [0] https://en.wikipedia.org/wiki/Greylisting_(email)
| ytch wrote:
| Is it possible to solve by some kinds of warming up? AFAIK
| greylist is IP-based. We can send email at regular time so
| all the sender IP can keep in list.
|
| But email does has many uncertainty like spam detection and
| others to slow the process after SMTP server receive it.
| jethro_tell wrote:
| How would that work? Send an email to every customer
| (domain, so pick a single customer at every domain) and
| send them an email with a fake login, or a note that says
| please disregard?
|
| Aside from that being spam, it's also likely to get legit
| emails stuck in spam filters as people start marking them
| as spam.
|
| Secondly, I think most of the largest providers don't
| really grey list any longer. They seem to have moved to
| inbound throttling. So your first email goes through but
| then if you send a rash of mail, you end up seeing the
| throttle on the back side.
| iggldiggl wrote:
| This can be particularly fun if the sender uses Amazon SES
| for example, because Amazon randomly rotates through its mail
| servers on each retry attempt, so a simple greylisting
| implementation (based on exactly matching the full IP) delays
| the mail by not just one, but possibly multiple retry
| intervals until by chance Amazon happens to use to original
| server again.
|
| So you either need to whitelist Amazon SES (and possibly a
| few other providers behaving similarly), or use a greylisting
| implementation which doesn't match the _full_ IP (I think
| Mailcow by default e.g. uses /19 for matching IPv4
| addresses).
|
| A previous mail hoster of mine did the former, i.e.
| Greylisting based on the full IP, and what was even worse,
| their support staff totally denied any knowledge of it and
| tried to claim it wasn't their fault that any e-mails from
| Amazon (Amazon itself and anything using SES) would arrive
| with random amounts of large delay.
| jjeaff wrote:
| And don't forget the security implication that someone with
| access to your email can log in to your account undetected.
|
| With traditional password reset by email, at least when I try
| to login next, my password won't work and I'll know something
| might be up and can change my email password.
| innocenat wrote:
| I resonate deeply with this comment.
|
| As an extension to your second point, sometimes I want to login
| to a service on a shared/public computer out of necessity. I'd
| really not want to login into my email on said computer too.
| Nemo157 wrote:
| A good one-time-sign-in-link implementation will send a link
| to authenticate a session elsewhere, so you can click the
| link on your phone to complete login on the computer.
| szszrk wrote:
| That's kind off what Microsoft does in Microsoft
| Authenticator. It doesn't ask for password, it sends
| notification to you phone app and asks you to tap "65". The
| app then shows 3 numbers, one is 65. You log in on the
| other device after tapping. No passwords entered at all.
|
| They did a nice job on that one.
| gfodor wrote:
| We did this for Mozilla Hubs (hubs.mozilla.com)
| specifically so people can easily sign in from within a VR
| headset which doesn't have a password manager and which is
| hard to type in.
|
| However, the problem is that this goes so much against user
| expectations it just confuses people and they end up going
| through the grueling version of typing the long link in by
| hand in VR since they can't imagine it could be as easy as
| opening it on their phone. (We of course, call this out in
| the prompt, but nobody reads that.)
| arminiusreturns wrote:
| As a counterpoint to this, I quite dislike this approach,
| especially when the auth is a link instead of a OT2P,
| because now whatever I am accessing has metadata and can
| cross-correlate data from other providers about my phone.
| Amazon is one in particular that I experience, and I never
| click the link, and rather just type it out by hand on the
| system I am already trying to log in via.
| cesarb wrote:
| That assumes the user can click the link on the phone. The
| reason a user might be "using a shared/public computer out
| of necessity" might be because the user does not at that
| moment have working Internet on the phone. For instance,
| the user might be outside the home area without a roaming
| agreement, or the user might be out of prepaid credits on
| the phone.
| sam_lowry_ wrote:
| What if we just allowed sending one-time links not only via
| mail, but via Telegram, Whatsapp, Messenger, Signal and a
| bunch of other options?
| cuu508 wrote:
| I just assume my every keypress on a public/shared PC gets
| keylogged, so a password is not a great option either.
| ss64 wrote:
| 20 minutes delay! Ha my worst is about 10 days.
| starbugs wrote:
| I guess we got lucky then? It doesn't seem to make a big
| difference though. After a couple of minutes most users
| considered the login attempt failed in our cases.
| camhart wrote:
| 4. Email delivery period. Using AWS Simple Email Service,
| you're actually sharing an email server IP address with other
| accounts. At times those accounts can get the IP address added
| to spam lists. All the sudden your emails stop getting received
| on some clients.*
|
| * Solution to this is to pay $$ / month to get a dedicated IP
| address, then never let it get added to a spam list.
| starbugs wrote:
| We ended up purchasing a dedicated IP from Mailgun. This
| solves the spam/latency problem mostly, but brings about new
| problems.
| albertgoeswoof wrote:
| What other problems do you face with a dedicated IP?
| petercooper wrote:
| Not MailGun, but we have 3 dedicated IPs with SendGrid
| and one problem is that there are spamlists and ISPs that
| block or mark down IP blocks owned by SendGrid so you get
| no real advantage from the dedicated IP. I wish you could
| "bring your own IP" to these services.
| jethro_tell wrote:
| Heh, it would get tagged as a sendgrid ip after a few
| transactions.
| starbugs wrote:
| You have more management work for your team. If
| something's wrong with it, it's mostly your problem.
|
| I initially thought it was a "problem solved" thing by
| paying the money. Ended up causing us regular work (not
| much, but still).
| albertgoeswoof wrote:
| Dedicated IPs aren't great because they're completely
| untrusted. Better to sign up with a smaller email provider
| than mailgun/ses
| RulerOf wrote:
| SES warms up dedicated IPs for several weeks by using them
| for regular SES traffic during the warmup phase: https://do
| cs.aws.amazon.com/ses/latest/DeveloperGuide/dedica...
| sethammons wrote:
| I work with Twilio SendGrid. What do you mean? IPs are the
| de facto way that reputation is tracked and a dedicated
| IP's trust is based on your sending habits. How would a
| smaller provider be better? The only thing that I can think
| is similar IP ranges can also influence delivery, so you
| may want a dedicated range for transactional email. I don't
| see smaller providers as able to do that.
| albertgoeswoof wrote:
| A new dedicated IP is unknown and some providers will
| automatically treat it as untrusted and give it a lower
| score.
|
| A smaller email provider can give you a shared IP that
| has other users and is therefore already whitelisted.
| Provided the email provider has good anti-spam approaches
| (e.g. enforced DKIM verification), you should have better
| luck with that shared IP over a dedicated one if you only
| send a few thousand emails a month.
| sethammons wrote:
| ah, I see what you are saying. Better shared pool
| management by the larger senders would help, but a
| smaller sender should be able to more aggressively
| protect their shared IPs; I agree in principle. This is
| extra important for infrequent sending.
|
| I still contend that a dedicated IP is superior for
| deliverability reputation as long as you are sending
| enough email. For a brand new (to you) dedicated IP, it
| will need to be warmed up (gradually increase the amount
| of traffic it sends). There are automated and manual
| processes to accomplish that, including "pre-warmed"
| dedicated IPs that were previously in a "good enough"
| shared pool.
| iggldiggl wrote:
| > 4. Email delivery period. Using AWS Simple Email Service,
| you're actually sharing an email server IP address with other
| accounts.
|
| They also randomly rotate through their mail servers on each
| retry attempt, so a simple Greylisting implementation based
| on matching the full IP address can delay your emails for not
| just one retry interval, but several (until by chance Amazon
| happens to reuse the IP of the original delivery attempt).
| swiley wrote:
| One more issue is if you're using eg microsofts webmail
| (office? hotmail? I'm not sure what it's called but my
| university had it) the links will get queried automatically to
| "scan them for viruses" which tends to expire them.
| ngrilly wrote:
| I ran exactly into this problem with linear.app (which uses
| passwordless login with "magic" links) and Outlook / Office
| 365. Only solution has been to ask linear.app to disable the
| links for our account and keep only the one-time code that we
| manually copy-paste.
| fredcy wrote:
| We ran into this, where the Outlook client would scan one-
| time login links from SalesForce (iirc). Huge pain to work
| around.
| stemlord wrote:
| It means I have to go sign into my email account just to retrieve
| the OTP to sign into this other account.
| ch0I9daAiO wrote:
| Losing your email or domain would also be a problem.
| MattGaiser wrote:
| It's irritating and would clog my inbox.
| numbsafari wrote:
| Take all the time and energy you will put into this and instead
| invest in making sure your sign-up and authentication flows work
| with popular password managers.
| shireboy wrote:
| I know a guy who as a matter of course sets his passwords to long
| random strings. When he wants to log into something, he then uses
| the sites' "forgot password" as his "OTP" to assign a new one,
| log in with it. He does not store the random string, so his
| password is random, he doesn't know it. Sounds like a lot of
| trouble, but my point is "forgot password" can kinda be otp for
| those paranoid enough.
| motohagiography wrote:
| Given a scheme is only ever as secure as its recovery process,
| he's not wrong.
| weeboid wrote:
| OTP, with extra steps :D
| newscracker wrote:
| This is fine until a platform or service decides to lock his
| account or permanently disable it because of frequent password
| reset attempts. If he's lucky, he may be able to use a phone
| number connected to the account to get in. If not, then that's
| the end of it. Seeing the kind of login patterns that many
| sites track for security reasons and how bad their judgments
| can be, I personally wouldn't take such a risk.
| Willamin wrote:
| I wonder why SSL Client Certificate Authentication hasn't become
| popularized for the web.
|
| 1. Browser visits a site that needs authentication. 2. Browser
| checks if there's already an existing client cert. 3. If not,
| browser generates one. 4. Browser uses it in the SSL handshake,
| resulting in the user being signed in without passwords, cookies,
| email links, etc.
| corrys wrote:
| Perhaps one the main reasons is that a large number of people
| use multiple devices or even multiple browsers on the same
| device. Not sure how SSL client certificate authentication
| accommodates that.
| aarroyoc wrote:
| It's the way Spanish government webapps work with the citizens
| but it's a bit confusing to be honest. When it works it's
| perfect but the setup is complicated, so they're introducing an
| optional user/password login also.
| theandrewbailey wrote:
| UIs to use client certificates are terrible, and key and
| certificate storage almost always involves a password anyway.
|
| My day job occasionally involves a WebDAV server protected with
| a normal login plus a client certificate. Sometimes I need to
| explain the process to less technically literate people who use
| different client software than I do, and the certificate part
| is a total pain.
| jon-wood wrote:
| Because the UI for managing client certificates is _terrible_ ,
| with no real support for distributing a cert to multiple
| endpoints unless you're in an enterprise environment with
| device management, or issuing smart cards and readers. I do
| think there's legs in client certs for enterprise
| authentication, but for consumer products it's a non-starter.
| jchook wrote:
| I wonder if this is something that cloud password managers
| like 1Password could tackle.
| gfodor wrote:
| Isn't the problem with this that it means your account is tied
| to your browser install? Eg, you'd need to copy the cert to
| another machine to sign in, would need to ensure it's backed
| up, etc.
| randomdata wrote:
| Password management already is to basically that extent and
| the tools to copy that information around, backup, etc. also
| have come into existence to support usage beyond a single
| browser install.
| gfodor wrote:
| That's half true, password management piggybacks on top of
| a system which doesn't have these characteristics, so it
| means no special work needs to be done on the development
| side to support them, and it's activation function is only
| determined on one side of each edge (the user side.) For
| this cert system to work, you have a bit of a chicken-and-
| egg problem since it requires both sides of the user-
| service graph to have done work pre-emptively to support
| it.
| hkt wrote:
| It would be really, drastically lovely if that were to happen.
| For bonus points, encrypt the client certs with a master
| password and sync between a user's devices.
| indymike wrote:
| Email and sms are prone to delays that make the experience bad
| for users.
| bravoetch wrote:
| It's unpopular because it doesn't solve user issues. It solves
| vendor or engineering issues.
| jwr wrote:
| Oh, this is so terrible. I hate this approach with a passion.
|
| E-mail is NOT INSTANTANEOUS. It was never meant to be. It happens
| to arrive quickly for most people most of the time, but you
| should never, ever, base a service on that.
|
| Many systems have greylisting in place: a new sender gets a 4xx
| reply, and is allowed through only on subsequent retries after a
| pre-set time period. This is often as much as 30-60 minutes. It's
| a good approach to reduce spam, it turns out a lot of spamming
| software does not bother to retry, or doesn't want to incur the
| cost.
|
| So, if you try this OTP-over-Email approach, you end up with
| frustrated customers, who 1) have to wait up to 60 minutes, 2)
| their OTP doesn't work, because you expired it after 5 minutes.
|
| It's terrible. Don't do it.
| jiofih wrote:
| Email has been nearly instantaneous for me for the past decade
| or so. Either it arrives in a 30 second window, or never.
| Usually 2-5 seconds.
| bryanrasmussen wrote:
| email is supposed to be dependable - as a protocol - it
| should always arrive. This dependability comes at the price
| that in some edge cases it must arrive slowly. There should
| be no 'never' arrive, although I realize that many services
| now effectively keep email from actually being seen by the
| user in the name of combating the various problems a free,
| anonymous, dependable message delivery protocol inevitably
| give rise to.
| sethammons wrote:
| I run an MTA sending billions of emails daily. Most mail is
| delivered in seconds, but there is a long tail that can take
| days (myriad of reasons involving recipient mail servers,
| dns, sending behavior , etc). It would not be fun to have
| your log in attempt come in a couple days later. 99.9%+ you
| will be just fine, but how do you handle those people who
| fall through into long-delay land?
| jwr wrote:
| That's great, good for you! But E-mail is not guaranteed (nor
| designed) to be instantaneous.
| Macha wrote:
| I have both a personal G Suite domain (formerly "Google Apps
| For Your Domain") and my employer's G Suite account where in
| both cases I've experienced 5+ minute delays on a semi-
| frequent basis.
| samb1729 wrote:
| > (formerly "Google Apps For Your Domain")
|
| And now formerly G Suite, as it's become Google Workspace.
| Gotta keep that "products rebranded per decade" quota up,
| it seems!
| da_big_ghey wrote:
| Thirty seconds is not instantaneous and is much slower than
| typing a password. The only server that shows mail the
| instant it's sent is the one I run for my personal use, which
| is a bad solution for most.
| hrktb wrote:
| "never" doesn't feel instantaneous though.
|
| Joking aside, email never coming is a pretty common occurence
| for me on new services, especially small orgs (local clubs,
| small merchants)
| wruza wrote:
| Why can all instant messengers do this "instant" part and email
| cannot? I'm aware of mta chains, decentralization, etc, but
| heck.
| Someone wrote:
| Because, as _jwr_ says, it was never meant to be. The mental
| model is that of regular mail that gets collected at post
| offices, then split by major destination, sent on, and
| finally ends up in a mailbox.
|
| Mail servers do not even have to be on the internet
| (https://en.wikipedia.org/wiki/Non-Internet_email_address),
| or on a network at all. It was fairly normal to have a time
| sharing system dial in to a mail server every day for a few
| minutes to exchange mail messages
| (https://en.wikipedia.org/wiki/UUCP#Mail_routing))
|
| Also, of course, it is harder to accomplish in a
| decentralized system that isn't controlled by a single party.
| jwr wrote:
| Excellent points. As someone who has carried UUCP mail on
| floppies to computers not connected to the network at all,
| I can relate :-)
| snarf21 wrote:
| Right, it isn't authentication, it is only account control. If
| you have to login to your email anyway. We just need simpler
| 2FA options. FIDO is moving the ball forward in the right
| direction but they don't seem willing to push the final steps.
| riedel wrote:
| Funny that SMS second factor auth took off. I remember that the
| sometimes hour long delays in SMS .
|
| I actual was astonished by the simplicity of sign in links when
| for the first time using gather.town . I have seen then also in
| banking (revolute) with IP address pinning which proved to be
| annoying because this randomly switched depending on network
| availability.
| progval wrote:
| As a user, I have the same issue but in the opposite direction.
| My greylisting config requires only 1 minute wait, but many
| providers only retry after 5-10 minutes.
|
| Usually I can request a new login (or email verification) link
| and it will go through immediately. It does not work with
| Sendgrid-based services though, as Sendgrid rotates the IP used
| by the service for every mail.
| j45 wrote:
| A consideration I see is the tradeoff between security and
| convenience.
|
| Where email appears as a push notification on an imap idle
| configured email account, email can be far more unreliable, even
| with the best transactional email services.
| factsaresacred wrote:
| Friction I guess. Having to open a new tab...wait seconds(!) for
| the email to appear...click a link which opens another tab.
|
| Nah, just let a password manager handle it.
| huhtenberg wrote:
| One-time links are invalidated by various automated scanners that
| "check" emails upon arrival, including visiting all contained
| links. This is very common in enterprise setups.
| mihir6692 wrote:
| Authenticators are much better options then email links if
| service wants to go for password-less login.
|
| P.S. authenticators have their own problems too just like E-mail.
| :D
| emidln wrote:
| Scryfall.com (a Magic the Gathering search engine and deck
| building site) does this and the experience is very nice. I'd
| have to check, but the session Scryfall uses feels pretty long. I
| rarely, if ever have to authenticate again on the same
| browser/machine. This would likely be more annoying if I had to
| do it every day.
| OJFord wrote:
| As a user, I hate it, it's a PITA, why be different, 'everyone'
| 'understands' passwords, we expect them.
| Veen wrote:
| > why be different
|
| Because, although everyone understands passwords, they have
| security and customer experience issues:
|
| - Users choose easily guessed passwords and get hacked.
|
| - They use the same passwords on multiple services and get
| hacked.
|
| - They forget passwords, requiring an email reset, so they need
| to access their email anyway.
|
| - The service doesn't need to store and manage passwords.
|
| Every authentication method involves tradeoffs, and the service
| has to decide which set of tradeoffs they prefer. Personally, I
| prefer passwordless logins, but I understand why they're
| annoying for some.
| ffpip wrote:
| Notion [1] used to do this. It is pretty bad for signing in. You
| have to be logged into your email, wait for a six digit OTP and
| then use that for logging in.
|
| [1] - https://notion.so
___________________________________________________________________
(page generated 2021-01-04 23:02 UTC)