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?
4 Answers
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_Ở!dcontains 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%A9when 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.
answered Dec 25, 2011 at 6:34
-
Not to mention that when you eliminate spaces, you're eliminating a bunch of easy to remember long passwords (and length has been proven more effective than complexity against cracking) and encouraging users to adopt gibberish passwords which are far less memorable than a long series of spaces. Dec 25, 2011 at 6:56
-
1I do agree with most of what I read hear, but I have a real hard time to digest the statement "the easiest way, when testing is not possible...". Testing not possible??? Anyone who agrees to a project where that occurs: stupidity efficiently maximized...Yes I know it happens :-|– ThomasDec 25, 2011 at 18:14
-
@Thomas: this is the difference between theory and knowledge in general and practice with its general ignorance and time constraints, where lots of people don't want to waste time testing, ignoring that they will spent at least twice later debugging. Dec 26, 2011 at 2:34
-
It may be reasonable to require that users define a passcode which consists only of digits if the same passcode may be needed for things like automated telephone access, but such a passcode shouldn't be the main authentication credential for computer-based access.– supercatJan 15, 2014 at 16:28
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
-
Are you saying there were technological restrictions with spaces in passwords that weren't there before? What part did storage exactly play in that? Dec 27, 2011 at 21:05
-
1I'm suggesting that technological limits and less complex external constraints (and possibly use of "trim") meant that people thought differently about what would be appropriate and allowable. You might place limits on passwords to ensure that they are liable to be memorable because resetting them is harder. You might not encrypt them because simply getting to a place where you can read them is (at the time) relatively very difficult (and in any case the systems are not accessible from the outside world). Different times, entirely different thought processes that have left a legacy– MurphDec 28, 2011 at 11:45
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.
answered Dec 24, 2011 at 18:50
-
1I prefer stripping leading/trailing spaces from passwords because they tend to cause problems but that's no reason to disallow them--they'll just get stripped both on setting and testing, no problem. Dec 25, 2011 at 3:23
-
And what exactly are the "problems"? I have been emphasizing in the answer that spaces SHOULD BE allowed. "They'll get stripped both on setting and testing" - What's the point then? then " 1 4m 1337" and " 1 4am 1337 " both hash to the same value(actually, there are infinite number of possibilities in theory). Dec 25, 2011 at 8:10
-
What's the point then?Minor point is that the password is of less entropy as user intended. And some systems trim GET/POST vars by default, an (unlikely) change to that behaviour will lead into more serious problems.– yannisDec 25, 2011 at 10:42 -
@Yati sagade: I'm NOT talking about stripping internal spaces. I'm talking about leading and trailing spaces--people don't realize the space is there and it causes login failures. Likewise, if you see a password that's all caps flip it to lowercase, it's probably someone who didn't realize caps lock was on. Dec 25, 2011 at 21:12
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.
-
What reason would you have to employ a whitelist beyond enforcing a particular character encoding? The fact that restricting arbitrary characters confers no benefits while weakening the passwords users choose is what I base this opinion on. All of the examples I gave are symptoms of developers not thinking through design choices carefully enough. Dec 25, 2011 at 6:45
"insert into USERS (..., password) values (..., '" + $POST['password'] + "');":-S