Is multi factor authentication practical/feasible?

Michael Slusarz
Thu, 14 Jul 2022 17:12:44 -0000

> 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.