2FA/MFA with IMAP & postfix/submission
Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail.
Are there multi-factor options available?
If it is not available, do you have any recommendations on where I should look to do this?
All of the links related to this topic appear to be very old, or limited to Linux PAM users.
On 7/14/21 8:08 PM, Alex wrote:
Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail.
Are there multi-factor options available?
google roundcube + 2FA
number of options available
works well IME
Main problem is that not many clients do natively support multifactor. Some clients, do popup a login dialog if the server rejects the password as invalid, which can be used to create a "cheaty variant" of multifactor, but some clients just popup an error dialog and tell the user to just correct password in settings. Some clients even go as long as requiring the user to delete the account with wrong password and set up a new connection.
So no, it cannot be relied upon.
I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. Or perhaps, just "set" the country of the account based on GeoIP.
When an account tries to login via IMAP or SMTP, you just check if IP and/or GeoIP country is right, and reject the login as invalid if so not.
The only thing a client needs to do to get his IMAP or SMTP client to work again if it stops working, is to login once via the web client.
-----Ursprungligt meddelande----- Från: dovecot-bounces@dovecot.org <dovecot-bounces@dovecot.org> För Alex Skickat: den 15 juli 2021 02:10 Till: dovecot@dovecot.org Ämne: 2FA/MFA with IMAP & postfix/submission
Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail.
Are there multi-factor options available?
If it is not available, do you have any recommendations on where I should look to do this?
All of the links related to this topic appear to be very old, or limited to Linux PAM users.
Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs.
If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords.
Aki
On 15/07/2021 08:18 Sebastian <sebastian@sebbe.eu> wrote:
Main problem is that not many clients do natively support multifactor. Some clients, do popup a login dialog if the server rejects the password as invalid, which can be used to create a "cheaty variant" of multifactor, but some clients just popup an error dialog and tell the user to just correct password in settings. Some clients even go as long as requiring the user to delete the account with wrong password and set up a new connection.
So no, it cannot be relied upon.
I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. Or perhaps, just "set" the country of the account based on GeoIP.
When an account tries to login via IMAP or SMTP, you just check if IP and/or GeoIP country is right, and reject the login as invalid if so not.
The only thing a client needs to do to get his IMAP or SMTP client to work again if it stops working, is to login once via the web client.
-----Ursprungligt meddelande----- Från: dovecot-bounces@dovecot.org <dovecot-bounces@dovecot.org> För Alex Skickat: den 15 juli 2021 02:10 Till: dovecot@dovecot.org Ämne: 2FA/MFA with IMAP & postfix/submission
Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail.
Are there multi-factor options available?
If it is not available, do you have any recommendations on where I should look to do this?
All of the links related to this topic appear to be very old, or limited to Linux PAM users.
On 2021-07-15 07:26, Aki Tuomi wrote:
Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs.
If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords.
speculating :=)
weekforce policy server with 2fa, that just update allow_nets in dovecot user dict table, so all dovecot do is to check allow nets pr user from dict, i dont know if that is possible so imap / pop3 / lmtp and other service in dovecot dont need to mess with oauth2 or other complicated login system not supported everywhere
hope to see more stable security in dovecot with this, and certenly hope weekforce is not the only opensoure solution that is half dokumented :/
currently i just use ip2location in shorewall with asn numbers where i have known custommers, i got tired of blacklist random ips, bad idea hackers just could use another ip for free
no more fails here, it just remain to update microsoft servers with use port 465, 587, 993 without know passwords, who did dokument that ports is password less, shame on them
Hi,
Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs.
If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords.
speculating :=)
weekforce policy server with 2fa, that just update allow_nets in dovecot user dict table, so all dovecot do is to check allow nets pr user from dict, i dont know if that is possible so imap / pop3 / lmtp and other service in dovecot dont need to mess with oauth2 or other complicated login system not supported everywhere
Yeah, I'm not sure we can use something that appears to be so experimental.
What about client certs? Wouldn't that solve the problem?
Does Outlook for Windows include any type of MFA? It appears inextricably linked to Office 365.
What about something like what we used to do with pop-b4-smtp to at least restrict by IP address?
On 2021-07-15 16:49, Alex wrote:
What about something like what we used to do with pop-b4-smtp to at least restrict by IP address?
no, pop was not handle million of users share one single nat ip, weekforce cant handle that either, so allow_net cant do any better there
all i think is possible is to make 2fa updated with users login to weekforce, and thats it, then weekforce can do the allow_net with that login, there mail/mua still is just enforeced with allow_nets only
all should be pretty simple for all kind of mail programs not knowing how to use oauth2 or 2fa then
who will make the weekforce policy server for exact that ?, i am willing to test it, but not code it
Quoting Benny Pedersen <me@junc.eu>:
On 2021-07-15 16:49, Alex wrote:
What about something like what we used to do with pop-b4-smtp to at least restrict by IP address?
no, pop was not handle million of users share one single nat ip,
weekforce cant handle that either, so allow_net cant do any better
there
Well no, but I thought the problem to be solved was 'prevent
compromised credentials from abusing SMTP'. Certs do that, but with
high overhead.
OTOH, going off Alex's suggestion, you could tie the IMAP or POP Auth
into an iptables rule that allows that IP to use SMTP for x minutes.
Basically, the opposite of fail2ban - 'auth2allow' :)
You could probably use fail2ban, just adjust the log regex's and the
action appled.
The odds of an abuser coming from the same IP are pretty slim, and if
the system itself is compromised, they're going to have the cert
anyways.
In my experience, most clients do SMTP after the POP or IMAP check..
I'd expect issues to be minimal.
Rick
Hi,
Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs.
If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords.
Client certs appears to be a good solution.
What's the process for managing them with more than a hundred client accounts?
I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem?
Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?
Client certs appears to be a good solution.
What's the process for managing them with more than a hundred client accounts?
If you've got the budget ... MDM. If you don't, you can probably hack together some sort of self-service system.
I believe the problem they are trying to solve is hacked accounts from
compromised passwords. Does client certs solve that problem?
Well yes.
If you make client certs mandatory, unless the client can present a valid cert, the server will kill the connection before the client has a chance to try out a compromised password.
Quoting Alex <mysqlstudent@gmail.com>:
Hi,
Unfortunately the best way to do multifactor authentication today
is to use OAUTH2, which isn't currently supported for own
installations. Or you can use client certs.If you want to use some kind of MFA with tokens, you end up having
to feed your token all the time. So the best option, for now, is
device passwords.Client certs appears to be a good solution.
What's the process for managing them with more than a hundred client
accounts?I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem?
Client certs would solve that - but you'll need some management around
it (creation/deployment/renewal/device changes/etc). The easiest
method is to run MDM and PKI infrastructure, but with 100 clients I
kinda doubt that's in place and I wonder if they have the budget for it.
Another option, not open source, but if you engage Recorded Future,
you can get a report and notifications of password compromises, and
then take action on that info (ie, force affected user to change
password).
Alternatively, and free, don't use the email address as the username
for authenticaiton, use some other generic ID.
Rick
Problem is that not many client support it - especially mobile ones.So wireguard VPN is the way to go, much simpler for the users. -------- Originalmeddelande --------Från: Rick Romero <rick@havokmon.com> Datum: 2021-07-15 17:04 (GMT+01:00) Till: dovecot@dovecot.org Ämne: Re: Sv: 2FA/MFA with IMAP & postfix/submission Quoting Alex <mysqlstudent@gmail.com>:
Hi,
Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs.
If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords.
Client certs appears to be a good solution.
What's the process for managing them with more than a hundred client accounts?
I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem? Client certs would solve that - but you'll need some management around it (creation/deployment/renewal/device changes/etc). The easiest method is to run MDM and PKI infrastructure, but with 100 clients I kinda doubt that's in place and I wonder if they have the budget for it.
Another option, not open source, but if you engage Recorded Future, you can get a report and notifications of password compromises, and then take action on that info (ie, force affected user to change password).
Alternatively, and free, don't use the email address as the username for authenticaiton, use some other generic ID.
Rick
Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?
Restricting by IP is soon going to become very tedious, especially if you are dealing with more than a small number of users, and especially once post-COVID travel comes back and people start connecting from random hotels and airport lounges.
If you don't fancy the idea of client certs, the alternative I would suggest instead of IP limiting would be a Wireguard VPN instead of IP limiting.
Wireguard VPN servers run very quiet and won't respond to anything unless a client sends the right parameters.
Of course the downside of a VPN compared to certificates is that the user will have to be aware and know how to manage a VPN, whilst with certificates it can all be quietly done in the background.
On 2021-07-15 8:07 a.m., Laura Smith wrote:
Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?
Restricting by IP is soon going to become very tedious, especially if you are dealing with more than a small number of users, and especially once post-COVID travel comes back and people start connecting from random hotels and airport lounges.
If you don't fancy the idea of client certs, the alternative I would suggest instead of IP limiting would be a Wireguard VPN instead of IP limiting.
Wireguard VPN servers run very quiet and won't respond to anything unless a client sends the right parameters.
Of course the downside of a VPN compared to certificates is that the user will have to be aware and know how to manage a VPN, whilst with certificates it can all be quietly done in the background.
And of course, you can always do..
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_delay_reject=no
-o { smtpd_client_restrictions = reject_rbl_client auth.spamrats.com=127.0.0.39, permit } -o { smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject }
Pick your favourite RBL's.. And do suggest that based on our threat teams' research, block AUTH from many of the cloud providers IP Space, several RBL's out there make it easy..
And/or, you can create your own lists, Amazon/Google/Azure all list their IP space publicly..
Just remember, use your own DNS servers, or upstream DNS servers, and NOT open resolvers such as Google's 8.8.8.8, as most RBL's block queries from those..
-- "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 2021 Jul 15, at 08:52, Alex <mysqlstudent@gmail.com> wrote:
Client certs appears to be a good solution.
A solution, certainly. A GOOD solution? Not really.
What's the process for managing them with more than a hundred client accounts?
And that's the first issue.
The second issue is "my primary device is not available, I need to login from this other computer or use my phone which is unsuitable for this task. Too bad I have no choice but to use the phone because this computer doesn’t have the cert."
And then you have the "now that I've installed this cert, theis computer is considered trusted" which is another issue.
2FA is a lot more flexible and robust.
OATH works well. SQRL looks promising though it requires a web UI I to do the authentication (and SQRL does away with passwords as well).
I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem?
Maybe. Depends on if the hacker can get access to the user's machine or not.
Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?
It is certainly possible in Postfix, but that opens up its own issues. It may be acceptable in some corporate environs, but in most situations being able to access your email wherever you are is a requirement.
-- The wages of sin is death, but so is the salary of virtue, and at least the evil get to go home early on Fridays. --Witches Abroad
The thing is, that people must stop expecting "being able to access mail whenever you are" without extra steps.
Best solution is to offer a webmail with TOTP or SQRL or similiar secure auth method.
Then have that webmail adds IP or country into trusted list, so if you want to access IMAP mail or SMTP mail from hotel wifi, you have to simply do one single login to webmail, and then your IMAP/SMTP will work as usual.
The problem with certificates, is as I said, not many clients support them. Outlook support them natively, I don't know if Windows Mail support them, and I don't know if Samsung Mail do support them (maybe they do support client certificates in Enterprise mode, but then you need a license for that), K9 mail I know support them, other built-in email clients I don't know if they support client certificates.
The solution I have on my email is a OpenVPN connection to my server, which is protected. My phone has a 24/7 connection to that VPN server, and thus im able to lock out all logins outside from VPN.
-----Ursprungligt meddelande----- Från: dovecot-bounces@dovecot.org <dovecot-bounces@dovecot.org> För @lbutlr Skickat: den 15 juli 2021 18:37 Till: dovecot mailing list <dovecot@dovecot.org> Ämne: Re: 2FA/MFA with IMAP & postfix/submission
On 2021 Jul 15, at 08:52, Alex <mysqlstudent@gmail.com> wrote:
Client certs appears to be a good solution.
A solution, certainly. A GOOD solution? Not really.
What's the process for managing them with more than a hundred client accounts?
And that's the first issue.
The second issue is "my primary device is not available, I need to login from this other computer or use my phone which is unsuitable for this task. Too bad I have no choice but to use the phone because this computer doesn’t have the cert."
And then you have the "now that I've installed this cert, theis computer is considered trusted" which is another issue.
2FA is a lot more flexible and robust.
OATH works well. SQRL looks promising though it requires a web UI I to do the authentication (and SQRL does away with passwords as well).
I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem?
Maybe. Depends on if the hacker can get access to the user's machine or not.
Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?
It is certainly possible in Postfix, but that opens up its own issues. It may be acceptable in some corporate environs, but in most situations being able to access your email wherever you are is a requirement.
-- The wages of sin is death, but so is the salary of virtue, and at least the evil get to go home early on Fridays. --Witches Abroad
I think it's only 12 steps. There are people who need to sober up....
On July 15, 2021 8:54:16 AM AKDT, Sebastian <sebastian@sebbe.eu> wrote:
The thing is, that people must stop expecting "being able to access mail whenever you are" without extra steps.
Best solution is to offer a webmail with TOTP or SQRL or similiar secure auth method.
Then have that webmail adds IP or country into trusted list, so if you want to access IMAP mail or SMTP mail from hotel wifi, you have to simply do one single login to webmail, and then your IMAP/SMTP will work as usual.
The problem with certificates, is as I said, not many clients support them. Outlook support them natively, I don't know if Windows Mail support them, and I don't know if Samsung Mail do support them (maybe they do support client certificates in Enterprise mode, but then you need a license for that), K9 mail I know support them, other built-in email clients I don't know if they support client certificates.
The solution I have on my email is a OpenVPN connection to my server, which is protected. My phone has a 24/7 connection to that VPN server, and thus im able to lock out all logins outside from VPN.
-----Ursprungligt meddelande----- Från: dovecot-bounces@dovecot.org <dovecot-bounces@dovecot.org> För @lbutlr Skickat: den 15 juli 2021 18:37 Till: dovecot mailing list <dovecot@dovecot.org> Ämne: Re: 2FA/MFA with IMAP & postfix/submission
On 2021 Jul 15, at 08:52, Alex <mysqlstudent@gmail.com> wrote:
Client certs appears to be a good solution.
A solution, certainly. A GOOD solution? Not really.
What's the process for managing them with more than a hundred client accounts?
And that's the first issue.
The second issue is "my primary device is not available, I need to login from this other computer or use my phone which is unsuitable for this task. Too bad I have no choice but to use the phone because this computer doesn’t have the cert."
And then you have the "now that I've installed this cert, theis computer is considered trusted" which is another issue.
2FA is a lot more flexible and robust.
OATH works well. SQRL looks promising though it requires a web UI I to do the authentication (and SQRL does away with passwords as well).
I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem?
Maybe. Depends on if the hacker can get access to the user's machine or not.
Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?
It is certainly possible in Postfix, but that opens up its own issues. It may be acceptable in some corporate environs, but in most situations being able to access your email wherever you are is a requirement.
-- The wages of sin is death, but so is the salary of virtue, and at least the evil get to go home early on Fridays. --Witches Abroad
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 2021-07-15, Sebastian <sebastian@sebbe.eu> wrote:
Best solution is to offer a webmail with TOTP or SQRL or similiar secure = auth method.
Then have that webmail adds IP or country into trusted list, so if you = want to access IMAP mail or SMTP mail from hotel wifi, you have to = simply do one single login to webmail, and then your IMAP/SMTP will work = as usual.
As long as the IMAP/SMTP access is coming from the same ISP as the web access and not, for example, natted to one IP whereas the web traffic is coming from a proxy, or natted to a pool of addresses (or balanced between multiple internet connections) where you don't always get the same external address.
On 2021-07-15 7:54 a.m., Laura Smith wrote:
Are there multi-factor options available?
Mandating good old-fashioned client-certificates is most likely your best bet in terms of delivering the best user-experience.
Or, you can use the CLIENT_ID SMTP extension for dovecot/postfix.. For the record, still seeing 50-1 attempts against SMTP AUTH vs IMAP/POP AUTH attacks..
Completely transparent to the user..
Still need to see upstream implement the variable capabilities patch.. so that plugins can modify it..
But reach out if you want more details..
-- "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 (12)
-
＠lbutlr
-
Aki Tuomi
-
Alex
-
Benny Pedersen
-
justina colmena ~biz
-
Laura Smith
-
Michael Peddemors
-
PGNet Dev
-
Rick Romero
-
Sebastian
-
Sebastian Nielsen
-
Stuart Henderson