If the user can type it then it should be allowed in their password.
Telling someone what they can and can't use in their password always feels wrong to the user. Passwords are currently the most universal way to authenticate. Preventing users from entering anything is, in essence, telling them who they can or can't be.
1. Any printable character that a user inputs should be allowed.
The following characters are okay...
'A', 'a', 'á', 'Æ', 'æ', 'Ñ', 'ñ', '-', '_', ' ' (space), '\t' (tab), '\n' (newline), ...
Just because I don't know how to submit a TAB or ENTER character as part of my password doesn't give me the right to prevent others from doing so.
(Don't worry, few people will try to submit an ENTER character as part of their password but allowing the few that do will earn their respect.)
2. Keys that don't display a printable character should not be allowed.
The reasons for this should be obvious but for completeness I will mention the following keys which can be detected but are reserved for other actions. For example, a password input shouldn't record that the shift was hit multiple times...
[ctrl], [alt], [shift], [arrow keys], [apple key], [windows key], etc.
3. Not allowing certain characters makes users question your security.
When you prevent users from putting certain characters in their password it not only annoys people but causes many of them to question what else you are doing that isn't secure.
You may as well be saying...
"Hey we don't want to fix our application to properly deal with special characters so would you mind helping us out by making your password less secure?"
The rules below will allow for secure input while preventing a user from ever getting stuck:
Don't show the characters that the user is typing in password fields (there are some exceptions on mobile)
Having the user type in their password twice is usually sufficient in letting them know that they got it right (i.e. didn't accidentally add unintended white space etc.)
Having a password reset mechanism is important to handle any cases of accidental lockout.
4. Encouraging a user to add more isn't the same as prohibiting characters.
One way to help a user come up with a secure password is to make a game out of it...
5. The future of authentication
"The Tech That Will Kill Passwords Dead" is a pretty good gizmodo article discussing the problems we all face with passwords. It also talks about some new patterns that could possibly replace passwords one day.
Many mobile applications are starting to allow users to show or hide passwords in plain text in order to increase ease of use and remove one barrier to entry. I would still avoid this because the problem it creates is worse than the problem it solves.
Even with a very intuitive mechanism for showing/hiding a password 60% of users still say it feels wrong to see passwords in clear text.
According to that same article it appears that Touch ID is on the right track and easily wins as far as usability is concerned. Touch ID still has some major problems that make it impractical. The biggest being that it only works on select devices and has issues with one person controlling multiple accounts.
Facial recognition is another contender as an increasing number of high pixel density cameras make their way into the world but this approach often leaves people worrying about privacy.
The one problem shared by all of these new authentication attempts is this: You are the password.
It's actually a lot easier to fake who you are than what you know. In addition, once you've been compromised it's nearly impossible to change (your fingerprints for example)
Passwords are the authentication mechanism of choice for a good long while so...
Please don't place arbitrary character limitations on my password. Thanks!