Is multi factor authentication practical/feasible?

Jochen Bern Jochen.Bern at binect.de
Fri Jul 1 18:02:35 UTC 2022


On 27.06.22 00:52, Steve Dondley wrote:
> I have a small client whose insurance company insists they have MFA for their email to be covered under some kind of data protection policy. Currently I have the client set up on a Debian box for the email server coupled with roundcube for webmail. Most the users just use roundcube but some also use their mobile devices to check email. Maybe one person uses outlook. There’s about 5 to 10 users total.
> 
> I know roundcube offers a MFA plugin. But I don’t have the foggiest idea how of an iPhone, Android device, or Outlook could all be set up to work with MFA with a standard dovecot/postfix setup. Are there any practical solutions for easily implementing MFA that could work across multiple devices?

*Totally* theorizing here, but as far as I'm aware, the SMTP (AUTH), 
POP, and IMAP protocol definitions do not provide elbow room to make 
*two* rounds of authentication. (Ever pondered why the admin can require 
O365 users to "use 2FA", but users then are still allowed to create 
"application passwords", note plural and lack of standard password 
features like a limited lifetime for those?)

If I'm correct with that, and if you have to provide these protocols, 
there are three options:

1. Users need to roll their memorized password and an OTP from a token 
into *one* combined password they enter (seen that in some early 2FA 
implementations when CLI/GUI login procedures did not yet have support 
for multiple rounds built in)

2. User needs to enter his "password" (PIN, actually) into the *token* 
to make it spit out a (valid) OTP, and *that* is then the "password" he 
sends to the servers (some people will insist that this "is not 2FA")

3. Servers/backends have a way to communicate with the token directly 
(ideally so that the user gets the password-to-enter via the token, say, 
per SMS, but for *that* to work out, you need that *every* piece of 
software used is willing and able to forward the info "user X wants to 
make an attempt at auth" *before* it also has the password at hand)

Good luck,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://dovecot.org/pipermail/dovecot/attachments/20220701/2941573d/attachment.bin>


More information about the dovecot mailing list