Re: Strategies for protecting IMAP (e.g. MFA)
On Mon, Nov 15, 2021 at 02:14:31PM -0600, Tyler Montney wrote: > I've just recently started using mailing lists, so replying is still a bit > awkward to me. (Probably be easier if we'd use forums.) Forums are a mixed bag. Some love them, some hate them. I previously ran a forum for LedgerSMB. It had some usage, but people mostly preferred the mailing lists. I was also running an add-on by the forum author that allowed posting incoming emails to boards. I never setup an outgoing to the mailing list. I wanted to. No time. However, reading and searching emails from a mailing list in a forum is *nice*. Really nice. You can see the entire thread at once. If any mailing list I'm part of wants to do a read-only posting of email only messages like that, I would put up a forum for that only, for free. I would only make something like that public if the mailing list owners wanted it done. - As far as 2FA over a phone, I hate it. When traveling, my phone only works in USA, Canada and Mexico. If I were in Guatemala, I'd have no access to my DNS server company. Ugh! -- Chris Bennett
Re: Strategies for protecting IMAP (e.g. MFA)
On Sun, 14 Nov 2021, Michael Peddemors wrote: And there are RBL's now for know IP(s) used by IMAP hackers, including SpamRats RATS-AUTH that can assist in reducing those attacks. These guys also lists brute forcers: http://www.blocklist.de/en/rbldns.html I don't know how well they catch IMAP hackers, but they list 95%+ of our ssh brute forcing attacks. Joseph Tam
Re: Strategies for protecting IMAP (e.g. MFA)
> Probably because it can be complex to set up and maintain Such is mail and many other things, which falls on the admins. I see no harm in exploring what's what before deciding. > and more would be gained by educating users Yes, users are the weakest link. Users are also the biggest challenge. Making them use 2FA on their phone? Easy. Retraining them to think more like me? Very difficult (assuming you get management buy-in). Again, I'm trying to explore deploying an all "bells and whistles" mail stack that can cater to both an enthusiast environment (like myself) and one in a commercial/enterprise environment. Not having 2FA like I could get from cloud offerings may be a deal breaker for me. > I personally find your style of quoting a bit irritating, especially because you leave the whole original message intac Gmail loves hiding the previous text with an ellipsis, making me not realize. > Why not quote in a manner we have successfully used for a couple of decades? I've just recently started using mailing lists, so replying is still a bit awkward to me. (Probably be easier if we'd use forums.)
Re: Strategies for protecting IMAP (e.g. MFA)
On 15/11/2021 11:52, Arjen de Korte wrote:
Citeren Benny Pedersen :
On 2021-11-14 20:26, Matthew Richardson wrote:
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
And there are RBL's now for know IP(s) used by IMAP hackers, including
SpamRats RATS-AUTH that can assist in reducing those attacks.
Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in
Dovecot" says "PLEASE UPDATE".
How would one use a DNSBL like this in Dovecot to reject IMAP
connections
from listed IPs?
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 }
This is not an answer to the question, this is Postfix syntax.
openRelay, dont do it
In what way would this create an open relay exactly? The 'permit' at the
end of the 'smtpd_client_restrictions' only means that the client is
accepted, not that other smtpd restrictions are lifted.
resolved version
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_delay_reject=no
-o { smtpd_relay_restrictions = reject_rbl_client
auth.spamrats.com=127.0.0.39, permit_mynetworks,
permit_sasl_authenticated, reject }
Although syntactically correct, it is confusing at best to put client
restrictions in another place than smtpd_client_restrictions. Especially
with 'smtpd_delay_reject=no' in effect you'd only reject after receiving
'RCPT TO', which is evaluated after 'smtpd_client_restrictions' and
'smtpd_helo_restrictions' during the SMTP transfer.
order do matter
Indeed.
Perhaps I was not clear in my last message. Have a look to this
documentation:
https://homebox.readthedocs.io/en/latest/email-access-monitoring/
I am available if you have any question to implement something similar
yourself. Extending the system to add a second factor authentication is
probably easy enough.
Kind regards,
André
--
𝓐𝓡 - André Rodier
Re: Strategies for protecting IMAP (e.g. MFA)
Citeren Benny Pedersen :
On 2021-11-14 20:26, Matthew Richardson wrote:
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
And there are RBL's now for know IP(s) used by IMAP hackers, including
SpamRats RATS-AUTH that can assist in reducing those attacks.
Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in
Dovecot" says "PLEASE UPDATE".
How would one use a DNSBL like this in Dovecot to reject IMAP connections
from listed IPs?
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 }
This is not an answer to the question, this is Postfix syntax.
openRelay, dont do it
In what way would this create an open relay exactly? The 'permit' at
the end of the 'smtpd_client_restrictions' only means that the client
is accepted, not that other smtpd restrictions are lifted.
resolved version
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_delay_reject=no
-o { smtpd_relay_restrictions = reject_rbl_client
auth.spamrats.com=127.0.0.39, permit_mynetworks,
permit_sasl_authenticated, reject }
Although syntactically correct, it is confusing at best to put client
restrictions in another place than smtpd_client_restrictions.
Especially with 'smtpd_delay_reject=no' in effect you'd only reject
after receiving 'RCPT TO', which is evaluated after
'smtpd_client_restrictions' and 'smtpd_helo_restrictions' during the
SMTP transfer.
order do matter
Indeed.
Re: Strategies for protecting IMAP (e.g. MFA)
On 2021-11-14 20:26, Matthew Richardson wrote:
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
And there are RBL's now for know IP(s) used by IMAP hackers, including
SpamRats RATS-AUTH that can assist in reducing those attacks.
Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in
Dovecot" says "PLEASE UPDATE".
How would one use a DNSBL like this in Dovecot to reject IMAP
connections
from listed IPs?
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 }
openRelay, dont do it
resolved version
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_delay_reject=no
-o { smtpd_relay_restrictions = reject_rbl_client
auth.spamrats.com=127.0.0.39, permit_mynetworks,
permit_sasl_authenticated, reject }
order do matter
for dovecot use allow_nets or weekforce policy server, 3dr party, if
dovecot is the submission it would imho be a winner
i still consider external service as a insecure help
Re: Strategies for protecting IMAP (e.g. MFA)
On 2021-11-14 16:55, Lefteris Tsintjelis wrote: And if you need sporadically to use it outside your white listing, VPN works great. with own CA yes if not to being fooled by others
Re: Strategies for protecting IMAP (e.g. MFA)
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:- >And there are RBL's now for know IP(s) used by IMAP hackers, including >SpamRats RATS-AUTH that can assist in reducing those attacks. Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in Dovecot" says "PLEASE UPDATE". How would one use a DNSBL like this in Dovecot to reject IMAP connections from listed IPs? -- Best wishes, Matthew
Re: Strategies for protecting IMAP (e.g. MFA)
On 14/11/2021 18:03, Lefteris Tsintjelis wrote: On 14/11/2021 14:50, Kees van Vloten wrote: Apart from a really nice firewall firehol also supplies a good set of ip-blacklists. For public exposure of email ports, I am using the combination of firehol-firewall, firehol-blacklist, fail2ban and a whitelist based on geo-ip. The mail-client ports exposed are 993 and 465, because starttls is considered flawed nowadays: https://nostarttls.secvuln.info/) Full access from any IP (except firehol-blacklist and fail2ban) is possible over VPN (openvpn) with MFA (privacyidea). Privacyidea also supplies a mobile-app compatible with a.o. TOTP and HOTP but it provides a more secure way of enrollment (2-step). Thanks for pointing at crowdsec.net, will see if it can tighten security further in cooperation with the above. - Kees The problem I faced over the years, with so many IPs, was that the black listing way would reach its limits at some point. Using the classic fail2ban expiration dates and method, over time, never actually manages to get rid of them as they keep on trying and trying. I needed to expand the blacklist expiration time limits way high but that reached firewall limitations so I personally switched to a permanent white list firewalling, as I could do that, and it really got rid of a lot of my headaches with just about all my public services. Black listing would work in case of central dedicated anf large firewalls but for smaller solutions I think country white listing firewall is far better method. What would also be interesting is something similar to the spamcop combined with crowdsec reporting system so that it can be used to effectively analyze and reduce all those bots. The Spamhouse DROP list would also be a good permanent black list addition to any border routers or stand alone public services. https://www.spamhaus.org/drop/ Perhaps I was not clear in my last message. Have a look to this documentation: https://homebox.readthedocs.io/en/latest/email-access-monitoring/ I am available if you have any question to implement something similar yourself. Extending the system to add a second factor authentication is probably easy enough. Kind regards, André -- 𝓐𝓡 - André Rodier
Re: Strategies for protecting IMAP (e.g. MFA)
On 14/11/2021 14:50, Kees van Vloten wrote: Apart from a really nice firewall firehol also supplies a good set of ip-blacklists. For public exposure of email ports, I am using the combination of firehol-firewall, firehol-blacklist, fail2ban and a whitelist based on geo-ip. The mail-client ports exposed are 993 and 465, because starttls is considered flawed nowadays: https://nostarttls.secvuln.info/) Full access from any IP (except firehol-blacklist and fail2ban) is possible over VPN (openvpn) with MFA (privacyidea). Privacyidea also supplies a mobile-app compatible with a.o. TOTP and HOTP but it provides a more secure way of enrollment (2-step). Thanks for pointing at crowdsec.net, will see if it can tighten security further in cooperation with the above. - Kees The problem I faced over the years, with so many IPs, was that the black listing way would reach its limits at some point. Using the classic fail2ban expiration dates and method, over time, never actually manages to get rid of them as they keep on trying and trying. I needed to expand the blacklist expiration time limits way high but that reached firewall limitations so I personally switched to a permanent white list firewalling, as I could do that, and it really got rid of a lot of my headaches with just about all my public services. Black listing would work in case of central dedicated anf large firewalls but for smaller solutions I think country white listing firewall is far better method. What would also be interesting is something similar to the spamcop combined with crowdsec reporting system so that it can be used to effectively analyze and reduce all those bots. The Spamhouse DROP list would also be a good permanent black list addition to any border routers or stand alone public services. https://www.spamhaus.org/drop/
Re: Strategies for protecting IMAP (e.g. MFA)
On 2021-11-14 7:55 a.m., Lefteris Tsintjelis wrote: On 13/11/2021 23:16, Tyler Montney wrote: With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work. Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations? May also consider black listing, or even better, white listing country IPs. A white list firewall, if you only have to deal with certain country for example, will also work extremely well and it is quite easy to maintain and update as well as simple and fast and very effective. And if you need sporadically to use it outside your white listing, VPN works great. Our threat teams do a lot of work around IMAP threats, and a couple of things to note.. there is a marked increase of IMAP attackers using cloud infrastructure for IMAP hacks.. You might ask the question, do you need to allow IMAP access from the cloud, or do you expect only email clients to access them. If the later, consider blocking AWS, GoogleCloud, Azure from connecting to your IMAP. Note, it may affect certain VPN anonymizers, or Desk Top in the Cloud, but in general given the predilection of certain hacking groups for those, you might like to control that. And there are RBL's now for know IP(s) used by IMAP hackers, including SpamRats RATS-AUTH that can assist in reducing those attacks. And for 'some' IMAP operators, country AUTH blocking might be valuable. Of course, you have to consider your users, and what they can do when traveling or vacationing. A step forward, is to do country AUTH blocking, and insist they use a email client which supports MFA when traveling, or force them to use webmail. Of course, transparent 2FA is the way to go in the long run. Time to update that pull request, so that plugins can dynamically control CAPABILITY advertisements. -- "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: Strategies for protecting IMAP (e.g. MFA)
On 13/11/2021 23:16, Tyler Montney wrote: With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work. Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations? May also consider black listing, or even better, white listing country IPs. A white list firewall, if you only have to deal with certain country for example, will also work extremely well and it is quite easy to maintain and update as well as simple and fast and very effective. And if you need sporadically to use it outside your white listing, VPN works great.
Re: Strategies for protecting IMAP (e.g. MFA)
On Sat, Nov 13, 2021 at 03:34:12PM -0800, lists wrote: > [..] Now Yubikey at least has my attention. But people often leave the > key plugged into their notebook. Very true with the Google equivalent > which I have heard from Google employees. The keys themselves aren't > exactly transferable, but when you have physical access then all bets > are off. Yubikeys are available in several form factors. Not all of them can readily be left plugged in - at least, not into a portable device. The larger Yubikeys stick out too far and would likely fall out or get broken if left plugged in. So, if you don't want laptop users leaving their keys in their devices, give them larger format Yubikeys. (Or Nitrokeys, see below.) > If someone fool actually paid me to be sysadmin, I would use a > Yubikey. [..] Yubikeys are decent in many respects, but not entirely unproblematic: https://en.wikipedia.org/w/index.php?title=YubiKey&oldid=1053509936#Security_issues For portable hardware security tokens with a better security track record (to my knowledge, anyway), see: https://en.wikipedia.org/wiki/Nitrokey https://www.nitrokey.com/ Also possibly of interest: https://www.gniibe.org/category/fst-01.html -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Strategies for protecting IMAP (e.g. MFA)
On 14-11-2021 13:56, Marc wrote: Full access from any IP (except firehol-blacklist and fail2ban) is possible over VPN (openvpn) with MFA (privacyidea). Privacyidea also supplies a mobile-app compatible with a.o. TOTP and HOTP but it provides a more secure way of enrollment (2-step). How are you managing dns/clients etc so only the email traffic is goes through the vpn and no other traffic? There are different use-cases: - Mobile(phone) users will use the externally exposed mail-ports, i.e. they have access from the geo-ip whitelist. This way the mail-app on the phone can be used easily. - Home or laptop users will use the VPN to get full-access through the VPN. I redirect DNS through the VPN (i.e. all queries) but not all other traffic (no default gateway change). - A last case not mentioned earlier is webmail, which is also hidden behind privacyidea MFA. The policy is to use MFA when you first connect to the network from an untrusted location, the one exception is mail over 993/465 but instead that is limited by blacklists, geo-ip and fail2ban. - Kees
Re: Strategies for protecting IMAP (e.g. MFA)
* Tyler Montney: > I'm getting the feeling that people don't have an MFA implementation. Probably because it can be complex to set up and maintain, and more would be gained by educating users and in particular by users actually giving a damn about password-discipline and -quality. On a tangent: I personally find your style of quoting a bit irritating, especially because you leave the whole original message intact. Why not quote in a manner we have successfully used for a couple of decades? Thanks! -Ralph
RE: Strategies for protecting IMAP (e.g. MFA)
> Full access from any IP (except firehol-blacklist and fail2ban) is > possible over VPN (openvpn) with MFA (privacyidea). > Privacyidea also supplies a mobile-app compatible with a.o. TOTP and > HOTP but it provides a more secure way of enrollment (2-step). How are you managing dns/clients etc so only the email traffic is goes through the vpn and no other traffic?
Re: Strategies for protecting IMAP (e.g. MFA)
I will throw in a few interesting projects which have kept my small servers safe: *) firehol.org *) crowdsec.net *) www.fail2ban.org Have a look at those interesting projects! On 13.11.21 22:16, Tyler Montney wrote: With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work. Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
RE: Strategies for protecting IMAP (e.g. MFA)
>30(?) years ago the majority of systems were using a user name to access mail. >Then the 'I want to track everyone companies' made logging in with email the >standard that everyone blindly followed. Now decades later the brute forcing >of known passwords etc is a problem, mostly because the login is publicly >known, so we have to address this with the 2FA preferably giving even more >private information about the user like phone number or high school name, pet >name etc. And this is sort of funny because we had 'a simple' 2fa system where the user name and password were not publicly known. (at least to me, because scans on my servers are 99%(?) email address login attempts) > > why is this funny ?
Re: Strategies for protecting IMAP (e.g. MFA)
On 2021-11-13 22:16, Tyler Montney wrote: Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations? in the end we all know how to play ludo passwords is hard to guess if its odd number of chars, and random selected chars filled with 6 digest as must please confirm your mobil phone numbers is already :) worst case is when sites dont allow more then 12 chars as the password, hmm dont share how many chars used could be part of the game if password used can be divided by 7 will it be a even or odd number ? its still sunday here
Re: Strategies for protecting IMAP (e.g. MFA)
On 13/11/2021 23:34, lists wrote: The thing I don't like is most 2FA token generators. Ultimately you need to transfer the polynomial that generates the code. Most do that with a QR image. Well so much for security! Others have a one time emergency code. Of course we are talking evil maid attacks, which granted is an unacceptable term these days. Now Yubikey at least has my attention. But people often leave the key plugged into their notebook. Very true with the Google equivalent which I have heard from Google employees. The keys themselves aren't exactly transferable, but when you have physical access then all bets are off. If someone fool actually paid me to be sysadmin, I would use a Yubikey. Note Freeotp let's you input the code but also has the QR code fallback. The phone app however hasn't been updated in years. It does allow you to test out a TOTP scheme. It took me no time to write a script to accept the token on Linux. The tricky part if I recall correctly was setting up the script to accept the token that just expired. You would want to do that to minimize user friction. Not to get too far off track but I don't allow any web control over my email server. There is no control panel to hack. I ssh into the server and that uses PKI. I do everything via CLI. If ssh is compromised then nothing else will be secure so email would be the last of my problems. Companies such as Last pass (not an endorsement but an example) supposedly incorporate password generators. If you are going to allow users to set let alone change their own password, you might be able to write a script that generates the password. If I were to go up to the next level of security I would use mail-crypt. It is just that I see so much chatter about getting it to work. *From:* montneyty...@gmail.com *Sent:* November 13, 2021 3:03 PM *To:* dovecot@dovecot.org *Subject:* Re: Strategies for protecting IMAP (e.g. MFA) "Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) password" Again, since it's just me, this is do-able. But I'm looking for something practical as well. I'm getting the feeling that people don't have an MFA implementation. "if the users are sufficiently discipline" As a Sysadmin, I can tell you they genuinely are not and they likely never will be. Hope for the best, plan for the worst. I also want to clarify that I'm not rejecting any of these suggestions, they're all good. On Sat, Nov 13, 2021 at 4:42 PM Ralph Seichter <mailto:ra...@ml.seichter.de>> wrote: * Tyler Montney: > Since this is getting increasingly complicated, I wanted to ask before > going further. What do you all do? Any recommendations? Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) passwords which are used only once (!) and kept either in the user's brain or in an encrypted password store. Ensure that authentication data can only be transmitted over encrypted connections. These measures cover a lot of ground, if the users are sufficiently disciplined. Users are usually the weakest link. -Ralph I almost reached this stage with a personal / open source project I am working on. It is based on Dovecot login scripts, and ejabberd to send alerts in XMPP, from the postmaster account. The details: Custom dovecot login scripts compute a "confidence" score, with two thresholds. The first lower threshold raises a warning sent by xmpp with some details, while the second threshold simply deny the connection. A few of us have been using it for a while, both on mobile and desktop. The current stable version is based on Stretch, as Buster has too many issues, We are now working on the bullseye version. It is perfectly valid to extend the Dovecot custom script to include for instance Duo authentication. Another option would be to extend a Dovecot custom login script to wait for an answer on xmpp message sent by postmaster, or even something crazier like a HOTP / TOTP code. Good luck. Homebox: https://github.com/progmaticltd/homebox -- 𝓐𝓡 - André Rodier -- 𝓐𝓡 - André Rodier
Re: Strategies for protecting IMAP (e.g. MFA)
> Op 13 nov. 2021 om 22:17 heeft Tyler Montney het > volgende geschreven: > > > With the world of ransomware as it is today (aka attacks seem more vicious > and commonplace), anything I expose to WAN must have additional protection. > I've seen a few posts to this list on it. The only thing that helped was that > Dovecot supports OAuth. Through OAuth I figure I could implement MFA. > However, I'd have to host my own identity server. From there, Thunderbird > supports OAuth so that should work. > > Since this is getting increasingly complicated, I wanted to ask before going > further. What do you all do? Any recommendations? If I remember correctly, Dovecot is able to do IP whitelisting in the userdb or passdb. That way, you don’t have to close your mail ports, but you can add an additional layer of protection with an IP whitelist per mailbox.
Re: Strategies for protecting IMAP (e.g. MFA)
He suggested we use should alias as public email? but most providers don't have aliases such as gmail. On Sun, Nov 14, 2021 at 4:48 PM Benny Pedersen wrote: > On 2021-11-14 09:39, Marc wrote: > > Don't use email addresses as login ;) > > why is this funny ? >
Re: Strategies for protecting IMAP (e.g. MFA)
On 2021-11-14 09:39, Marc wrote: Don't use email addresses as login ;) why is this funny ?
Re: Strategies for protecting IMAP (e.g. MFA)
Don't use email addresses as login ;) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -. F1 Outsourcing Development Sp. z o.o. Poland t: +48 (0)12 4207 835 e: m...@f1-outsourcing.eu
Re: Strategies for protecting IMAP (e.g. MFA)
The thing I don't like is most 2FA token generators. Ultimately you need to transfer the polynomial that generates the code. Most do that with a QR image. Well so much for security! Others have a one time emergency code. Of course we are talking evil maid attacks, which granted is an unacceptable term these days. Now Yubikey at least has my attention. But people often leave the key plugged into their notebook. Very true with the Google equivalent which I have heard from Google employees. The keys themselves aren't exactly transferable, but when you have physical access then all bets are off. If someone fool actually paid me to be sysadmin, I would use a Yubikey. Note Freeotp let's you input the code but also has the QR code fallback. The phone app however hasn't been updated in years. It does allow you to test out a TOTP scheme. It took me no time to write a script to accept the token on Linux. The tricky part if I recall correctly was setting up the script to accept the token that just expired. You would want to do that to minimize user friction. Not to get too far off track but I don't allow any web control over my email server. There is no control panel to hack. I ssh into the server and that uses PKI. I do everything via CLI. If ssh is compromised then nothing else will be secure so email would be the last of my problems. Companies such as Last pass (not an endorsement but an example) supposedly incorporate password generators. If you are going to allow users to set let alone change their own password, you might be able to write a script that generates the password. If I were to go up to the next level of security I would use mail-crypt. It is just that I see so much chatter about getting it to work. From: montneyty...@gmail.comSent: November 13, 2021 3:03 PMTo: dovecot@dovecot.orgSubject: Re: Strategies for protecting IMAP (e.g. MFA) "Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) password"Again, since it's just me, this is do-able. But I'm looking for something practical as well.I'm getting the feeling that people don't have an MFA implementation."if the users are sufficiently discipline"As a Sysadmin, I can tell you they genuinely are not and they likely never will be.Hope for the best, plan for the worst.I also want to clarify that I'm not rejecting any of these suggestions, they're all good. On Sat, Nov 13, 2021 at 4:42 PM Ralph Seichter <ra...@ml.seichter.de> wrote:* Tyler Montney: > Since this is getting increasingly complicated, I wanted to ask before > going further. What do you all do? Any recommendations? Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) passwords which are used only once (!) and kept either in the user's brain or in an encrypted password store. Ensure that authentication data can only be transmitted over encrypted connections. These measures cover a lot of ground, if the users are sufficiently disciplined. Users are usually the weakest link. -Ralph
Re: Strategies for protecting IMAP (e.g. MFA)
"Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) password" Again, since it's just me, this is do-able. But I'm looking for something practical as well. I'm getting the feeling that people don't have an MFA implementation. "if the users are sufficiently discipline" As a Sysadmin, I can tell you they genuinely are not and they likely never will be. Hope for the best, plan for the worst. I also want to clarify that I'm not rejecting any of these suggestions, they're all good. On Sat, Nov 13, 2021 at 4:42 PM Ralph Seichter wrote: > * Tyler Montney: > > > Since this is getting increasingly complicated, I wanted to ask before > > going further. What do you all do? Any recommendations? > > Use strong (as in long and/or randomised and impossible to break using > rainbow table attacks) passwords which are used only once (!) and kept > either in the user's brain or in an encrypted password store. Ensure > that authentication data can only be transmitted over encrypted > connections. > > These measures cover a lot of ground, if the users are sufficiently > disciplined. Users are usually the weakest link. > > -Ralph >
Re: Strategies for protecting IMAP (e.g. MFA)
* Tyler Montney: > Since this is getting increasingly complicated, I wanted to ask before > going further. What do you all do? Any recommendations? Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) passwords which are used only once (!) and kept either in the user's brain or in an encrypted password store. Ensure that authentication data can only be transmitted over encrypted connections. These measures cover a lot of ground, if the users are sufficiently disciplined. Users are usually the weakest link. -Ralph
Re: Strategies for protecting IMAP (e.g. MFA)
It seems to me that Oauth weakens security. You allow some other system into your system. Are you running your own email server? I see you are using Gmail for the listserv.If you run your own server there are other steps I would take first other than MFA, though MFA would be the best. Geofencing alone reduces the attack pathways. My server is set up so only 25 sees the entire internet. All other email ports are behind a geofence and a rather large blocking list I have built up over the years of VPS, hosting companies, etc. I'm using 587.I see very little attempts to hack my email server. If I wanted to go the next level up I would use fail2ban. But that would be to cut down chatter in the log file. No bot or person is going to crack my password. It is high entropy. Server passwords are not in clear text. From: montneyty...@gmail.comSent: November 13, 2021 1:16 PMTo: dovecot@dovecot.orgSubject: Strategies for protecting IMAP (e.g. MFA) With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work.Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
