On 2022-04-27 at 01:47:06 UTC-0400 (Wed, 27 Apr 2022 17:47:06 +1200)
AndrewHardy <[email protected]>
is rumored to have said:
Hi,
Following this thread has been quite intriguing. Interesting
conversation indeed.
On a similar topic but probably more focused on addressing root cause
(which in mind is just passwords = the devil of security) and the
inherent insecurities with using them.
I’m very interested in what options / solutions (if any) exist that
allow you to use a passwordless approach to authenticating your users
against imaps/pop3/smtps/submission services (tls encrypted of course)
acknowledging that it’s extremely unlikely to address abuse of the
non-auth enabled smtp listener so won’t rid the server of ‘all
noise’ or ‘hacking attempts’ nor address lower level
exploit/attacks (network/protocol level etc).
Do any solutions exist today? I suspect the issue isn’t so much what
you can do server side as possibilities are near endless but
constraint is email client support which in my mind is the primary
issue? Is that a reasonable conclusion?
I think it depends on what you mean by 'primary' but basically: yes. The
reason client support is extremely uneven is that there are not easily
implementable standards for how to avoid passwords with SMTP AUTH. The
most common mechanism is to use OAuth2, which requires client developers
to register their authenticating apps with service providers and get
their blessings to be used with their services. Typically the
out-of-band OAuth2 interaction requires some form of one-time password.
Another approach is to use client X.509 certificates, a mechanism that
is better for automated use (i.e. where there's no one available to
respond to perform the OOB OAuth2 renewal.) Both client certs for
authentication and OTP+OAuth2 are non-trivial to do correctly in a MUA.
The real root cause is deep and insoluble. Passwords are problematic
because they can be guessed or stolen. A certificate can be stolen. A
hardware token (e.g. RSA key) that generates random-ish one-time
passwords (i.e. HOTP) can itself be stolen and has seed and counter
values that can be stolen. A TOTP authenticator app (e.g. Google
Authenticator or MS Authenticator) has a seed value. To fix that
problem, nth-factors typically are time-limited. TOTP codes expire every
minute, typically. HOTP codes are strictly one-use so that a thief needs
the seed, counter AND to prevent legit use. Certificates expire, and the
trend is towards making them expire faster. OAuth2 tokens expire. All of
these create the need for regular human interaction to renew the
authentication, and so feel inconvenient. A 'slick' solution is
impossible because there needs to be a barricade against a thief
automating access with stolen credentials.
I’m guessing what I’m asking is if there’s an open source
solution that doesn’t require you to pay Microsoft or others
extraordinary amounts of money just to get some smart protection?
If you want to do it now with Postfix, client certificates from your own
CA are probably the best way to go. Based on the angst displayed on that
topic here over the years, it is not trivial to get set up correctly,
but it is possible. Dovecot SASL supports OAuth2, so that's also an
option if you're willing to handle the backend yourself.
--
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
