!!! Overview [{$pagename}] are a typical parameter of a [Password Policy] specifically the [Password Modification Policy] that deals with [Password Quality] [{$pagename}] are requirements are enforced by the [Password Validator]. [{$pagename}] 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 [{$pagename}] [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. !! [{$pagename}] 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|ISO 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: [{ReferringPagesPlugin before='*' after='\n' }] ---- * [#1] - [Passwords Evolved: Authentication Guidance for the Modern Era|https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/|target='_blank'] - based on information obtained 2017-07-26-