> On 07/07/2022 01:12 EEST Michael Peddemors <michael at linuxmagic.com> wrote: > > > On 2022-07-06 10:17, gene heskett wrote: > >> As far as I can see from what I tested today (mainly switching my > >> Thunderbird from "Normal Password" to "OAuth"), Clients effectively > >> *have* to be "also a browser" (rendering the HTML for O365's login > >> prompts, accepting and sending user input, storing the OAuth token as > >> a HTTP cookie) to be able to do that. SMTP remains exempt from the > >> requirement for now, on the theory that printers and the like may want > >> to use it, and not be up to implementing the new stuff. (Otherwise, > >> MS' position can be summarized as "our clients work great, Thunderbird > >> succeded in implementing it, if your client doesn't, go nag the vendor".) > > > > And one more time we have allowed a sworn enemy to set the standard, > > shame on us. > > Getting a little off topic, but yes.. I believe Dovecot also sees the > threat for all it's users, if authentication processes are forced in a > direction that only favours the big three. > > Which is why I hope it gets more open with allowing 3rd parties to > contribute to Dovecot as plugins, that support other methods of 2FA.. > > Sworn Enemy? Not if you have shares in your 401k/RRSP they aren't. > These are smart business moves to consolidate the market for them, which > in turn means stock prices go up. > > But it will be a terrible world, if interoperability between independent > email providers, and the big three area threatened, or if they are > forced to 'drink the koolaid'. > > But it is nice to see products like Thunderbird and other supporting > alternative means of 2FA, just like to see Dovecot support them as well > natively, or through plugins. > > Just my two bits.. > >FWIW I think OAuth2 is the modern way to do actually MFA authentication. There is some progress in Mozilla world (and hopefully other mail clients) to allow OAuth2 to work outside the "big three" circle. Mostly this is *client development issue*, the server-side already mostly supports all the bits you need to roll your own MFA with OAuth2 using off the shelf components. No need to pay microsoft or google. Alternate to OAuth2, which works pretty well today, is to use device passwords. Also, Michael's code that we would love us to merge, will possibly some day be merged, and hopefully he will provide the client-side of it to benefit the community too? Aki
> On 07/07/2022 5:24 AM Aki Tuomi <aki.tuomi at open-xchange.com> wrote: > > FWIW I think OAuth2 is the modern way to do actually MFA authentication. There is some progress in Mozilla world (and hopefully other mail clients) to allow OAuth2 to work outside the "big three" circle. Mostly this is *client development issue*, the server-side already mostly supports all the bits you need to roll your own MFA with OAuth2 using off the shelf components. No need to pay microsoft or google. > > Alternate to OAuth2, which works pretty well today, is to use device passwords.A bit late to the game, but wanted to expand a bit on Aki's comments. It's good that this topic is being discussed. We've long felt that email authentication (and, related, client auto-configuration) is one of the biggest weaknesses of email as compared to more "modern" messaging technologies. However, discussions around this topic tend to get sidetracked as everyone wants to try to design their own technical solutions. However, all the necessary technologies exist and are standardized. Token auth is handled by OAuth2. MFA ,and more generally authentication UI, is handled by OpenID Connect. At the mail protocol levels, token auth is handled by SASL. Additionally, SASL supports auto-discovery of authentication providers so there is no need to "hard-code" OAuth2 providers (the unfortunate way that some clients are currently handling OAuth2). Dovecot supports all of these technologies already, so there's nothing left to do on the server side. (Side note: client auto-configuration is also already fully supported using existing technologies as well.) Instead, the issue is chicken/egg - all of this is worthless until clients/providers start implementing this. That's where the focus of efforts need to be, not in trying to determine which technologies to use. Admittedly, this not insignificant paradigm shift can be a bit confusing technically. It's been a long-standing TODO to create some kind of implementation guide to help server/client/auth providers to understand what they need to do to create this new "modern email authentication" ecosystem. This is a classic example of a situation where necessary standards exist, but the education about these standards are lacking AND there remains open questions about how those standards should interact with each other in real-world scenarios. Dynamic client registration in OpenID Connect, in particular, is a key component to make this work but is somewhat under documented and lesser known, so it will take community involvement, and likely trial and error, to determine best practices. TL;DR from a Dovecot perspective: we feel we have all the necessary components needed to enable "modern email auth" in the current product, so we don't see any additional engineering efforts needed in Dovecot. We instead are focusing our attention in building and supporting a broader community of client authors and authentication providers to push for implementation in order to accomplish the goal. michael p.s. As mentioned by Aki, app-specific/device passwords is a perfectly acceptable solution, although a bit of an end-user usability nightmare. It's a hack to improve security today, but not a proper long-term answer.