2FA Password Security Issues for Email - Design Considerations
Question asked by Douglas Foster - 9/14/2022 at 9:16 AM
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:
  1. a hardware fingerprint which provides uniqueness,
  2. a configuration tool which ensures that the device has been configured to secure standards, such as data encryption, screen lock password, and workspace boundaries between work and personal applications,
  3. a device security certificate which indicates that the specific device (indicated by the hardware fingerprint) has been configured to the security standards,
  4. a screen lock code or biometric technique for user validation that is delegated from the server to the trusted device, and
  5. a gateway which accepts and verifies connections from configured devices using a proprietary protocol, then relays traffic to the email server using standard protocols.
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.

1 Reply

Reply to Thread
Douglas Foster Replied
I have just been reading about a security breach at Uber.   The theory is that the attacker first obtained initial credentials, but remote access was protected by two-stage password-first 2FA.  Then he kept trying to get in, and each time the correct user got an unsolicited request to confirm the login.   Humans being human, the user failed to detect this as an attack but instead perceived it as another nuisance pop-up.   Eventually he clicked to confirm the connection and the hacker was in.

This scenario is a strong argument in favor of time-based 2FA tokens or second-factor-first 2FA, rather than the more flexible password-first 2FA like DUO.

Any form of 2FA also depends on you ability to ensure the 2FA configuration and reset processes.

Reply to Thread