Password complexity has been touted for some time to prevent identity theft. Especially in an Active Directory environment. Typical password complexity rules in Active Directory are:

• Uppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
• Lowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
• Base 10 digits (0 through 9)
• Nonalphanumeric characters: ~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/
• Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

Back in 2016, Microsoft released a password recommendation paper based on Microsoft's Azure experience (seeing millions of username and password attacks per day). In the paper, they highlight that long passwords can mitigate the desired intent of security by:

• For simplicity, end users might repeat the same base password multiple times
• To avoid passwords from being cracked, the character length of passwords (18-20) characters long would lead to bad behavior in in users (such as keep the passwords on their desktop, a piece of paper in their pocket), etc.
• Rotation of passwords with forced expiration is found to have little value. If a cybercriminal has a keystroke logger on an end user's machine; the effort of changing the password will offer no containment to the attack.

Microsoft has also found substantial containment of stolen identity in stolen credentials for SaaS applications could be mitigated by multi-factor authentication.

According to Microsoft:

"We strongly recommend enabling always-on multi-factor authentication for all admins in your organization, especially subscription owners and tenant admins," Microsoft's announcement indicated. "Seriously, go do this right now."

In this blog series, we will examine different aspects of enabling  two factor authentication (2FA) for Office clients. The first we will review is the end client.

Before that discussion, we must define what "modern authentication “ is. Modern authentication is based on Active Directory Authentication Library (ADAL) and OAuth 2.0. With clients who are Oath aware, you can properly respond to a 2FA challenge. Legacy applications like ActiveSync which historically use basic authentication do not.  With the release of iOS 11.0, the ActiveSync client for the iPhone supports.

Even when it comes Office, support for ADAL must be reviewed. If you look at Table 1 below for Outlook clients, you will see the only native version of Outlook which would support MFA out of the box would be 2016.

 Table 1

So office 2016 is enabled by default, office 2013 would need to have the switch in the user portion of the registry toggled to enable the feature. Outlook 2010 falls in the same category as native versions of ActiveSync, which relies on basic authentication.  

While we can acknowledge the value in 2FA in providing real value in securing user identities in a SaaS suite like Office 365, we can see the consumer applications of this suite (in this case OWA, Outlook, and ActiveSync) but have different experiences depending on the versions the end users are using.

While Microsoft has produced a band-aid for this, in the next article, we will discuss applying MFA globally relative to conditional access ( a more selective approach).