8 characters or more, some special, throw some numbers in there, and rotate often.
Pretty much the standard advice for creating passwords for as long as computer systems have existed. I want to talk about why this logic isn’t important anymore, providing you’ve got other controls and training in place.
In Active Directory, the Default Domain Group Policy Object will have a password policy with the following settings:
- Enforce password history: 24
- Maximum password age: 42 Days
- Minimum password age: 1 day
- Minimum password length: 7
- Complexity requirements: Enabled
How many of you look at that now and wince a bit?
In Entra ID (formerly Azure Active Directory) the standards are:
- Enforce password history: 1
- Maximum password age: 90 Days
- Minimum password age: 0 days
- Minimum password length: 8
- Complexity requirements: Enabled
Slightly better, but still not what good looks like.
While this has been “best practice” for many years, too much of the focus today is still on how the actual password is comprised, rather than adopting multi-factor authentication and Self-Service Password Reset.
Many organisations out there today will have highly specific requirement: some might want 12 characters minimum, others encourage pass-phrases, and if you’re really unlucky, ridiculously short expiry times.
Passwords aren’t the important bit anymore
As Gabe Newell demonstrated with the introduction of Steam Guard over 10 years ago, it’s the MFA element that protects him.
Our industry has not yet caught up with this idea, hence the slurry of external regulators and insurers demanding standards that they haven’t questioned or revised recently.
What you should be doing
If Entra ID is your identity provider:
- Leave the default password creation policy as it is – Go configure a banned password list if you really want to
- Create a Conditional Access policy to enforce MFA for All Cloud Apps for All Users*
- Disable password expiry from the M365 Admin Portal
- Configure Self-Service Password Reset and target to ALL USERS
*There are legitimate exceptions to make in Conditional Access, but they are not to be made for end-users (Your C-Levels are just like everybody else).
…There are other CA policies I’d recommend, but that isn’t for this post.
Expanding on those suggestions
Conditional Access Policy
Pretty straight forward, although if you’ve never implemented this before, might be best to use “report-only” for a week or two.
Disabling password expiry
This option is over at https://admin.microsoft.com –> Org Settings –> Security & Privacy
Self-Service Password Reset
Assuming you’ve made the migration to Entra ID Authentication Methods, you’ll have a few options to choose from for users to use to reset their own passwords without calling the helpdesk:
- Microsoft Authenticator
- Third-party software OATH tokens
- Voice call
- Email OTP
(Eventually Security Questions will be available too, although some of those are pretty weak. I recently saw a custom one added which was: “What is your favourite colour?”)
I always recommend requiring two of the above methods for a password reset.
Once configured, users will be able to add methods for SSPR over at https://aka.ms/mfasetup
It’s all well and good being the snarky sysadmin creating these strong policies, but you also need to tell people about them. Number-matching MFA has done a lot to prevent mistakes of people approving prompts without thinking, however users need to be to informed about the new login experience.
For example, tell them:
- Don’t approve or proceed stuff you aren’t expecting
- Go to https://aka.ms/mfasetup and register some alternate methods
- Make use of the self-service options to you should the time come
A big mistake we often make as technical people is forgetting that the things we think are simple are just as obvious to everyone else in the company.