Why do certain sites prevent spaces in passwords?

Question

It seems less common with newer websites, but many websites I need an account on (like for paying bills, etc.) prevent me from creating a password with spaces in it. This only makes things more difficult to remember, and I am aware of no database or programming restrictions on spaces in passwords, encrypted or (heaven forbid) otherwise. Why, then, is the spacebar so commonly discriminated against when it comes to signing up for a site?

Answer 1

There are a huge amount of stupidities when it comes to passwords in websites.

• Some have purely technical reasons (valid or not, that's another question, but nearly all of them are not):

Your password must be four characters length and have only digits.

(By limiting a password to 0001 .. 9999 range, you can simply store them as a number, plaintext, in the database)

• Other are explained by some erroneous thoughts that they will make passwords more secure:

Your password must start with a capital letter and end with a digit.

(By doing this the developer, or the manager, assumed that this will actually force the users to choose a safe password, while the rule as "Your password must contain min. 6 characters and contain at least one capital letter, lowercase letter and a digit" will magically fail to do it)

• Other, finally, are explained by the fact that passwords are stored plaintext, and there are some ambiguities about how they are stored, processed or retrieved, and there are no time to unit test them.

Your password contains an invalid character é.

or,

Your password y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!d contains some invalid characters. Use characters from Latin alphabet and digits only.

or,

Your password cannot contain whitespace characters.

In all three cases, the developer was just insure that passwords like this will be stored correctly.

• In the first case, what if é will be transformed into %C3%A9 when sent? Or what if the database will store é incorrectly?

• In the second case, what if PHP (why PHP?) cannot deal with unicode, and does something terrible when receiving a password like this? What if < character causes trouble? What if & character is interpreted as a separator in an URL (assuming that for some reason, the password is being sent through GET instead of POST)? What if ' is interpreted by the database, because, guess what, we have no idea what SQL Injection is and how to avoid it? Or what if ' is transformed into \'?

• In the third case, what if PHP (again?) trims whitespace in some cases and not in others? What if the administrators (who have surprisingly the access to users passwords in plaintext) are lost because they see only one whitespace, while the user have set three consecutive whitespaces?

In all three cases, those ambiguities are easily solved through testing, especially unit testing. But in a huge amount of projects, there is no testing at all, and no time to test (but still plenty of time to debug later).

This means that whether the developer tries to think about the possible consequences of allowing spaces, or unicode characters, or just any character outside ASCII 48..57 ∪ 65..90 ∪ 97..122 (digits, lowercase letters, uppercase letters), the easiest way, when testing is not possible, is to just forbid them.

In my opinion, this is the sole reason to forbid spaces. Yannis Rizos gave another reason related to UX. While being a plausible reason in theory, it doesn't work at all in practice: websites made by people who actually care about UX don't fix stupid password rules. Instead, websites where whitespace is actually forbidden are in most part done by people who never heard about UX. This is especially true since forbidding any character is really annoying from UX point of view, as any password-related restriction, including the useful ones, as the minimum number of characters.

Answer 2

The answer is History

We seem to forget that the basis of a lot this comes from a time when storage was not effectively free (on disk or in memory) when our ability to manage all these things was somewhat less than it is now and equally the ability of automated systems to attempt to crack same was also somewhat less.

There are lots of rants about passwords based on what we know now and what we can do now but the simple fact is that we're often dealing with a combination of legacy thinking and legacy systems.

Should there be restrictions in new systems now? I would hope not - far less reason now

Answer 3

IMHO, It is outright foolish of any site/app that uses modern hashing and/or salting to store passwords to not allow for spaces in passwords. But, some legacy systems(read about this somewhere) still pass around passwords in plaintext - so not allowing spaces there may make sense. Also, some apps may "strip" all string inputs they receive. So, a password starting or ending with a space is not going to be good(of course, that was over contrived, but you can imagine what not can happen with almost anybody coming up with his own site). There is nothing "bad" in allowing spaces in passwords - as you point out, the DBs won't disallow the hashes or the plaintext versions.

Actually most of my Windows friends don't know that they can use spaces in their passwords - So, maybe, as per Tim Medora's answer, site owners don't want to take chances with lamahs(pardon that) or maybe some of them have misconceptions and/or are ignorant of the advantages spaces can provide.

Answer 4

It's done for the same reason that many sites don't allow hyphens, apostrophes, or non-ASCII letters in names, even though these are very common practices even just within the U.S. and it requires more work to disallow these characters than to simply allow them.

It's also done for the same reason many sites' word filters won't let you use words like "cocky", "retardant" or even "accumulate" (though many common racial slurs are perfectly alright).

It's because a lot of developers are apparently completely lacking in common sense, or at least have a very limited imagination when considering possible user inputs and scenarios. A small percentage of them may be working off of false information (that excluding non-alphanumeric characters is somehow a standard practice, or that the hashing algorithm or storage method can't handle spaces or special characters). Others may simply be lazy—they're worried about charset issues, so they simply restrict inputs to a minimal character space. And then there may be those who are exercising overzealous input validation/sanitation because of paranoia due to a lack of understanding of real threats.