During Microsoft Ignite 2017, Microsoft was promoting the #DeathToPasswords hash tag rather aggressively and socializing the problems that exist with passwords. Many of the highlights focus on the ineffectiveness of passwords, policies, and updated guidelines from NIST.

One very interesting session involved a demo showing a Password Spray tool. Password Spraying is a nuanced means of performing a brute force attack that is rather effective the larger the target. With cloud services, we’re all becoming the same target. How a Password Spray works:

The attacker acquires a tool that works similarly to brute force tools in that it uses dictionaries and other tools to adjust to key spaces. The difference is that the tool uses botnets and other anonymizing capabilities (TOR, for example) so that their traffic doesn’t come from the same source. Instead of focusing on a particular credential, it spreads out attempts against an individual credential over extended periods of time (perhaps around six hours).

These behaviors allow the attacker to go undetected for a long time and eventually are able to compromise some accounts (usually 1% in a first pass). What this illustrates is that relying solely on passwords means it is a matter of time as to when you will have some users compromised.

Password Policies Don’t Help Much

The issue with attempting to address this with ever stricter password policies is that users respond in a very predictable manner. For instance, if you require a password of 16 characters, users will take passwords that are too short and just repeat them:

Four => FourFourFourFour GoodPass => GoodPassGoodPass

Introducing additional characters is also mostly an exercise in folly:

Password => P@ssw0rd BetterMix => B3tt3rM1x

Requiring frequent password changes with a history also doesn’t help matters:

Password => Password01, Password02, etc.

Finally, requiring a longer minimum password limits the increase in key space, which is counter to the purpose of allowing longer passwords. For example, if you require 16 characters, then you remove all possible passwords that are less than 16 characters, which is a sizable key space.

Addressing Behavior Mostly Doesn’t Work

Many times I have heard that “we’re attempting to create a technical solution to a behavioral problem.” That might be true, but the behavior is rooted in a situation that is becoming impossible to address otherwise and the behavior is mostly human nature. The compute capabilities that exist today are exposing the practical limits of passwords.

Showcasing the Issue

With a success rate of 1%, comprising credentials becomes rather trivial and is merely a foothold into an organization. For instance, if credentials for a mailbox are compromised, an attacker could sign into the account and establish mailbox rules that hide conversations from the mailbox owner and forward the conversations to an external address. With such a scenario, the attacker could be hidden and perform spearphishing attacks on other users in the organization, attempting to gain additional credentials or find users in finance or accounts payable.

I have heard accounts of this exact scenario playing out and organizations being defrauded of $200-400K via wire transfer.

MFA is the Solution

Multi-factor authentication is the solution to this issue. Instead of worrying so much about passwords, create a password policy that users can adhere to and implement additional factors of authentication. Even if the credentials are compromised, attackers will not have access to the other factors of authentication.

Traditionally, an additional factor of authentication is facilitated by something you have, like a One-Time PIN that is provided by a hardware token.

Some factors:

Something you have: hardware token, software token, smart card, certificate

Something you know: password, PIN, answers to questions

Something you are: facial recognition, finger prints, retinal scan

Somewhere you are: corporate location, country

If you find that a user’s credentials are compromised, you could force a password change and reset tokens, but that is merely delaying issues until the next compromise. MFA eliminates access even with compromised credentials because access still requires the other factors that have been established and required for authentication.

MFA can be used with various scenarios, as well. For instance, if users are on the corporate network, a policy can permit users without requiring MFA. However, if users are not on the corporate network, MFA can be required.

Azure Active Directory Premium and Enterprise Mobility + Security

Azure AD is the backend identity provider for Office 365 services and MFA capabilities exist. However, Azure AD can become your centralized identity provider for other online services. This provides a means to extend controls to other applications and reduce the number of credentials required for users. Azure Active Directory Premium comes with MFA capabilities integrated. The MFA capabilities come from the acquisition of Phone Factor that allows phone calls or text messages as media to deliver one-time PINs; however, integration with the Microsoft Authenticator app provides a software token mechanism.

Azure MFA can be used with Conditional Access per application, group membership, and other conditions to determine if access is permitted. In addition, risk scenarios can be evaluated. For instance, let’s say that User A is on the corporate network and doesn’t normally require MFA under these conditions. However, 5 minutes after signing in, User A has another successful sign in from a location that is much further away than can be travelled in 5 minutes. If this happens, access tokens can be reset forcing User A to sign back in and require MFA, even if accessing from the corporate network.