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)
