dovecot - Oct 2020 - SV: Looking for a guide to collect all e-mail from the ISP mail server

1: I meant like this:

Without whitelisting, you can't login to SMTP or IMAP, password isn't
valid
at all.

To enable SMTP and IMAP, you then either surf ro webmail, or the 2FA
gateway, and login with:
Username + password + 2FA code + captcha.

When all is valid, then your IP is whitelisted for SMTP and IMAP access.
This still means you have to use usename/password for SMTP/IMAP.

So how would this be a security hole?
Instead of using only username+password for SMTP/IMAP?
The whitelisting procedure ADDS to the security. The baseline security with
username+password is already there, but now you ALSO need a whitelisted IP
to even get a chance to authenticate.

Kind of stupid that there doesn't exist some common standard for 2FA that
works in email clients. Some clients do support TLS client certificates, and
some clients do support certain "extensions" for 2FA auth. But only
common
supported in all clients is password auth without 2FA, which is pretty
insecure.

Outlook have solved 2FA auth with a webview that uses OAUTH to create a
authentication token, for use with SMTP/IMAP using some proprietary
extension with gmail and hotmail.
But that webview is not something you can trigger from a third party
service.

Captcha is there to prevent bruteforcing. If a valid captcha is submitted
along with a 2FA code, you could lock out the account for 1 minute for each
invalid attempt.
If a invalid captcha is submitted, you ignore the request  completely.
This then prevents a attacker from flooding the server with invalid auth
requests for the sole purpose of keeping a user locked out. (Account Lockout
DDoS attack)


I had problems with my mail password getting hacked all the time. The
instant I added IP whitelist to my system and blocked all non-approved IPs
from authenticating at all (so you must have username + password + correct
IP to gain access) - then all hacking of my passwords have stopped. IP
lockout was the solution to my problems.


2: The idea with the reverse-proxy gateway, is only to prevent auth-bypass
or non-authenticated security holes. If you have a web service that has a
suspected vulnerability that could be used without authenticating, or could
be used to bypass authentication, then you put a reverse proxy in front. The
reverse proxy does the authentication, and only forwards requests belongning
to authenticated users.
Even if the webservice behind, has a auth-bypass hole, it cannot be
exploited, as the reverse proxy is behind the service, and non-authenticated
users cannot even touch the webservice at all.


-----Ursprungligt meddelande-----
Fr?n: dovecot-bounces at dovecot.org <dovecot-bounces at dovecot.org> F?r
@lbutlr
Skickat: den 27 oktober 2020 15:57
Till: dovecot mailing list <dovecot at dovecot.org>
?mne: Re: Looking for a guide to collect all e-mail from the ISP mail server

On 25 Oct 2020, at 22:47, Sebastian Nielsen <sebastian at sebbe.eu>
wrote:
> 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.

I mostly agree with the sentiments in your email, but whitelsiting IP
addresses is a HORRIBLE idea and a massive gaping security hole and using a
captcha is only slightly less horrible and user-hostile. If you are using
2FA there is absolutely no reason to use a captcha.

A 2FA gateway that reverse proxies the webmail is quite good, but enforcing
good passwords and using TLS is good enough for nearly all use cases.

(I recently upped the minimum password length from 12 characters)

-- 
Ah we're lonely, we're romantic / and the cider's laced with acid /
	and the Holy Spirit's crying, Where's the beef? / And the moon is
	swimming naked / and the summer night is fragrant / with a mighty
	expectation of relief


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5715 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20201027/0599b1e6/attachment-0001.p7s>

On Tue, 27 Oct 2020, Sebastian Nielsen wrote:
> Kind of stupid that there doesn't exist some common standard for 2FA
that
> works in email clients.
You can bodge it for HOTP/TOTP hardware token generators.  Dovecot allows
custom plugins to check passwords.  The plugin can take passwords of
the form {password}+{2fa-token}, then split each part to check against
authentication systems to check validity.

Joseph Tam <jtam.home at gmail.com>

I would have to also hack the email client since I don't enter my 20
character high entropy password when I send or retrieve email.

You really need an email standard to integrate TOTP. To be realistic, you need
Gmail to use it. Whatever Gmail wants is essentially a defacto standard. I live
in the real world, so whatever Google wants, I comply.







? Original Message ?


From: jtam.home at gmail.com
Sent: October 27, 2020 3:57 PM
To: dovecot at dovecot.org
Subject: Re: SV: Looking for a guide to collect all e-mail from the ISP mail
server


On Tue, 27 Oct 2020, Sebastian Nielsen wrote:
> Kind of stupid that there doesn't exist some common standard for 2FA
that
> works in email clients.
You can bodge it for HOTP/TOTP hardware token generators.? Dovecot allows
custom plugins to check passwords.? The plugin can take passwords of
the form {password}+{2fa-token}, then split each part to check against
authentication systems to check validity.

Joseph Tam <jtam.home at gmail.com>