Password rotation friend or foe?

According to Microsoft best practice for implementing a password policy includes enforcing “complexity requirements” and requiring at least 8 characters to ensure at least 218,340,105,584,896 different possibilities for a single password, sounds impressive doesn’t it!  In addition to this we can enforce the account lockout policy to ensure that each user account is locked out should an incorrect password be entered a certain number of times.

The problem with this statement is, it implies a level of security that isn’t really there; for example, 218,340,105,584,896 password possibilities sounds like a lot however it really doesn’t take into account human behavior when selecting a password.

In order to meet the Microsoft password complexity requirements all we have to do is not use our account or display name and then 3 of the following 5 options:

• Uppercase letter
• Lowercase letter
• Base 10 digits
• Non-alphanumeric characters (for example !, $, #, %)
• Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

This means that a password of “Password1!” would technically meet all the password complexity requirements, however I doubt anyone would argue that is a particularly strong password.  Ironically this human behavior of selecting a password that is easy to remember is further negatively influenced though other options of the password policy, such as the requirement to change the password every 30 or 90 days, this is due to the fact that if a user has to continually change their password they will look for an aspect they can rotate or vary.  When this occurs the password structure does not change, just the details within it, which typically makes the password more easily guessable, for example:

Password Structure: Use the month (with initial caps) followed by year
Password Implementation: January2016, February2016,

We can use 3rd party software to remove the users ability to use common words such as the company name; or seasons however if we make the requirements too stringent they may be inclined to write the password down. Therefore, we find ourselves in a balancing act whereby in actual fact; users may be more likely to choose a longer and more complex password or pass phrase (which is obviously what we want) if they do not need to change it every 30 or 90 days.

Reference:
https://technet.microsoft.com/en-us/library/hh994562(v=ws.11).aspx