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.
I realise it’s an impost impossible task to keep everything updated. But I wondered if you wanted to maybe update or include a note to show that the password length was increased to 256. I was actually surprised it was limited to be honest and something I had not considered.
How about instead of recommending non-expiring passwords, maybe Office 365 should provide a way to send password expiration reminders via email or text to users, which would eliminate 95% of the issues that that I run into with expiring passwords. Right now they don’t work well, because their is not reminders and users constantly get locked out, not knowing their passwords have expired. Just stupid.
Pingback: Multi-factor Authentication by Default for Administrators in Azure AD and Office 365 – SimpleITPro
Interesting that the topic of password managers was never mentioned.
Or is this a “legacy” concept too? A password that doesn’t change is compromised security. Organizations commonly use online resources that are accessed by multiple members of their staff, where MFA wouldn’t really work, and no good way to track who has access to what.
A business-run password manager system for its staff allows for truly strong passwords, rotation, and lack of frustration. It teaches and reinforces use of password managers in their employees’ personal lives.
The NIST recommendations that made so much news were based on people NOT using password managers. With so many online services that we use nowadays, it’d be impossible to use unique strong passwords on every service you use without one, so why are we not driving users towards them?
Ah, finally a first step in the right direction. Now they have to get rid of the 16 character password limit and the requirement for mixed case passwords with numbers and we finally are up to modern standards.
As of April 2019, maximum password length now seems to support up to 256 characters.
I was surprised to see some of the new NIST recommendations around passwords. A summary can be found here: https://auth0.com/blog/dont-pass-on-the-new-nist-password-guidelines/ the full NIST publication can be found here: https://pages.nist.gov/800-63-3/sp800-63-3.html – Along with Microsoft, it is a bit of a deviation from the “old school of thought” around passwords and password policy management.