In thesis ...
If your encryption algorithm accepts them, any printable data should be able to be part of a password, the rest is service policy.
Defining a service policy
You need to define a service policy to avoid strange behavior such as:
- Password trimming
- accept control characters as Ctrl + Backspace on Windows. Some are printable like the one I cited
- Automatic behaviors caused by spell checkers or virtual keyboards such as smartphones .
Passwords: hard to break is different from being difficult to remember
To help you set your policy, read this article from Jeff Atwood, co-founder of Stack Overflow, "Password Rules Are Bullshit" . It cites the most common problems of the rules that most sites adopt and how to circumvent them.
Intermsofinformationsecurity,somesaythatspacehasadistinguishablesoundonthekeyboard, (extra!) , so it should not be accepted or anything like that. If the attacker can hear the sound of the keyboard, it is much easier to break the password if he knows that it follows the pattern
X: qualquer outro caracetere
Okay, I do not want to accept spaces in passwords. And now?
You can display a validation message saying you do not accept spaces or trim spaces (strategy that Google uses).
I understand that not using spaces can decrease the sample field of password possibilities, but allowing them can cause the user to enter a space unintentionally. That's it! Unintentionally. The mobile web experience is good but not perfect yet.
Particularly, and defended by UX, I do not like the idea of trimming. Alert the user and ask for the correction.
Also do not include 1,000 different rules for creating a password, this can impair usability. Large applications use 3 constraints at most.
As a force meter, one of the parameters can be how much effort a computer would take to break such a password (!)