This veers far off-topic, but it is somewhat relevant to anyone using
email, which includes all MailMate users, so please forgive the verbose
ranting...
On 2021-06-29 at 10:13:10 UTC-0400 (Tue, 29 Jun 2021 10:13:10 -0400)
Glenn Parker <mailmate@lists.freron.com>
is rumored to have said:
I would be interested in a deeper discussion of the actual security
threats that all this awkward 2FA/OAuth2/whatever are meant to
address. I mean, I certainly understand the basic need for
authentication (and encrypted transmission) to limit access to private
information, but it seems like some folks are going way overboard for
email here. All security is a tradeoff with convenience, like a fence
around your property that limits free access to everyone, including
yourself. So, it’s important to weigh the tradeoffs.
To restate my question: what are the downsides to a compromised email
account, and do they justify this level of access control?
Email is a critical link in many password recovery/reset systems, so
compromising an email account can enable an attacker to identify and
compromise a broad range of other accounts. For example, I am aware of
banks and brokerages which will email a password reset link without any
form of secondary authentication or even sanity checking of where the
'click' is coming from. Because an email account can often be used to
authenticate a SIM swap on a mobile phone account, takeover of an email
account can break SMS-based 2nd-factor authentication as well.
Email is also a key form of communication in many businesses. A major
direct abuse of compromised email accounts is for an account hijacker
to use the account of an executive to direct employees to do things that
effectively give the attacker money. I won't do an in-depth description
here, but you can find details of incidents and by searching for
"Business Email Compromise" or "BEC attack." Often those attacks are
mounted via simple forgery rather than account hijack, but the defenses
against the forgery forms actually make account hijacking more
effective.
I help manage email systems that see unceasing attempts to break into
accounts, often using username+password combinations leaked by other
systems. At any point in time, one smallish mail system I work with (~2k
users) will have dozens of attack sources temporarily blocked at the
network level by automated tools that can detect some careless
authentication attacks. The simple fact that the Bad Guys find this sort
of attack to be worth mounting is enough for me to know that it is worth
mitigating, even if I were not aware of how exactly they use compromised
accounts. Unfortunately, due to users ignoring vehement advice about
password re-use, I have seen the impact that email compromise can have
on both businesses and on individual lives.
Users can perform a limited number of actions in the email universe:
read mail, delete mail, reorganize mail folders, and send mail:
* Read mail: private information could be exposed, obviously.
This is critical more because of the leverage it provides to other
systems than it is for the bulk of information in mail.
* Delete mail and reorganize mail folders: important (?) records or
progress tracking could be lost or “misplaced”. (But, seriously,
don’t use email for critical data storage).
If you know how to actually get people to follow that critical advice,
you could make millions.
I have had users who treat their "Trash" folders as critical archival
storage.
* Send mail: IMHO, the biggest threat to an organization is the
potential for social engineering via “authentic” appearing
email.
It's about even with the leverage of reading critical emails like
password reset messages, in my opinion.
I’m going to dismiss the deletion and reorganizing actions as de
minimus (but tell me if I’m missing something).
Covering tracks is useful. If I use your email account to reset your
banking password, I may be able to prevent you from seeing it happen by
rapidly removing the reset message.
Maintaining privacy for reading email is a valid concern, but I
don’t think it justifies having to authenticate on every IMAP
transaction.
I disagree, as do essentially all of the other people who have helped
develop the IMAP protocol and its common implementations over the past
~30 years. Fortunes have been made selling email privacy and other
fortunes made (some even legally) compromising it.
OTOH, bogus emails are potentially far more serious, and I could see
reasons for much tighter access when sending mail. And distinct
protocols controls for reading and sending could certainly be
implemented.
We're already there. While both SMTP and IMAP are resistant by design to
2FA, mail systems have mostly moved away from the traditional model of
basic SMTP for sending mail to its derivative 'submission' protocol that
enforces authentication at the transport layer and additional tools like
DKIM and DMARC that put authentication into the application layer,
embedding server signatures in headers and publishing domain policies in
DNS. SMTP/submission sessions are typically single-transaction and last
for seconds. IMAP sessions are mostly short, but they are almost always
multi-transaction and mostly last on the order of a minute, with some
being kept open idling for days.
I’m surprised that the level of flexibility for gating access to
email services seems so limited today. The crux for these matters is
the directory service that validates end user credentials. It seems
like we could implement some flexible and fairly sophisticated
authentication protocols (between the directory and the IMAP/SMTP
server) that would not require any direct tweaks to email clients.
This might allow, for example, a user to authenticate once via 2FA,
and then maintain IMAP access (using standard IMAP authentication) for
some number of days before having to authenticate again.
That's basically what OAuth2 does. It requires IMAP client support
because the client needs to know when and how to make the user go
through the out-of-band authentication procedure again.
As with all new open security schemes, it takes time for everyone to
reach interoperability.
It’s been a while since I worked on the software for such services,
so maybe there’s a lot I need to catch up on, but I basically feel
that “ultra-hardened” email is a poor idea.
It sucks. The alternatives are worse.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate
