Ask HN: Is there a good reason for disallowing some characters from a password?
Let&#x27;s start at the edgest of cases.<p>Some emoji, for example, are combinations of multiple other emoji, and a given combined emoji may not be uniquely represented by a sequence of codepoints. In the pathological case, this could mean that an OS update on the user&#x27;s system changes the composition of the same emoji, which might make it impossible for them to input their password. It is probably prudent for a system to disallow emoji passwords.<p>One step away from Emoji, Unicode also allows for other m̸̱̜̅ͅȋ̴̩̠̀s̸̺͐c̶͈͇͉̐͛̚h̸̤̣̆i̴͍͍͒͌e̴̲̽̓f̸̞̽̊. Chances are, full-on Zalgo passwords can lead to problems. Again, there are probably prudent reasons to restrict some characters. On the other hand, those modifiers exist for a reason, and disallowing phrases in the user&#x27;s native language doesn&#x27;t make for great UX.<p>Towards the more common use of Unicode, there is a pretty good _practical_ reason to restrict the use of some non-ASCII characters: if your system accepts ç, ö and ø as characters in passwords, and non-technical users venture into a part of the world where the keyboard layout doesn&#x27;t, your helpdesk is going to have to deal with the occasional annoyed customer. From a systems design perspective, those characters seem fine -- operationally, they may cause headaches.<p>Finally, we&#x27;ve arrived at printable ASCII characters. Restrictions on maximum length (usually 6 or 8 characters), and on certain characters (%, &amp; or :) tend to be based on interactions with legacy systems (e.g. DES crypt() used to have an 8-character minimum), or on bad input handling. Either way, it&#x27;s probably a bad sign.