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?

Venetian

Answer 1

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.

Osprey

I use keepass which has an option for using "high ANSI characters like the following: iôhQná"«-óÓSGÉH©®EqjË=«ÒquW6>\Jò-§. – Schumer

I don't know of RCIX's comment is intended to contradict what Kevin says, but those aren't control characters and would not be prohibited by the suggested rules. They just aren't 7-bit ASCII. – Armed

Not the answer I was expecting, but apparently it's the most reasonable one. A lot of systems out there do impose restrictions, and I assumed they had a good reason. If so, nobody here seems to know what they are, so I'll change my assumption! Some other answers here are more about restrictions that should be imposed, rather than characters that should be allowed. – Venetian

"If the user can't type it, they should have picked a different password." Well, unusual characters not being transmitted correctly isn't always the user's fault... although admittedly unicode is rather well supported. – Icbm

Nowadays, insisting on strong passwords may make sense for a broader range of sites. Users on low-stakes sites like Tumblr are routinely having their accounts hacked by brute-force password-guessing attacks, and then the attackers post spam. Also any site where users can publish data (such as in a profile) especially with links, risks harming the webmaster and/or other users, such as by spam, malware, or phishing links, so it's not just the hacked user who gets harmed. Also, many users use password managers and with these, being able to type the password easily is unnecessary. – Noles

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 #).

Malamute

Whatever you do though, PLEASE don't restrict max char length; i generate huge passwords via Keepass and it annoys me when i have to downgrade the generation algorithm i use for that. – Schumer

I'm not sure why this answer keeps getting voted up - it doesn't answer the question! The question was not "What restrictions would you impose?" it was "What characters would you make invalid". The answers that suggest few or no restrictions seem like more reasonable answers to that. (And, no, I would not store passwords as plain text). – Venetian

@issy: The very first sentence answers your question perfectly fine. An the fact that you're not going to store passwords as plain text is not immediately obvious since you're asking about some obscure "password handling schema changes". What can possibly go wrong when all you're storing is password hash? – Malamute

@Schumer restricting password length is perfecly fine, as long as the limit is not set too low. It's actually recommended by OWASP to limit passwords to 128 characters to prevent denial of service attacks (hashing a very long password can be CPU-intensive). – Detachment

Answer 3

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.

Meldameldoh

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.

Torr

Answer 5

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

Enabling

Answer 6

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 were confusing and they couldn't log in.

Radferd

Answer 7

Personally I have always been keen on not enforcing too many rules.

This has just changed. I have just found my website is vulnerable to XSS attacks. The solution is to sanitise every piece of input that comes from the user, including the password.

For 10 years we have had no limits on the password. Now we are implementing a limit to the characters that can be used, and this is simply to block hackers from being able to access Javascript or SQL. So we constructed the following list:

Valid characters for a password are: a-z A-Z 0-9 . - _ $ * ( ) # @ ! % / (blank)

This allows lots of flexibility but avoids characters that might be used in coding an XSS hack, such as ; < > \ { } [ ] + = ? & , : ' " `

HTH

Filippo

Forbidding characters in user input is both overkill and insufficient. Sometimes XSS attacks do not require any special character (imagine a website generating href from user input and not enclosing the URL in quotes), and sometimes you absolutely need to allow HTML entities (imagine stackoverflow denying these in messages). You just need to sanitize input when it's needed (if it's HTML), or encode it properly on rendering (if it's not HTML). Finally, passwords are usually not a vector of XSS attacks, because you're not supposed to render them (you shouldn't even store them). – Detachment

You are absolutely correct Maxime, however no code is ever perfect, and who knows when somebody less skilled will be updating our code. We clean all of our incoming form data - yes, every piece. I have a large set of REGEXP strings for validating numbers, id values, dates, times, usernames, text strings, longer variable strings, and I also have one for passwords. If I'm cleaning everything else, why wouldn't I clean my passwords also. I also use an ORM that automatically sanitisers all of the values inserted into my SQL queries, but I still clean everything prior. – Filippo

Anyways, this is becoming less important for us as many of our customers are implementing SSO authentication, so somebody else is looking after the passwords. – Filippo

Forbidding characters, "sanitizing", or "escaping" strings is both ineffective and unnecessary for preventing SQL injection attacks. Always use prepared statements for unsafe inputs. Then you'll be fully protected against these attacks and you won't restrict users at all. And @MaximeRossini gave equivalent advice for XSS. – Noles

Answer 8

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?

Aetolia

People who use a different keyboard from me would necessitate a less restrictive option. What's special about the keyboard I happen to have in front of me when I'm writing the code? Some people can get a euro-symbol or an e-acute in one keypress+shift, others can't. – Armed

Answer 9

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.

Epanodos

Answer 10

My policy dictates:

[^A-Za-z0-9-]

May sound harsh but the truth is:

“[R]equiring that type of comically frustrating password complexity is now known to be a terrible idea, and has actually contributed to the problems we have now with cyber breaches. Here’s what Bill Burr, the guy from NIST who wrote the old guide to password standards now says: ‘Much of what I did I now regret. In the end, [the list of guidelines] was probably too complicated for a lot of folks to understand very well, and the truth is, it was barking up the wrong tree.’”

Length and uniqueness are much more important that the presence of funny characters, moreover, note that passwords are usually stolen from the user (phished, logged, tapped), not guessed. “At least 6 characters and not any of the comically common passwords like qwerty, sesame or password” suffices for all usages I’m in care of (non-financial of course).

Hemoglobin

Answer 11

Personally, I use DigitalPersona's Fingerprint Keyboard (yes, Microsoft does [or did] make a similar device, both integrated with or separate from the keyboard).

This allows the generation of extremely long and complicated passwords that don't have to be written down (as the press of your finger on the reader supplies the password to the Logon dialog [system/application/website]).

This, in my opinion, provides the best of both worlds: Extremely difficult to "guess" passwords, without having to remember them. It also makes simple the additional security recommendation of using different passwords on different systems.

Well, that's my two-cents' worth.

Purveyance

This doesn't answer the question being asked. – Undercoating

Answer 12

Some rules to follow:

1. Avoid Control Characters. It's not as prevalent today, but control characters all have special meanings and some hardware intercepts control characters to perform special functions. Some will cause data issues Example Control 0 (Zero) would generate a null.
2. Are you going to impose security restrictions? This is a user interface question as well as a security issue. What is your application and it's need for security. Many of the examples previously given are out of date. Hash tables for combinations of passwords are published for up to 15 character passwords and 16 character passwords can be brute forced withing minutes if the password is otherwise weak or follows typical human behavior. Starts with a capital, ends with number or special character.
3. I'd avoid common wildcard characters, quotes, colon, semi-colon, etc... that are commonly used in OS or DB languages.
4. Multi-factor authentication is a good way to go. Don't depend upon the password only or don't accept passwords at all.

Iatrogenic