Password Policy

Require long passwords

It’s a good idea to set a Windows policy that requires a long password for domain accounts. There are two main reasons for this. The first is the math of cracking passwords given an NTLM password hash. In contrast to the recommended password hashing algorithms that we saw in Password Storage Done Right, (bcrypt, scrypt, Argon2, and PBKDF2), the NTLM password hashing algorithm does not have a work factor associated with it. This means that an attacker who gets access to an NTLM password hash will be able to attempt to brute force it with a huge number of attempts per second. The NTLM algorithm is not going away any time soon. So our only other defense against this attack is to use a longer password.

Another benefit from longer passwords relates to password storage from a long time ago. Before NTLM, Windows used a password hashing algorithm called LM. LM hashing hasn’t aged well and is quite susceptible to brute-forcing. Because of this, exposing an LM hash to an attacker (via Mimikatz, for example) should be considered equivalent to exposing a password to an attacker. The reason this affects us is that Windows servers can be configured to store both the NTLM password hash as well as the LM password hash for reasons of backward compatibility. Your domain should be configured to only use NTLM hashes, but you can buy some cheap insurance against getting that wrong. LM hashing only works on passwords that are 14 characters or shorter. So if you require passwords that are 15 characters or longer, you won’t be able to make the mistake of allowing LM hashes.

For more details on preventing usage of LM passwords, see Microsoft’s How to Prevent Windows from Storing a LAN Manager Hash of Your Password in Active Directory and Local SAM Databases.

One more, often overlooked, advantage of requiring a long domain password is that your users probably don’t use that password anywhere else. When large password breaches make the news, you have to worry about your users reusing passwords from that account at work. You can buy yourself some peace of mind by requiring a long password for your domain. It’s unlikely that any of your users will have chosen long passwords for themselves if they didn’t have to. If they were security conscious enough to choose a long password for their personal use, they’d likely be security conscious enough to not reuse passwords. So you’re unlikely to be impacted by external password leaks.

Putting all this together, we have a pretty good basis for choosing a minimum password policy of 15–20 characters. It’s worth noting that the minimum password length in Windows maxes out at 14. This is due to backward compatibility with the LM password-hashing algorithm. So if you want this to be enforced via technical means instead of just having it written down as company policy, you’ll need to have your users change passwords via another tool where you can enforce the longer password length. One such tool is Okta. Okta is a Single Sign-On solution for coordinating user access to online tools. Once installed, it can be used to handle user password resets and can enforce a minimum password requirement longer than 14 characters. Two more benefits of the pervasive use of Single Sign-On are that you can use it to require 2FA for all your internal web apps, and you’ll have a single place to disable access to all internal websites when someone leaves your organization.

Password rotation

The last piece of a password rotation policy is password rotation frequency. Both GCHQ and NIST have recently released guidance about passwords. The takeaway that you’re likely to hear about is that these two organizations no longer call for enforcing regularly scheduled user password rotation.

Other useful policies

What may get glossed over is that as a part of shifting the burden for effective password usage from users to site operators, they make additional suggestions, including the following:

• Enable a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account.
• Add support for all printable characters in passwords.
• Prevent users from using passwords known to be commonly used, expected, or compromised. Examples of such passwords include:
  • Passwords obtained from previous breach corpuses
  • Dictionary words
  • Repetitive or sequential characters (such as ‘aaaaaa’ and ‘1234abcd’)
  • Context-specific words, such as the name of the service, the username, and derivatives thereof
• Don’t provide password hints.
• Don’t allow for knowledge-based questions that come from publicly available data (ex: mother’s maiden name or name of a childhood friend) as part of handling a password reset.
• If 2FA is supported, provide at least one 2FA option that doesn’t use the public phone network.

And of course, passwords should be rotated if there is reason to believe they’ve been compromised.

If you require passwords of at least 15 characters for your Windows logins, you’re pretty well on your way to meeting these requirements. You don’t have explicit support for preventing the weak passwords that NIST describes, but the password length is a decent approximation. Add in a subscription to a compromised password service like Have I Been Pwned, and you’ll be in pretty good shape for not requiring regularly scheduled user password rotation.

                                                 Q U I Z