On 27.06.22 00:52, Steve Dondley wrote:> I have a small client whose insurance company insists they have MFA for their email to be covered under some kind of data protection policy. Currently I have the client set up on a Debian box for the email server coupled with roundcube for webmail. Most the users just use roundcube but some also use their mobile devices to check email. Maybe one person uses outlook. There?s about 5 to 10 users total. > > I know roundcube offers a MFA plugin. But I don?t have the foggiest idea how of an iPhone, Android device, or Outlook could all be set up to work with MFA with a standard dovecot/postfix setup. Are there any practical solutions for easily implementing MFA that could work across multiple devices?*Totally* theorizing here, but as far as I'm aware, the SMTP (AUTH), POP, and IMAP protocol definitions do not provide elbow room to make *two* rounds of authentication. (Ever pondered why the admin can require O365 users to "use 2FA", but users then are still allowed to create "application passwords", note plural and lack of standard password features like a limited lifetime for those?) If I'm correct with that, and if you have to provide these protocols, there are three options: 1. Users need to roll their memorized password and an OTP from a token into *one* combined password they enter (seen that in some early 2FA implementations when CLI/GUI login procedures did not yet have support for multiple rounds built in) 2. User needs to enter his "password" (PIN, actually) into the *token* to make it spit out a (valid) OTP, and *that* is then the "password" he sends to the servers (some people will insist that this "is not 2FA") 3. Servers/backends have a way to communicate with the token directly (ideally so that the user gets the password-to-enter via the token, say, per SMS, but for *that* to work out, you need that *every* piece of software used is willing and able to forward the info "user X wants to make an attempt at auth" *before* it also has the password at hand) Good luck, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: <https://dovecot.org/pipermail/dovecot/attachments/20220701/2941573d/attachment.bin>
Quoting Jochen Bern <Jochen.Bern at binect.de>:> On 27.06.22 00:52, Steve Dondley wrote: >> I have a small client whose insurance company insists they have MFA >> for their email to be covered under some kind of data protection >> policy. Currently I have the client set up on a Debian box for the >> email server coupled with roundcube for webmail. Most the users >> just use roundcube but some also use their mobile devices to check >> email. Maybe one person uses outlook. There?s about 5 to 10 users >> total. >> >> I know roundcube offers a MFA plugin. But I don?t have the foggiest >> idea how of an iPhone, Android device, or Outlook could all be set >> up to work with MFA with a standard dovecot/postfix setup. Are >> there any practical solutions for easily implementing MFA that >> could work across multiple devices? > > *Totally* theorizing here, but as far as I'm aware, the SMTP (AUTH), > POP, and IMAP protocol definitions do not provide elbow room to make > *two* rounds of authentication. (Ever pondered why the admin can > require O365 users to "use 2FA", but users then are still allowed to > create "application passwords", note plural and lack of standard > password features like a limited lifetime for those?)I implemented PrivacyIdea as a backend auth mechanism for dovecot once in the past. I honestly don't recall the details, and I wasn't sure how to do it dynamically with multiple domans, but one domain worked fine.? It was due to the PI 'realm' separator being @, and using full email addresses for the username.? I believed I used OTP for the user's webmail password and 'device password' for imap/smtp. Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20220701/c6cc5c65/attachment.htm>
On 7/1/22 1:02 PM, Jochen Bern wrote:> On 27.06.22 00:52, Steve Dondley wrote: >> I have a small client whose insurance company insists they have MFA >> for their email to be covered under some kind of data protection policy. > *Totally* theorizing here, but as far as I'm aware, the SMTP (AUTH), > POP, and IMAP protocol definitions do not provide elbow room to make > *two* rounds of authentication.What Jochen said. The protocols were designed long before SAML and OIDC. SAML/OIDC give you more control over authn/z and allow easily adding in MFA or other different types of auth. To do this right, you'd need to extend the protocol to allow OIDC or SAML. As some have noted, you can shoehorn it in. But I would not recommend doing that. Adding security as a bolt-on ad hoc usually has holes. But if you really wanted to do this, I'd suggest something like: * Extend dovecot to use an OIDC access token instead of a username/password. * Set up an IDP with your connection, defining credentials as well as MFA info * Set up the IDP with an API - this is the API for generating the access token used by dovecot * Extend Thunderbird or your mail app to use the IDP to get the access token, then use that to connect to Dovecot. So this sounds kind of cool to me. If you want a little help setting it up with Auth0, ping me off list. John -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20220703/5e53e053/attachment.htm>
On 01.07.22 20:02, Jochen Bern wrote:> *Totally* theorizing here, but as far as I'm aware, the SMTP (AUTH), > POP, and IMAP protocol definitions do not provide elbow room to make > *two* rounds of authentication. (Ever pondered why the admin can require > O365 users to "use 2FA", but users then are still allowed to create > "application passwords", note plural and lack of standard password > features like a limited lifetime for those?)On 04.07.22 21:29, Michael Peddemors wrote:> The only problem is, having looked at several of these insurance > companies forms, it is almost as if a o365 sales person wrote the requirements.On 04.07.22 22:23, gene heskett wrote:> This seems to be a place where the ITEF (IETF?)has seriously dropped > the ball. They do not well understand the chaos that will be created if > THEY do nor set a cast iron std that even Redmond can follow or go home. > I don't think we can scream that too loud if THEY don't get off the dime > and do something toward setting a standard.Speak of the devil ... Today, our company got hit by the 48h-unless-your-admins-abort-it-for-NOW rolling outages O365 does as an (un)friendly reminder that (what THEY call) "Basic Authentication" will be disabled on 01-Oct: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online#re-enabling-and-opting-out-of-proactive-protection Apparently, they already wrote and published standards on how the world shall introduce "Modern Authentication" (OAuth 2.0) into protocols like POP and IMAP: https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth 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".) I wonder when our ticket systems apparently ceased handling e-mails (via SMTP *and IMAP*) outside our office hours so as *not* to qualify for a similar exception. Please excuse me for the rest of the day, I need to incinerate a neighbor-of-Nintendo-shaped effigy at today's company BBQ ... Regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: <https://dovecot.org/pipermail/dovecot/attachments/20220706/f036b970/attachment-0001.bin>