Dictionary attacks and password protection in Microsoft Azure AD

Dictionary attacks, such as brute-force and password spray attacks, still find success every day. In a dictionary attack, attackers try combinations of usernames and well-known and often-used passwords against an authentication service. The brute-force attack is more noisy and easier to recognize. With brute force, an attacker will try lots of passwords for  a single user account, hoping that one of the attacks will be successful. In the backend, you will see lots of failed login attempts, so you can easily react to them. However, a password  spray attack is way more sensitive since an attacker will only use a small set of passwords against lots of user accounts. If the attacks are very slow and widely distributed, it is very hard to notice an attack. To avoid successful password spray and brute-force attacks in the cloud and, to be more precise, in Azure AD, there are some easy best practices:

• Encourage your users to use passphrases instead of passwords.

• Block passwords or patterns that should not be used in your environment.

Currently, you can use passwords or passphrases with up to 256 (!) characters in Azure AD. Even if you were only to use all 26 letters from the alphabet in uppercase and lowercase, this would mean (2 x 26) 256 possibilities, which results in a number near infinity.

With that said, and knowing that you cannot only use uppercase and lowercase letters but also numbers and other characters in a passphrase, this results in a plethora of combinations. You see that you should definitely enable and encourage your users to use passphrases with a lot of characters.

For passwords you do not want to allow in your organization, there is another option you can enable. By default, Microsoft does not allow you to use passwords or password patterns that can be found on password lists and that are known to be used in dictionary attacks. For example, a pattern that is not allowed is your username, or any part of it. In addition to that, it might make sense for your company to avoid passwords that are easily relatable to your enterprise. These could include well-known marketing phrases, corporate abbreviations, and so on. In Azure AD, there is an option to create a custom banned password list that can be used to either audit or enforce the usage of secure passwords.

You can even use this custom list to enable password protection for your on-premises

Windows Server AD by installing and enabling an on-premises agent.

The custom banned password list can contain up to 1,000 case-sensitive terms between  4 and 16 characters in length. One nice feature is the fact that character substitution such as e and 3 or o and 0 is considered.

 

In order to configure a custom banned password list, you need to navigate to Azure Active Directory | Security | Authentication methods | Password protection in the Azure portal, as shown in Figure. On that screen, you'll also find configuration options for the Custom smart lockout feature. As mentioned before, you might find an on-premises AD security policy forcing accounts to be locked after a given number of failed login attempts. This is kind of an on/off decision, and you can easily increment the lockout counter with the same password to force account lockouts. Remember that this is why you should disable such policies in your on-premises AD and monitor login attempts instead.

However, in Azure AD, smart lockout is the feature that combines the best of two worlds: letting users work without blocking them unnecessarily and preventing attackers from guessing your passwords at the same time. To achieve that goal, smart lockout comes with some interesting features:

• Users are not meant to be blocked from working. Smart lockout recognizes attack attempts and login attempts from valid users. Attack attempts are treated differentlso legitimate users are still able to work while attackers are blocked.

• Smart lockout stores the last three bad password hashes. Doing so, you cannot simply use the lockout counter to enforce DoS by using the same bad password several times.

• The default lockout threshold is 10 bad attempts with a lockout duration of 60 seconds. Smart lockout is always on for Azure AD; however, it does not guarantee that legitimate user accounts are never locked out. The service uses familiar versus unfamiliar locations to try to figure out whether a login attempt comes from a bad actor or a genuine user. However, there is still a probability that users will be blocked from logging in. And one important point is that the service does not necessarily protect you from highly sensitive password spray attacks. This is not because the service is bad but because those kinds of attacks can become really difficult to discover.

Imagine an attacker has a list of nine passwords and they use a widely spread network of bots to attack thousands of user accounts in one custom domain over a time frame of weeks. In that situation, there are some facts to realize:

• The number of login attempts per user account will not exceed the default threshold of 10.

• By using several widely spread host systems to run the attack, it is hard to discover whether a login attempt is valid or malicious. However, Microsoft will also take into account whether a login attempt comes from a known bad IP address or an unfamiliar location.

So, in this scenario, the service will probably not block an attacker. Of course, the nine passwords in the list need to be quite sophisticated to be accepted. However, there is still a probability of an attacker being successful at guessing your passwords.

Now that you know why passwords are not enough to protect your accounts, let's move  one step further and see how multi-factor authentication (MFA) can give an additional layer of security to your accounts.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)