> There's no technical reason for restricting any character from appearing in any password. The usual approach for handling a password is:
> - encode with a specific, well-defined encoding (e.g. utf-8)
Heads up – this is not enough for reliable operation. The same character from an end-user’s perspective can be encoded in multiple ways in UTF-8. So they might register with one platform and then a while later log in with a different platform, and you might receive different string data for their password even though they typed the same thing in both cases.
You might want to consider following RFC 5198 which has more specific requirements, such as encoding to normalisation form C to eliminate issues like this:
Likewise the hex of a 128bit key is unbreakable but will fail almost every password policy becuse of repeated characters and lack of upper case/special characters.
Though for accentuated characters, I can think of some scenarios where it is not a good idea. Say your users may have to travel / use some terminals. If the keyboard doesn't have those characters, you locked them out of the system. That's why I think non ascii characters aren't a good idea. Also you make yourself more exposed to developers doing something silly like mixing string encoding between different interfaces.
That’s correct. It’s quite a detail in this case, though; this high level description tries to explain why you should never forbid some “special” chars.
Please note that it’s not the same char; it’s actually a different set of code points which happen to have the same representation.
> - encode with a specific, well-defined encoding (e.g. utf-8)
Heads up – this is not enough for reliable operation. The same character from an end-user’s perspective can be encoded in multiple ways in UTF-8. So they might register with one platform and then a while later log in with a different platform, and you might receive different string data for their password even though they typed the same thing in both cases.
You might want to consider following RFC 5198 which has more specific requirements, such as encoding to normalisation form C to eliminate issues like this:
https://www.rfc-editor.org/rfc/rfc5198