Disallowing characters in a password?

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 charac开发者_JS百科ters, 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?

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.

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.

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.

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

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.

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.

I stumbled upon this question while doing some research and I thought I had to contribute.

Actually, I believe passwords should not accept any character. The problem may come with characters that are not part with the standard ASCII table.

Take, for example, the letter ü (lowercase u with umlaut):

• In the extended ASCII, that character is 0x81.
• In ISO-8859-1 (very common in Western countries) it's 0xFC.
• In UTF-8 ü has the codepoint U+00FC, and thus can be represented as 0xC3BC
• In UTF-8 the character may also be not normalized, though. So it could be composed of the umlaut character (just the ¨) plus the u: the result is another different sequence of bytes.

In all the cases above the hash for the password will be different, and the login will fail.

A possible solution to still allow any Unicode character is to ensure that the whole page uses UTF-8 everywhere, and normalize passwords (e.g. with NFC mode) before hashing them.
However, at this point it may be just easier to disallow any character that's not part of the standard ASCII table: bytes 0x00-0x7F or (even better, stripping control characters and others non representable plus newlines) 0x20-0x7E.