Azure AD Password Protection is now generally available!

Hi Alex Simons (AZURE), congrats on this going GA!

Two questions: 

1. Will we ever be able to play with the weak password cutoff and set a value higher than 5 points?

I would really like to set something higher and align with the on-prem password length policy. I can't wait to turn off password complexity, but I don't feel comfortable doing that unless I can also make AAD Password Protection a bit stricter on password strength.

I think the latest guidance (at least from NIST) is telling us to focus on length and ignore complexity, but the third leg of the stool NIST talks about is checking against a banned password list.

2. Will we be able to get more color on the global banned password list?

What it seems a lot of other people do is pull in the HIBP list (like on Github!), which we know has hundreds of millions of password hashes to check against. Clearly you're doing something quite different for the global banned password list, because instead of dropping 10GB of hashes on my SYSVOL share, I only see 100KB of data in the PasswordPolicies folder.

It would be really helpful if we can get some color on what's happening under the hood. I understand you can't share any content of the lists, and clearly the normalizing technique dramatically reduces the data you need to look at vs password hashes which need to have every possible variation.

But basically, can you tell us a bit more than this? (from https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#global-banned-password-list)

• Therefore the Azure AD Identity Protection team continually look for commonly used and compromised passwords. They then block those passwords that are deemed too common in what is called the global banned password list. 

Thanks again! We have been waiting for this to go GA for a while...

Hey Carlos,

Great Questions!

Let me start by saying - this feature is really all about preventing password guessing. Attacks like phishing, keystroke logging, and third party breach are really password independent, and database breaking (e.g. getting an offline copy of the data for brute forcing) is a completely different sort of threat. So focusing now on password guessing - most of this is done today via low-and-slow attacks across multiple customers and tens of thousands of accounts, but using only a few passwords (we typically detect and shut down the attack very quickly, and rate limiting and lockout technologies provide further friction to attackers).

So: we are trying to keep your users from having passwords that can be guessed.

1. [Can you change # of points required] We have looked at it, but our focus right now is ensuring that the algorithm we use defeats *all* guessing attacks as described above. We have been working with the red teams of some great preview customers to help us get this right. Rather than asking you to tweak the algo, we want to just do it right. If the current thresholds aren't doing the trick, we'd rather make it stronger for *everyone* (without adding friction just for "security theater"). We’ve updated the global banned password list and the banned password algorithm many times during the course of public preview. These changes will help expand the set of passwords being blocked. But if you are finding that there are patterns/guesses that the current algo isn't blocking, we would LOVE for you to reach out to us here or DM our GPM Alex Weinert on Twitter (@alex_t_weinert) , so that we can tune it further.

2. [How does it work?] In a nutshell, what we are doing is analyzing our current attackers' patterns and maintaining a shorter (~2000 word) base banned word list. From there, we normalize for case and common substitutions (so "P@$$w0rD" becomes "password") and ban all of those permutations. Any matches here are collapsed for point value, so while you can use a string like password or 123 in a password, there has to be enough entropy around it to make it a valid password, e.g. "123asd*%spasswordV$" would be allowed. The algorithm is fully outlined here. We don’t need to have every single weak password combination in the global list because the algorithm will take care of that for us. Additionally, blocking all passwords previously seen for any user is problematic – users will get frustrated coming up with a password no-one else has every thought of.

Broadly, I think that excessively strict rules do harm, not good - you are forcing people to rely on cut and paste, killing usability, etc. What we really need is client device bound credentials which use PKI to transmit non-replayable, cryptographically strong nonces for login and break the back of all of these password vulnerabilities (FIDO2!) - in the meantime, we want to prevent password guessing without generating unnecessary user friction. Check out https://aka.ms/passwordguidance for the studies that back this.

Thanks,

Rohini

Any suggestion for us. We're a school district. We have two distinct users. Staff and Students. Staff need strong passwords (and MFA). Students need simpler passwords without MFA. Any suggestions or possibility to have this feature offer differentiated support for our different user groups. Simplest would be to exclude students from Password Protection - but I can't. It's all or nothing. Next best might be to set a different 'score' for the user groups.

thanks

Steven Bink that is correct.  The global banned list is always in effect for all supported scenarios.

Hi MaherRiahi,

If you are running the AADPP proxy server behind a firewall, please make sure the appropriate ports and names are opened up.  Also, please make sure TLS 1.2 is supported between the AADPP proxy server and the outside network - that is another cause of this issue.

Jay

This is a fantastic solution and will really help customers to enforce stronger passwords, until the day we can completely remove passwords ;)

Why keep wasting time on tackling a symptom or the problem, when the actual problem is the existence of passwords in the first place...get rid of them. I should not have to remember any passwords. I want to go password-less.

The amount of total time wasted by everyone writing down username/password site combinations in a password manager, excel file, or whatever is getting pretty ridiculous and the fact that we are still doing this and losing billions to this type of fraud in 2019 baffles me.

MS/Google/Apple and the rest need to start an industry push to support FIDO U2F with hardware wallets (i.e. a Ledger or equivalent) and blockchain. I should be able to have something on my keyring and be able to login to any computer or website without ever needing to remember my password. I should be able to use a single token for ALL my logins. I'm pretty sure you can have fingerprint/PIN on top and just invalidate the token if it is ever lost or stolen (and keep the seed restore password somewhere safe like a safe).

I think there's a Windows 10 login app that technically allows you to login password-less but it's only in beta. But we need all the large IT companies to support password-less FIDO U2F as an OPTION so at least it's there for the security conscious that want to use it. Banks are ironically the worst at this, most only send OTP via SMS...

Hi Alex

It stated that "Preview customers MUST update the agents to the latest version (1.2.116.0 or higher) immediately."

According to the installation guide, then the domain controllers must be rebooted when the agent is installed. But will the GA build autodetect the old client and update it or do we need to uninstall, reboot, install and reboot before we are able to use the GA version?

Hi bjarneabraham,

The DC agent installer has supported in-place upgrade for quite awhile.   If you already have an earlier version installed, just run the GA DC agent installer over the top of the older one - it will still require one reboot, but not two.

Jay

JaySimmons Thanks for the reply, I just noticed that in the document and changed my comment, but you were quicker lol.