Is multi factor authentication practical/feasible?
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?
On Sun, Jun 26, 2022 at 06:52:05PM -0400, Steve Dondley wrote:
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.
I'm currently vague on whether/how these can be integrated with dovecot/postfix, but ...
Are there any practical solutions for easily implementing MFA that could work across multiple devices?
... there exist several cross-platform hardware tokens:
and time-based one-time passwords ("TOTP") are also cross-platform:
Please update the thread if you make any progress. Thanks!
Sam
I don't see why not.
Dovecot and Postfix are entirely configurable to connect to and use any desired authentication mechanism through certain basic interfaces.
The main problem I have experienced with MFA is a continual battle with extortion, "long cons," and thievery in law -- that the thieves are able to obtain one of the necessary factors for authentication -- a dongle or cell phone app or access to a cell phone number, or surveillance intelligence on calls or texts, whatnot -- whether by force or deception -- and then deny the targeted individual access to his or her own account.
Later on, after the victim has given up, the thieves are able to obtain the other factors for authentication, and then proceed to social-engineer a false account recovery using the victim's stolen I.D. -- and then they often as not falsely report the victim to gullible or complicit police forces as the thief.
If the victim cannot be successfully accused of theft in court, the "thieves in law" at work with inside help in government and law enforcement communities are able to cast identity theft as a mental illness akin to dissociative identity disorder -- to which the government offers nothing but a mental health "recovery" plan which does not include any actual recovery of the stolen assets in a person's name.
Casting identity theft as a mental health issue further enables thieves to take control of a victim's finances by possibly being appointed as guardians or payees in court. For the same reasons of legalized theft, extortion, and wrongful appropriation through state, local, military and federal court systems, individuals with similar names to known criminals are not allowed to hold significant assets in their names or possess firearms or obtain employment in sensitive positions in the United States.
On Sunday, June 26, 2022 2:52:05 PM AKDT, 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?
It IS possible to use 2FA on Dovecot, but it would be better if Dovecot supported options by Plugins to control what supported 2FA options are supported in the CAPABILITIES string. (Ongoing problem getting more power in the handles of 3rd party plugins for Dovecot, politics.. )
HOWEVER, there are many ways if you 'roll your own' dovecot, eg can apply patches to the build process. We do this.
Having said that, yes.. especially in North America this push by insurance agents for 2FA, is driven by the RansomWare problems, and gives an insurance company a way out..
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. And even IF you apply a 2FA, (eg a 2nd factor) you might find that the insurance documents will not accept anything other than what their legal department defined as 2FA..
The biggest problem, is not the use of 2FA, it is making 2FA transparent and simple enough for end users to adopt. End users don't want to mess with a second factor they have to add, or a hardware dongle, or giving their cel# out..
And the industry has to come together, otherwise you will quickly find out insurance companies ONLY accept 2FA from one or two closed source companies..
Which is why once again, I wish that Dovecot would take a leadership role in this, and allow more 3rd party plugins to be available to address this business need.
(Oh, on the side, there ARE some ways you actually do 2FA transparently, but of course the email client has to understand it. But while you can do 'tricks' even in IMAP for 2FA, we need to think that the same method should work for ALL communication channels which utilize the same credentials, eg IMAP/SMTP/POP, even other things like caldav/carddav etc)
-- Michael --On 2022-06-27 07:53, justina colmena ~biz wrote:
I don't see why not.
Dovecot and Postfix are entirely configurable to connect to and use any desired authentication mechanism through certain basic interfaces.
The main problem I have experienced with MFA is a continual battle with extortion, "long cons," and thievery in law -- that the thieves are able to obtain one of the necessary factors for authentication -- a dongle or cell phone app or access to a cell phone number, or surveillance intelligence on calls or texts, whatnot -- whether by force or deception -- and then deny the targeted individual access to his or her own account.
Later on, after the victim has given up, the thieves are able to obtain the other factors for authentication, and then proceed to social-engineer a false account recovery using the victim's stolen I.D. -- and then they often as not falsely report the victim to gullible or complicit police forces as the thief.
If the victim cannot be successfully accused of theft in court, the "thieves in law" at work with inside help in government and law enforcement communities are able to cast identity theft as a mental illness akin to dissociative identity disorder -- to which the government offers nothing but a mental health "recovery" plan which does not include any actual recovery of the stolen assets in a person's name.
Casting identity theft as a mental health issue further enables thieves to take control of a victim's finances by possibly being appointed as guardians or payees in court. For the same reasons of legalized theft, extortion, and wrongful appropriation through state, local, military and federal court systems, individuals with similar names to known criminals are not allowed to hold significant assets in their names or possess firearms or obtain employment in sensitive positions in the United States.
On Sunday, June 26, 2022 2:52:05 PM AKDT, 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?
-- "Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
On 7/4/22 15:32, Michael Peddemors wrote:
It IS possible to use 2FA on Dovecot, but it would be better if Dovecot supported options by Plugins to control what supported 2FA options are supported in the CAPABILITIES string. (Ongoing problem getting more power in the handles of 3rd party plugins for Dovecot, politics.. )
HOWEVER, there are many ways if you 'roll your own' dovecot, eg can apply patches to the build process. We do this.
Having said that, yes.. especially in North America this push by insurance agents for 2FA, is driven by the RansomWare problems, and gives an insurance company a way out..
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. And even IF you apply a 2FA, (eg a 2nd factor) you might find that the insurance documents will not accept anything other than what their legal department defined as 2FA..
The biggest problem, is not the use of 2FA, it is making 2FA transparent and simple enough for end users to adopt. End users don't want to mess with a second factor they have to add, or a hardware dongle, or giving their cel# out..
Which, as long as I'm the one paying for the service, isn't going to happen. When they start paying my net bill, is when they can send me spam. And not 1 millisecond before.
And the industry has to come together, otherwise you will quickly find out insurance companies ONLY accept 2FA from one or two closed source companies..
Which is why once again, I wish that Dovecot would take a leadership role in this, and allow more 3rd party plugins to be available to address this business need.
(Oh, on the side, there ARE some ways you actually do 2FA transparently, but of course the email client has to understand it. But while you can do 'tricks' even in IMAP for 2FA, we need to think that the same method should work for ALL communication channels which utilize the same credentials, eg IMAP/SMTP/POP, even other things like caldav/carddav etc)
-- Michael --
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. That is, according to what I read, part of their job. So pester them until they do it. By whatever means is at your disposal.
On 2022-06-27 07:53, justina colmena ~biz wrote:
I don't see why not.
Dovecot and Postfix are entirely configurable to connect to and use any desired authentication mechanism through certain basic interfaces.
The main problem I have experienced with MFA is a continual battle with extortion, "long cons," and thievery in law -- that the thieves are able to obtain one of the necessary factors for authentication -- a dongle or cell phone app or access to a cell phone number, or surveillance intelligence on calls or texts, whatnot -- whether by force or deception -- and then deny the targeted individual access to his or her own account.
Later on, after the victim has given up, the thieves are able to obtain the other factors for authentication, and then proceed to social-engineer a false account recovery using the victim's stolen I.D. -- and then they often as not falsely report the victim to gullible or complicit police forces as the thief.
If the victim cannot be successfully accused of theft in court, the "thieves in law" at work with inside help in government and law enforcement communities are able to cast identity theft as a mental illness akin to dissociative identity disorder -- to which the government offers nothing but a mental health "recovery" plan which does not include any actual recovery of the stolen assets in a person's name.
Casting identity theft as a mental health issue further enables thieves to take control of a victim's finances by possibly being appointed as guardians or payees in court. For the same reasons of legalized theft, extortion, and wrongful appropriation through state, local, military and federal court systems, individuals with similar names to known criminals are not allowed to hold significant assets in their names or possess firearms or obtain employment in sensitive positions in the United States.
On Sunday, June 26, 2022 2:52:05 PM AKDT, 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?
Cheers, Gene Heskett.
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/>
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:
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)
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")
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
Quoting Jochen Bern <Jochen.Bern@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
I have a small client whose insurance company insists theyhave 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 thefoggiest 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?)
The two factor became necessary for the big 'moron' companies who decided to start using email addresses as logins so it was easier to track people, because in that situation you only have to try commonly used passwords or passwords used at a different application. If you stay with an username that is not published publicly, the commonly known password is still useless, since you do not have the username. I think for a small organization you can push this implementation at the insurance company. Unless of course they do not think ios and windows are not secure enough to store your username ;)
On 7/2/22 10:15, Marc wrote:
The two factor became necessary for the big 'moron' companies who decided to start using email addresses as logins so it was easier to track people, because in that situation you only have to try commonly used passwords or passwords used at a different application. Maybe some companies are using e-mail addresses for tracking. But I can tell you that most times users want to use their e-mail address for login because that's what they easily memorize.
If you stay with an username that is not published publicly, the commonly known password is still useless, since you do not have the username. Whether that protects you depends on your threat model.
In my world I regard the confidentiality of usernames to be near zero. And I'm in the camp who recommends not to use usernames based on person names (unguessable or even completely random).
Unless of course they do not think ios and windows are not secure enough to store your username ;)
Indeed my threat model includes breaches concerning the local storage of all sort of MUAs. Unfortunately there's currently no real solution for this.
Ciao, Michael.
Guns are banned and there's a night guard with a Big Mag flashlight or a billy club walking the beat around the bank, kicking a homeless man who fell asleep on the sidewalk to tell him wake up or your pocket's going be picked clean by morning, because you've got too much money in your name for your own good anyways, if you've got any teeth left in your mouth or can afford the dentist's bill for that.
On Saturday, July 2, 2022 12:15:09 AM AKDT, Marc wrote:
I have a small client whose insurance company insists theyhave 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 ...
The two factor became necessary for the big 'moron' companies who decided to start using email addresses as logins so it was easier to track people, because in that situation you only have to try commonly used passwords or passwords used at a different application. If you stay with an username that is not published publicly, the commonly known password is still useless, since you do not have the username. I think for a small organization you can push this implementation at the insurance company. Unless of course they do not think ios and windows are not secure enough to store your username ;)
On Sat, Jul 02, 2022 at 07:32:21AM -0800, justina colmena ~biz wrote:
Guns are banned and there's a night guard with a Big Mag flashlight or a billy club walking the beat around the bank, kicking a homeless man who fell asleep on the sidewalk to tell him wake up or your pocket's going be picked clean by morning, because you've got too much money in your name for your own good anyways, if you've got any teeth left in your mouth or can afford the dentist's bill for that.
Please stick to the topic, which is about how to implement MFA with Dovecot.
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
On 7/3/22 8:31 AM, John Gateley wrote:
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.
I did find this RFC - I haven't read it, but it applies directly: https://datatracker.ietf.org/doc/html/rfc7628
j
Please note this is my opinion only
It seems any kind of dual auth will need a security app running on YOUR server saving toikens, logins etc etc
this is what lead to microsoft, gmail etc having their own api which will only work for them
this is also (mainly because of https authing the device) what makes it hard to proxy oauth2 etc
If you look at sogo's documentation they have a java server applet
Still working on the install to make work with my system but in general you need your own whatever app to track oauth2
5.7. Authenticating using C.A.S. SOGo natively supports C.A.S. authentication. For activating C.A.S. authentication you need first to make sure that the SOGoAuthenticationType setting is set to cas, SOGoXSRFValidationEnabled is set to NO and that the SOGoCASServiceURL setting is configured appropriately.
I myself will eventually get around to implimenting this on one of my servers ?
logically i will have to track tokens etc via https like google etc
basically the reality is every server will have it's own token base etc thus preventing any kind of a standard.
Happy Sunday !!! Thanks - paul
Paul Kudla
Scom.ca Internet Services <http://www.scom.ca> 004-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3
Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email paul@scom.ca
On 7/3/2022 9:50 AM, John Gateley wrote:
On 7/3/22 8:31 AM, John Gateley wrote:
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.
I did find this RFC - I haven't read it, but it applies directly: https://datatracker.ietf.org/doc/html/rfc7628
j
Disclaimer: I work for Auth0 (now Okta)
On 7/3/22 9:40 AM, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:
It seems any kind of dual auth will need a security app running on YOUR server saving toikens, logins etc etc
Not necessarily. With Auth0, the IDP runs on Auth0's server. You are responsible for storing ID tokens, access tokens, and refresh tokens in your app. There are ways of doing this fairly securely, even with desktop apps or mobile devices, where you don't have a secure backend.
this is what lead to microsoft, gmail etc having their own api which will only work for them
If I understand this correctly, Google et al provide an MFA API for apps that want to handle auth themselves, instead of going the OIDC/OAuth2/SAML route. They also provide standards based protocols, like OIDC.
That's what I was hinting at above - adopting OIDC makes things easier than trying to bolt on security (via some MFA API).
this is also (mainly because of https authing the device) what makes it hard to proxy oauth2 etc
This is definitely a pain point. You can either open up a browser from the device, or on constrained devices, use device flow (display a URL, user visits that URL on their laptop, device grabs confirmation from the IDP that they did). Neither one is completely elegant, but opening a browser on a mobile device is far less intrusive than you might think.
5.7. Authenticating using C.A.S. ...
basically the reality is every server will have it's own token base etc thus preventing any kind of a standard.
I'm not familiar with C.A.S. I don't have any clients that I know of using it, so I can't comment on it. But the JWT token spec is now common, and is a standard. Also the SAML spec. I see more OIDC, but also a lot of SAML.
Happy IAM Sunday to you too!
j
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-onl...
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/...
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
On 7/6/22 12:09, Jochen Bern wrote:
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-onl...
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/...
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.
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,
Cheers, Gene Heskett.
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/>
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..
-- "Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
On 7/6/22 18:15, Michael Peddemors 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.
Yes, many years ago, what little I knew about windows nt-3.51 led me to believe it had a timer set for a random number in the 2 to 4 year category, that deleted its main dll when the timer expired, I put the drive in a different machine and dug around in it after it failed in the night, and the failure was costing us around 5g's a day in airing the wrong commercials for our market area. I did find a suspicious shell script, but didn't find the timer.
So time was of the essence and since it was a CBS supplied machine I had no access to its license number so the support person refused to supply the now missing library and called me a pirate several times during our conversation. To this day I may be forced to buy a windows license as part of the sale, but the windows install will be wiped when it arrives on my property. So I either build my own, or buy used w/o a hard drive and sticker. Old Dells, with linux installed have a lot of miles left in them.
So other than that, we're on the same page.
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'.
I can't drink the koolaid, way too much sugar and I'm a DM-II for nearly 40 years.
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. Since my own net provider's mail server is dovecot, and so far it Just Works, I am happy but concerned because being the only game on this ball of rock and water is BG's dream.
Just my two bits..
Mine too. Take care and stay well, Michael Peddemors
Cheers, Gene Heskett.
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/>
On 07/07/2022 01:12 EEST Michael Peddemors <michael@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@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.
On 2022-07-14 10:12, Michael Slusarz wrote:
On 07/07/2022 5:24 AM Aki Tuomi <aki.tuomi@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.
Thanks for weighing in Michael,
.. but if you wish to enable developers and innovation, you do need to foster the ability for other parties to use plugins, advertise other methods, etc.. there are still many that feel oAuth might not be the right approach, and while anyone can be an oAuth provider, that this might centralize.. As it is, we already see in North America the insurance companies wording for '2FA' requirements check boxes sounds a lot like 'Are you using o356?'.
I believe Dovecot can be a leader, in ensuring that the future doesn't just consist of a few central players..
You might 'feel' that you have all the necessary components, but of course that does come from a business perspective, and it doesn't allow for new, novel, or innovative ways that 3rd parties are coming up with everyday.
(and in the case that we are working with, there are already several clients and servers that support it)
Dovecot I personally believe, given it's over 70% market share, does have a responsibility to remain open and collaborative, otherwise it risks being perceived as rigid as some of the big commercial proprietary products.
By 'deciding' for the world what is sufficient for 'modern email auth', this is limiting.. IMHO
To quote that old Linux Torvald saying.. "Let a thousand flower bloom.."
Noone has to agree on everything, or approaches.. but enable them to get out into the real world, and amazing things may happen..
Have a great weekend everyone.. get out in the sun..
-- "Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
participants (13)
-
Aki Tuomi
-
gene heskett
-
Jochen Bern
-
John Gateley
-
justina colmena ~biz
-
Marc
-
Michael Peddemors
-
Michael Slusarz
-
Michael Ströder
-
Paul Kudla (SCOM.CA Internet Services Inc.)
-
Rick Romero
-
Sam Kuper
-
Steve Dondley