Re: Is multi factor authentication practical/feasible?

[Michael Peddemors]

On 2022-07-14 10:12, Michael Slusarz wrote:

On 07/07/2022 5:24 AM Aki Tuomi  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.
V

Re: Is multi factor authentication practical/feasible?

[Michael Slusarz]

> On 07/07/2022 5:24 AM Aki Tuomi  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.

Re: Is multi factor authentication practical/feasible?

[Aki Tuomi]

> On 07/07/2022 01:12 EEST 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.
> 
> 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

Re: Is multi factor authentication practical/feasible?

[gene heskett]

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 

Re: Is multi factor authentication practical/feasible?

[Michael Peddemors]

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.

Re: Is multi factor authentication practical/feasible?

[gene heskett]

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

Re: Is multi factor authentication practical/feasible?

[Jochen Bern]

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Is multi factor authentication practical/feasible?

[gene heskett]

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.


* https://www.identitytheft.gov/
* https://www.robodeidentidad.gov/

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.


* https://en.wikipedia.org/wiki/Thief_in_law

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

Re: Is multi factor authentication practical/feasible?

[Michael Peddemors]

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.


* https://www.identitytheft.gov/
* https://www.robodeidentidad.gov/

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.


* https://en.wikipedia.org/wiki/Thief_in_law

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.

Re: Is multi factor authentication practical/feasible?

[John Gateley]

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

Re: Is multi factor authentication practical/feasible?

[Paul Kudla (SCOM.CA Internet Services Inc.)]

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

Re: Is multi factor authentication practical/feasible?

[John Gateley]

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

Re: Is multi factor authentication practical/feasible?

[John Gateley]

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

Re: Is multi factor authentication practical/feasible?

[Sam Kuper]

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.

Re: Is multi factor authentication practical/feasible?

[justina colmena ~biz]

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


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 ;)

RE: Is multi factor authentication practical/feasible?

[Marc]

> 
>   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?)
> 

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 ;)

Re: Is multi factor authentication practical/feasible?

[Rick Romero]

 Quoting Jochen Bern :


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

Re: Is multi factor authentication practical/feasible?

[Jochen Bern]

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Is multi factor authentication practical/feasible?

[justina colmena ~biz]

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.


* https://www.identitytheft.gov/
* https://www.robodeidentidad.gov/

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.


* https://en.wikipedia.org/wiki/Thief_in_law

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?

Re: Is multi factor authentication practical/feasible?

[Sam Kuper]

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:

- https://www.nitrokey.com/

- https://www.yubico.com

- https://www.nytimes.com/wirecutter/reviews/best-security-keys/


and time-based one-time passwords ("TOTP") are also cross-platform:

- https://en.wikipedia.org/wiki/Time-based_one-time_password

- https://en.wikipedia.org/wiki/FreeOTP

- https://en.wikipedia.org/wiki/Google_Authenticator

- https://en.wikipedia.org/wiki/LinOTP

- https://www.macrumors.com/2021/06/07/ios-15-built-in-password-authenticator/


Please update the thread if you make any progress.  Thanks!

Sam

Is multi factor authentication practical/feasible?

[Steve Dondley]

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?