Microsoft Recommending Non-Expiring Passwords to Office 365 Customers

My Office 365 admin portal displayed a new recommendation when I logged in last week. Microsoft is recommending that user account passwords be set to never expire. My tenant is currently set to an expiry period of 90 days, whereas a newer tenant I was doing some testing with last month has defaulted to 730 days. I am not sure whether a tenant created today will default to 730 days or to non-expiring passwords.

This recommendation has so far appeared only in tenants that I have access to that are configured with First Release for everyone, and that aren’t enabled for directory synchronization. I imagine that the recommendation is being rolled out slowly.

The thought of non-expiring passwords might raise a few eyebrows in some organizations. For a long time the accepted position for passwords was to change them regularly. This thinking comes from a time when passwords were the single factor of authentication for most systems, with multi-factor authentication being relatively rare. Times have changed though, and recent research has concluded that requiring users to change their passwords regularly will usually lead to them:

• choosing weaker passwords to begin with, because they don’t want to learn complex new passwords each time they are forced to change it
• choosing new passwords that are only a minor variation of their previous password, e.g. Monday01 changes to Monday02

So what should we do if we aren’t requiring our users to regularly change their passwords?

Microsoft’s recommendation links to a page in the Office 365 admin portal that allows you to set user passwords to never expire. You can access the same password expiration settings in the Settings -> Security & Privacy section of the portal.

From that page (above) there is a link to learn more about the recommendation. The link goes to a Microsoft white paper titled Microsoft Password Guidance and authored by the Microsoft Identity Protection Team. It’s an interesting read and should be useful for anyone trying to build security policies based on modern standards instead of legacy ideas.

As you would expect, there’s an element of user education involved in good password selection. Forcing users to adhere to complex password policies, such as requiring multiple character sets, has been shown to be counter productive. Similarly, forcing users to make use of difficult to remember passwords is detrimental to the user experience, and makes users view passwords as a burden rather than an important security requirement.

Microsoft instead recommends:

• An 8-character minimum password length (Azure AD/Office 365 has a maximum password length of 16 characters for cloud identities)
• Remove character composition requirements (i.e. don’t require combinations of uppercase, lowercase, numbers, special characters, etc)
• No password expiration
• Ban common passwords
• Educate users to not re-use corporate passwords for other systems and apps
• Enforce multi-factor authentication
• Enable risk-based multi-factor authentication challenges

The first three items are configurable by you as the administrator. The fourth item, banning of common passwords, is handled automatically for you by Microsoft for cloud identities. Here’s an example of what a user will see when they try to reset their password to one of the banned passwords.

Educating users to not re-use passwords is a little trickier. You can give them all the education in the world but password re-use is not something that can be easily detected and prevented.

That brings us to multi-factor authentication. MFA is one of the best password security measure that you can implement. MFA is particularly important for admin accounts, but it should be deployed to users as well. However, in a reader survey I ran earlier this year, 54% of respondents said they do not use MFA at all. Only around 20% of respondents say they use MFA for all admin and user accounts. The main reason given for not rolling out MFA is the inconvenience of users having to enter MFA codes at sign in. However, as I showed in this article, it’s possible to remove much of that inconvenience using Azure Active Directory conditional access policies.

The final item on the list is risk-based MFA prompts. Azure Active Directory (and therefore Office 365) is able to identify risky sign-in behaviour based on a variety of signals:

• Leaked credentials – Microsoft monitors sources of breach data dumps and also acquires breach data from researchers and law enforcement agencies.
• Anonymous source IPs – Examples include known proxy services that are typically used for malicious behaviour.
• Impossible travel – two sign-ins from geographically distant locations. I triggered one of these while on vacation in the USA by using my Freedome VPN service to connect to an Australian endpoint to access some geo-restricted content.
• Unfamiliar locations – sign-ins from locations that are not close to where the user normally logs in, and are from unknown devices.
• Infected devices – sign-ins from devices that are known to be infected with malware.
• Suspicious IPs – sign-ins from IP addresses that show a pattern of failed sign-in attempts for multiple accounts over a period of time.

The risk events that are triggered by the list of signals above are available in Azure AD reports. With Azure AD Identity Protection you can also create risk-based policies that will automatically respond to risk events. This requires Azure AD Premium P2 licensing. Risky sign-ins can be blocked entirely, or can trigger an MFA prompt or password reset for the user. Triggering MFA prompts requires that MFA already be rolled out to your users, so these risk-based policies are best used in conjunction with a proactive MFA deployment. This is another example of how you can allow non-MFA logins and only trigger MFA for risky sign-ins.

As you can see above, most of what Microsoft recommends instead of password expiration can be deployed for free. However, conditional access and the advanced capabilities of Azure AD Identity Protection require additional licensing. The cost is worth it, in my opinion, because even a minor breach of low level user accounts can escalate to a very expensive security incident very easily. But, for organizations who aren’t willing to invest in security, it will be a tough sell to move away from the password expiration policies that they probably believe have served them well until now.