Disallowing characters in a password?

Question

Is there something special about characters that should be allowed/not allowed in a password?

I store the password in the db hashed/salted and use PDO to prevent against injection. Is what I'm doing enough? Recently I came across a system that disallowed a number of characters, don't remember all of them, but one was the ampersand &. Were they doing it for anti-database injection reasons, or is there something else I'm missing? Should password characters be restricted to a certain set of characters or no need?

Answer 1

Why would you want to limit characters in a password? You should be doing some sort of hashing anyways. My passwords frequently contain special symbols including ones that aren't included on the keyboard.

If you want limitations, they should only require them to be more complex, not less.

Answer 2

There is no technical reason to disallow any characters in a password. I guess in the case you describe, they would allow only alpha-numeric characters to avoid problems on the user's side (say, by entering a character that isn't available on keyboards in another country).

Many providers and sites force users to choose very complex passwords containing a minimum number numbers and, sometimes, evenb special characters to prevent brute-forcing or dictionary attacks.

I don't think forcing people to choose a complex password is wise. Passwords you can't remember, you will write down somewhere, which is often creating a much bigger security risk in real life.

A simple rate limit in the login system (e.g. deny access for 15 minutes after 3 failed login attempts) takes the edge off the brute-forcing threat much more elegantly.

One doesn't have to agree 100% with it, but I found this provocative paper on the subject from Microsoft Research very interesting. So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users

From the abstract:

It is often suggested that users are hopelessly lazy and unmotivated on security questions. They choose weak passwords, ignore security warnings, and are oblivious to certificates errors. We argue that users' rejection of the security advice they receive is entirely rational from an economic perspective. The advice offers to shield them from the direct costs of attacks, but burdens them with far greater indirect costs in the form of effort.

Answer 3

The only thing I disallow / strip in passwords is whitespace, there is no reason to forbit anything else.

Answer 4

When I enter passwords, I normally like to write longer sentences that i can remember instead of p"%&/k1 or the like.

So make sure you allow your users to write passwords longer than 10signs. It always frustrates me, when I am forced to enter a short password with special characters instead of a longer one that would be more memorable and safer.

Answer 5

I only disallow characters that can't be typed on a standard keyboard. There's no reason why a user can't choose a secure password with 26 uppercase and lowercase letters, 10 numbers, and 20 something symbols.

If you're doing a login system for a public site, instead of forcing users to choose a secure password, I would recommend using OpenID. That way, the user doesn't need to remember a new hard-to-remember password just for your site.

Answer 6

Don't mess with the user's password.

Just make sure that you are using a consistent encoding and rules in all stages of your password handling. In your case encoding shouldn't be a problem as you are storing salts.

As examples, I've come with stupid rules like passwords being limited to 4 digits (!!!), only alphabetic characters (a-z), and some academic website silently truncating passwords to 10 chars on registration and then failing when you tried to login with the long password.