Modernize your approach to passwords with the Azure AD identity platform

Alexander Filipin
AlexFilipin
Published in
4 min readNov 2, 2020
Picture of a password

Yes, we don’t like passwords, but let’s take a practical look at what we can do to make it easier for our users while increasing security.

When I talk to my customers about passwords, I use the following checklist to optimize their approach to passwords.

  • Involve your users
  • Use strong authentication
  • Start banning commonly attacked passwords
  • Turn off traditional complexity, and expiration rules
  • Protect against leaked credentials
  • Implement self-service password reset

Involve your users

When you change your approach to password, your users must be involved. You can use the following section as input to draft your user communication.

  • Your password no longer expires — an NO you shouldn’t switch from 3 months expiration to annually because you want to establish a notion of: “If we ask you to change your password in the future, it is only because we are convinced that your password has been compromised.” You want to avoid that attackers can predict the users next password (research), because they might choose one very similar to their previous password, therefore your users need to be aware WHY you ask them to change their password. However, it makes sense to have a last periodic password change after you installed a block list like Azure AD Password Protection to increase the quality of existing passwords. Because Azure AD Identity Protection Leaked Credentials will only detect username/password PAIRS not in general weak passwords.
  • An example how to build good passwords: Advocate and establish a culture of passphrases opposed to passwords — “…a longer phrase like “I often like working Mondays” will generally be more secure than shorter combinations of characters that are hard to remember, such as “$Le90pch”.” — Stephan Wiefling
  • Which requirements must a password meet in the future: Common passwords are blocked, minimum length of 12 characters, a decent password history, one change per day BUT no complexity nor expiration — There are valid points to require 15 characters or even longer passwords if you have to consider brute force attacks against portals without lockout protections and password cracking as attack vector. Ultimately, it is a risk assessment for your specific environment, a cloud-only environment, with lockout policies and other brute force and password spray protections on all portals, has a lower risk with a minimum length of 12 than a legacy on-prem / hybrid environment, in which, in the worst case, it is not even clear how many login pages there are. Resources: NIST see SP 800–63B Memorized Secret Verifiers, BSI see “ORP.4.A8 Regelung des Passwortgebrauchs”, Microsoft and latest research for the 12 characters minimum
  • Highlight that this change can make users’ life easier, the above points (No expiration, No complexity, Use of phase phrases) are pleasant for users
  • Please choose a password which you use exclusively for work related purposes (no re-use for non-work related purposes)
  • Advertise Passwordless alternatives — more details in the “Use strong authentication” section of this article
  • What if you have forgotten your password? — Advertise self-service password reset option, more details in the “Implement self-service password reset” section of this article

Now let’s have a look at the Azure AD features for technical implementation, I will not go into detail here but rather link to the official documentation of the features to reach the respective checklist item. Many of my customers are confused without the following overview which feature has to be activated to reach the respective checklist item.

Use strong authentication

Azure AD pieces involved:

You should have a good Conditional access concept which will require you to look into the following topics for strong authentication:

Start banning commonly attacked passwords

Pieces involved: Azure AD Password Protection (Cloud, On-prem)

  • Yes it works on your on-prem DCs by installing agents on them
  • No you don't have to sync your password hashes for it (but you should for other reasons)
  • No you don’t have to enable password write back for it (but you should for other reasons)
  • No you don’t have to sync users between on-prem AD and Azure AD for it (but you should for other reasons)
  • Licensing information

Turn off traditional complexity, and expiration rules

Pieces involved:

Protect against leaked credentials

Pieces involved:

Implement self-service password reset

Pieces involved:

--

--