Password best practices controversy

Last year, Microsoft published this guidance on passwords, which contains some advice that departs from traditional best practices. For example:

• Eliminate character composition requirements (e.g. multiple character types @, 2, A, b)
• Eliminate mandatory periodic resets (do not enforce expiry)

The reasoning is based on Microsoft’s research, and the fact that they see billions of authentications per year. Research is showing that user behavior tends to get worse as more restrictions and rules for complexity are placed upon them. NSIT has also corroborated these findings.*

In other words, users will make poor decisions like re-using passwords, and they will tend to do other stupid things like “increment” their passwords simply by changing the last character (D@isyCh@in1, D@isyCh@in2, etc.), and use obvious substitutions like zero for the letter “O” and @ for the letter “A,” and so on. With the requirement for very long passwords, they just repeat a word twice or several times, or add 123456 to the end. Not so great.

So the reasoning goes: just don’t require users to be smart, because they aren’t going to be in the real world anyway. Instead, we are advised to take other counter-measures, such as banning common passwords & phrases, and requiring a second factor of authentication. There is a lot to be said for this, on both sides of the fence. (I personally still favor educating users, testing them, and issuing other continuous reminders to “slow down”–campaigns like this have been shown to dramatically reduce risk).

Where I take issue with this

The main problem that I see with this advice is that (especially smaller) organizations are going to jump all over it, and turn off their complexity/expiry requirements, but without implementing the necessary counter-protections, such as Multifactor Authentication or Credential Service Providers. Of course, these are key, inseparable points of the narrative that Microsoft and NSIT are promoting, but I really don’t think the full message is being heard yet. I have had several customers (and co-workers) suggest we remove expiry & complexity requirements ASAP. Sorry, not without a replacement strategy.

Second point: we live in a world where breach and compromised credentials is an everyday reality.  Credential dumps, even for major service providers, end up on the dark web at an increasingly alarming rate. Therefore, it seems prudent to me, that even if we remove composition requirements, we should still indeed require regular expiry of passwords.

Maybe that is controversial, but I don’t see another way around it. Is a second factor really enough? We know that round-tripping a code is not difficult to bypass either, right?

Thus, if at any given moment, you could have your password compromised, leaked, hacked, etc. (in fact it is very likely to happen at some point or even several in your working career), then it makes sense to require regular enforced changes, right?  So… how often should we change them?

Six characters can be brute-forced in a matter of hours, and as of today, eight characters still takes a few months (I know–math is weird). Therefore, I think at least semi-annually or quarterly requiring new passwords is a wise choice. Why? Because that way you remain inside the brute force time window, at a minimum. Granted, it is unlikely that brute force will be the vector of attack in most cases, but even so, doesn’t it seem like a reasonable minimum for frequency of change?

What do you think?

*Troy Hunt has a pretty good article on this topic, too.