Overview#

Password Character Composition are a typical parameter of a Password Policy specifically the Password Modification Policy that deals with Password Quality

Password Character Composition are requirements are enforced by the Password Validator.

Password Character Composition is typically enabled within a Password Policy with various restrictions on the composition of the password in an attempt to increase Password Entropy

This is an Example ALL TOO Common Password Character Composition Example:

• Passwords MUST NOT contain the user's entire samAccountName (Account Name) value or entire displayName (Full Name) value. Both checks are not case-sensitive:
  • The samAccountName is checked in its entirety only to determine whether it is part of the password. If the samAccountName is less than three characters long, this check is skipped.
  • The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs.
• Passwords MUST contain characters from three of the following five categories:
  • Uppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
  • Lowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
  • Base 10 digits (0 through 9)
  • Non Alphanumeric characters: !@#$%^&*_-+=`|\(){}:;"'<>,.?/
  • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

Password Character Composition Restrictions from the Experts[1]#

National Institute of Standards and Technology (NIST) is pretty clear on this - don't do it:

All printing ASCII RFC 20 characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode ISO/ISC 10646 characters SHOULD be accepted as well.

It's also worth noting their point on Unicode characters; there are many precedents of sites restricting perfectly valid language characters simply because they don't fit into what a site's developers consider "normal". Then, of course, there are passwords like this:
The ❄️ 🌟 🔦 ⚪ on the mountain 🌙 🌠. 🙅🏻 a👣 to 🐝 👀. A 🏰 of 😢, and it 👀 like☝️️ the 👑. The 💨 is 🐺 like this 🌀 ❄️ ☔️ 🏠. 🙅🏻 keep it in, ☁️ 💡 ☝️️ tried.

If someone really wants to have a password that's an emoji representation of the first verse of "Let It Go" from Frozen, good on 'em!

The other aspect of special characters is this from NIST:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets

Wait - what?! You mean people aren't required to have lowercase, uppercase, numbers and symbols?! This goes against so much of conventional password wisdom and it's not until you step back and think about it logically that it really makes sense.

Microsoft has precisely the same guidance as NIST in their documentation: "Eliminate character-composition requirements"

More Information#

There might be more information for this subject on one of the following:

• NIST.SP.800-63B
• Password Anti-Pattern
• Password Quality
• Password Validator

---

• [#1] - Passwords Evolved: Authentication Guidance for the Modern Era - based on information obtained 2017-07-26-