It's a good thing I put on my "Be Disruptive" shirt this morning, because I'm about to disrupt all up in this place. You're sitting down, right? Excellent.
According to recent documentation, Microsoft's current best-practices guidance for passwords is to…set them to never expire. It's ok if you need to take a moment to re-read that. Once you've made peace with that one, you can also disable complexity requirements.
We've been talking for some time about the limitations of passwords and the importance of enabling multi-factor authentication, but this is the first time we've seen the drumline change from "passwords aren't enough" to "seriously, just don't bother even changing them any more", and that's a HUGE posture shift.
So what's driving it?
Again, we know passwords tend to be hard to remember and end up jotted on sticky notes under keyboards (or stuck to monitors). We know users recycle the heck out of them, too, with statistics saying a full 73% of credentials are recycled across systems. And we know users love cat names, their children, and the tried and true "password1".
Microsoft warned us some time ago that winning team names make up a huge percentage of passwords, and introduced some really cool password filtering capabilities to prohibit that. Windows 2016 AD will very soon be able to actually subscribe to those filters, and admins will be able to introduce their own banned words, so users don't just put famous employees or corporate initiatives as passwords. That's cool, and would somewhat imply that passwords still have a very high value. But what Microsoft has also discovered is that having users change passwords more frequently actually drives up the likelihood that they'll fall into these bad password habits. And it makes total sense, if you think about it: being forced to think up a new password every 60 to 90 days is an out-of-band exercise for most of us. It's usually interruptive to our process, so it doesn't get the attention it might deserve. Our brains tend to go to something that's on our minds, we turn it into 1337 sp34k, and move on.
But no more.
Those great filtering tools now block simple 1337 sp34k conversions, which ultimately means users will get even more frustrated trying to come up with something quick.
All of which is just to say that passwords aren't getting the job done, and you can stop worrying about them. So sayeth Microsoft (so don't blame me). But we can't just wholesale dump the principal security mechanism that protects the object that we've declared "the new control plane" of IT security: the user identity.
Back to multi-factor….
If you haven't enabled it yet, what's holding you back? Office 365 and Azure admins can use it for free. In fact, let me quote Alex Simons, who in that same document updated the Azure AD best practices guidance this week with the following gem:
We strongly recommend enabling always-on multi-factor authentication for all admins in your organization, especially subscription owners and tenant admins. Seriously, go do this right now.
The best part about that guidance is that it can be done for free, right now. Admins get MFA for free in all subscriptions of Office 365 and Azure. There is literally no justification to not enable it.
But if you're swinging the password hammer, you can't just enable admins and call it good. Users need the same level of account protections, and multi-factor authentication is a much more powerful protection than passwords will ever be. So let's handle some objections…
-
My users won't like it. You won't like it when their credentials get compromised. For all the security mechanisms we can deploy, honestly MFA is one of the easiest for users. Consider what they're doing right now: changing a password every 60 - 90 days to something that's ultimately not that hard to guess. With MFA, they're going to get challenged to either input a code or check a notification on their phones. And since we can cache that challenge for up to 60 days, there's not ultimately a big difference in the experience, except now we don't need them to disrupt their business processes to think up a cute phrase like T@x3s_R_th3_w0rs+!
-
I don't have time to support it. I've heard this one a lot, and even helped write a 33-page deployment guide with step-by-step guidance to get users up & running. We sent out that giant document to a global user-base for a customer, and predictably, the users were not impressed with a gigantic "how-to" guide. The good news is that enrolling is a very simple and guided process, so most users didn't even need to reference the document. And once they're running, they're set. There's very little to support. There are few IT deployments as easy to get right.
-
How do I know a malicious 3rd party won't intercept the auth requests? This is a time-of-setup concern I've heard way too many times over the years. Admins have the ability (though I've rarely seen it used) to pre-populate a user's authentication phone number. Realistically the user only sees a request for that phone number 1 time, and that is when MFA is first enabled. So an attacker would need to know the exact moment a user was enabled and beat that user to the login prompt. It's a minimal opportunity, but again: one that can be mitigated. And the administrator can always clear saved authentication information like the recovery email address & authentication phone, so if illicit activity is suspected, we can take immediate corrective actions.
-
Ugh: another app?? Yes and no. There are a number of native mechanisms to support the secondary authentication method. You can use the app with active notifications, the app with rolling codes (similar to RSA or Google's Authenticator app), text messages, or phone calls. While the app provides the best experience and is probably the easiest to configure & support, it also has the handy-dandy ability to consolidate secondary authentication functions for Google and Amazon MFA capabilities. So not necessarily an additional app, if numbers are your thing. I've also heard this objection in the form of "I'm not running any company apps on my personal device", and that's typically when you're going to use text messages or phone calls.
Now there has traditionally been one challenge to getting MFA deployed, and it's one of reporting. Azure AD gives great insights into just about every element of a user account, but oddly does not do a great job reporting who is and isn't MFA-enabled. You can look them up one-at-a-time in the portal, but there's no export functionality. Even PowerShell doesn't provide direct visibility, and some of the scripted solutions I've seen on the Internet make bold assumptions about fields that will or won't be populated. So please steal the following code, run an Azure Active Directory PowerShell, and see who in your environment is licensed, enabled for login, and NOT MFA-enabled.
If you're not using Azure Active Directory at the P2 license level, just run that guy once per day and call every user that pops up on the list until you whittle it down to zero. If you are running AAD P2, though, you can turn on risk-based sign-in policies that will automatically configure your users for MFA.
Once you have your users configured, they can leverage that security against on-premises authentications via the Azure MFA server and/or ADFS, VPN authentications with Network Policy Server configurations, Office 365 & Azure services, and SSO-enabled SaaS applications that have been integrated with your Azure AD.
There are very few tools in the security toolbox that can have such a wide-reaching and profound impact to the overall security posture as MFA. What's stopping your deployment?
https://cloudblogs.microsoft.com/enterprisemobility/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf
Comments