Good luck with all that coding. I have four years now of running my own email 
server. Zero hacks. I keep the attack surface to a minimum. Less is more. 

One thing you don't want to do is write your own code. This stuff is always way 
harder than you think. Worse yet you run alpha generation code because you are 
the only one using it. All software has bugs. What you need is a mass of users 
flogging the code and finding the bugs. 

Now if you do use a browser, you have to deal with leaks, bugs, possible 
process interaction if more than one tab is open, and possibly browser 
extensions hacks if extensions are used. 

Count me out. 

And did you miss the part where I was hacked via RoundCube? 






          Original Message      


From: sebast...@sebbe.eu
Sent: October 25, 2020 9:47 PM
To: dovecot@dovecot.org
Reply-to: dovecot@dovecot.org
Subject: SV: Looking for a guide to collect all e-mail from the ISP mail server


>>"Never use a  browser for email."

I don't agree.
In fact, using a browser for email or atleast initial setup, is actually more 
secure. This because SMTP/IMAP clients normally don't support 2FA, so you would 
have to "hack" a solution to enable 2FA for email.

This can be made in 2 ways: Either, you have a full fledged email setup. Whats 
important, is, to prevent auth-bypass holes, you remove the authentication in 
RoundCube or whatever webmail you use, and instead use a reverse-proxy or 
firewall authentication instead. Thus an unauthenticated user doesn't even 
touch RoundCube/webmail at all, but must authenticate at a prior stage.

The second way, is to not have webmail at all, but instead have a 
authentication gateway in browser, where you must auth with 2FA and captcha. 
The only purpose of this gateway, is to authenticate users with 2FA before 
their IP is whitelisted.

After this, you simply have a script, that upon valid login (with 2FA) in 
either webmail or auth gateway, you set the authorized IP of the user to this. 
Whats happen then, is that each account will have an authorized IP attached 
(you could limit it to the /24 to cater for mobile clients), and then login to 
that account, will only be accepted from that authorized IP.

This then allows SMTP/IMAP usage from that IP.
If you want to go even more secure, you could restrict the firewall to the list 
of all IPs that all users have dynamically, and then in the SMTP/IMAP server, 
lock down auth to the authorized IP of that particular user account only.

Its very important, that upon authing with a incorrect IP, that the server 
responds in the same way as a invalid password was specified, in this way, if 
someone attempts to bruteforce the password, they will "miss" the correct 
password, if the server does not react differently to a correct password but 
invalid IP. Thus bots that bruteforce will not gain any success.


All this can be combined with permanent whitelists and geoIP whitelists, to 
avoid users having to authenticate with 2FA for "trusted" locations. One 
example would be to have the local office as permanent whitelist, and also have 
it that any IP in the user's "home country" is permanently whitelisted for his 
account once the user authenticates with 2FA.

Other IPs outside his home country, is then only whitelisted once, next 2FA 
login, the old whitelist is simply deleted.

Reply via email to