Email systems are very difficult to secure using Two-Factor authentication.   First, because there are so many connection methods which may require off-network access:  MAPI, EAS, EWS, IMAP, POP, SMTP, XMPP, and Webmail.   It is further complicated by the fact that multiple protocols share port 443: MAPI, EWS, EAS, and webmail.  

Perhaps more importantly, all of the connections other than Webmail rely on email client applications, and these applications usually use (or even require) passwords to be stored on the device with reversible (and therefore weak) encryption.  If a device with stored password falls into the wrong hands, we have to assume that the password can be found and cracked.   By default, email system administrators have no control over which devices can contain stored passwords.  Of course, most email client applications also store email messages, so the data risk applies to both the login credentials and the stored messages.

Additionally, email client applications are designed for long-running, nearly permanent, connections to the server.  We have no reason to assume that a connected client application is under continuous control of the user represented by the connected credentials.

The current industry workaround is to use difficult to guess passwords for email client connections, which is obviously not 2FA, and 2FA only for webmail connections.   

A more sophisticated and effective solution would require custom software components with these features:

This class of application exists from third parties, and these solutions do provide enhanced security for external devices, particularly cell phones.   They would need to be coupled with a Web Application Firewall that prevents external connections attempting to bypass the proprietary gateway.

SmarterMail’s implementation of 2FA requires SmarterMail passwords rather than Active Directory integration.   This has the side benefit of ensuring that a compromised email account does not also compromise other Windows domain resources and other remote access methods.

Issues with the Secondary Authentication Method

Authenticator applications and fobs generate random numbers based on a uniquely assigned random number seed, coupled with a time-of-day function applied to the random seed.     These implementations allow the password and second factor to be entered at the same time, so that if a failure occurs, an attacker has no knowledge of whether the password or the 2FA code was the problem.   If the user interface expects the 2FA code to be entered into the same field as the password, an attacker may be unable to detect that the 2FA code was even expected.    Another advantage is that the code-generating application does not need network connectivity.   A disadvantage is that the code generation process can be configured on an unlimited number of devices.   The mail system administrator has no ability to control which devices, or how many devices, get configured.   Similarly, the system administrator has no ability to force the code generation to be removed from a device.   If a device is compromised, the old seed must be revoked, a new seed generated, and all devices must be reconfigured.  SmarterMail supports this form of two-factor authentication when set to “Authenticator App”.

Another class of applications checks the user’s primary login credentials first, then expects the second factor to be authenticated by methods which are specific to the user account.   This allows for a wide variety of authentication methods, but has the downside that it permits password guessing attacks on the primary password.   SmarterMail supports this form of two-factor authentication when set to “Recovery Email Address”, but email delivery is the only supported method for communicating with the user.

An alternative, but less common, design prompts for the second-factor first, then prompts for the primary password if the second-factor has been accepted.    In the observed implementations, the user is restricted to one specific type of second-factor code, and the code generation requires network connectivity to the server.