[MlMt] Follow Up to Email Concerns

[Bill Cole]

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 at 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
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire