<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div><div class="plaintext"><p dir="auto">In my opinion as someone whose primary research area, for
<br />
more than 30 years, has been security, your email credentials
<br />
are the most valuable you have. I would add that this opinion
<br />
is shared by most security professionals. Why? Because
<br />
your email account is used to reset access to almost every
<br />
other online account you have.
</p>
<p dir="auto">This doesn't mean that implementations can't be done better.
<br />
However, one constraint is that a major mail service can't
<br />
afford to have people continuously connected. A quick Google
<br />
search says that gmail has 1.8 billion users—and even with
<br />
the very large number of servers that Google has, that's too
<br />
many TCP connections. This means that most clients have
<br />
to disconnect between sessions. To be sure, it's certainly
<br />
possible, in principle, for an IMAP server to send a re-auth
<br />
token to the client to be used on the next connection attempt,
<br />
but I don't know IMAP well enough to know if that's among
<br />
the very many IMAP options even defined, let alone implemented.
</p>
<p dir="auto">On 29 Jun 2021, at 10:13, Glenn Parker wrote:
</p>
<blockquote><p dir="auto">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.
<br />
To restate my question: what are the downsides to a compromised email account, and do they justify this level of access control?
<br />
Users can perform a limited number of actions in the email universe: read mail, delete mail, reorganize mail folders, and send mail:
<br />
* Read mail: private information could be exposed, obviously.
<br />
* 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).
<br />
* Send mail: IMHO, the biggest threat to an organization is the potential for social engineering via “authentic” appearing email.
<br />
I’m going to dismiss the deletion and reorganizing actions as de minimus (but tell me if I’m missing something).
<br />
Maintaining privacy for reading email is a valid concern, but I don’t think it justifies having to authenticate on every IMAP transaction.
<br />
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.
<br />
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.
<br />
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.
<br />
Glenn P. Parker
<br />
glenn.parker@comcast.net
<br />
_______________________________________________
<br />
mailmate mailing list
<br />
mailmate@lists.freron.com
<br />
<a href="https://lists.freron.com/listinfo/mailmate">https://lists.freron.com/listinfo/mailmate</a>
</p>
</blockquote><br /><p dir="auto"> —Steve Bellovin, <a href="https://www.cs.columbia.edu/~smb">https://www.cs.columbia.edu/~smb</a>
</p>
</div>
</div>
</body>
</html>