What characters would you make invalid for a password?

Question

A hypothetical situation: you've implemented a password handling system, and it doesn't impose any limitations at all on what characters can be used. You want to set up some rules that are a reasonable compromise between two things -

1. Allow the user as much freedom as possible.
2. Allow for the possibility that you may change how you handle passwords in the future - you don't want to rule out reasonable implementations because your users' existing passwords would become invalid.

What rules would you impose? Are there other factors that might affect you choice?

Answer 1

I'd keep anything you can make with one key (and optionally shift) on your keyboard, except tab. What kind of schemes would necessitate a more restrictive option?

Answer 2

Do not impose no restrictions whatsoever, ever. And it seems to me that you're planning on storing password, not hash. Do not do that either. Rather, store salt and hashed combination of password and said salt.

However, you can require your users to have a reasonably strong password by imposing restriction on length (say, not less than 6 characters) and on characters which comprise the password (say, it should contain lower- and uppercase alphabetic characters, one or two digits and several non-alphabetic characters such as ^ or #).

Answer 3

Have the users type passwords that contain at least a number and a non-alphanumeric character, and be more than six characters long. Anyway, I think that whatever the limitations, in the event that you change the way you validate passwords, you should notify users in reasonable time to update theirs.

Answer 4

Any non-control character should be fine. I should think that the developers of super-duper password systems in the future would allow "unusual" ASCII characters like punctuation and other marks, but control characters have a habit of being unwieldy to enter in text mode shells and even GUI dialogs that expect Tab and Enter/Return to be free for their own purposes.

Answer 5

A blank space (based on the logic it may be trimmed accidentally before being hashed)

Answer 6

The rules I would suggest enforcing:

1. Length - no less than 8 characters - but no more than 20
2. Ease of breaking - the pass should not contain the user's first name, last name or user name, nor (if possible to check) any word that appears in the English dictionary.
3. Content - There are 4 types of characters on the keyboard: uppercase, lowercase, numbers and punctuation marks. A good password should include representatives from at least 3 groups, and no more that 2-3 characters of the same group in a row.

Answer 7

Best is no restrictions whatsoever, unless you can really justify them.

If you are a bank, email provider, or if the user can order something without supplying a credit card, then forcing users to use a strong password makes sense. Otherwise, you're just making it hard for no reason.

As to what you should store, I'd say 1024 characters of unicode with control characters prohibited is about all that's justified. If the user can't type it, they should have picked a different password. All you're storing is a hash, so you can always cut it down to whatever size you want.

Answer 8

No limit on the password. If they can type it from their keyboard, regardless of what regional keyboard they use. You may want to impose a minimum length, options like at least one number and one special character, but no max limit.

Regarding your second question. The way I would implement it is via making seperate fields as you improve password strength. For example, right now you would have two fields that relate to the password: salt, password_md5. Lets say later on you want to use sha256. Create a new field called password_sha256. When the user logs in you first check password_sha256. If that field is empty then check password_md5. If that matches you now have the plain text password the user entered. You can then generate the sha256 password (I'd also reset the salt for good measure) and store the new value. I would then blank out the value in password_md5 so no one could reverse that to get the password.

Personally I'd just go with the best hash your language can do and use that. The important things are enforcing a good minimum password policy--it doesn't matter how secure the hash is when the password is "1234"--and to seed the hash with some random character to avoid dictionary attacks.

Answer 9

In our organization, if the user is supplying the password we allow them to use anything they want.

When users are first enrolled in the system a password is generated for them. Since this password is usually mailed to them, we avoid using certain characters that could be confused particularly when using certain fonts. For example, the letter O and the number 0 (zero) are not used. The same for L, I and 1 (one), S and 5, Z and 2 and others.

Before we made this change we had a lot of calls to our help desk because the characters we confusing and they couldn't log in.