122

"Your password can't contain spaces." is a message I see from some websites, including 1 .

Why? (This question is very similar to Why Disallow Special Characters In a Password? , but the answers there don't seem to apply to the space character).

Some systems apparently strip out all spaces before hashing the password. ( How does Google not care about "spaces" in Application-specific passwords? )

Why not simply hash whatever the user typed in, spaces and all?

  • 3
    There is a related question from a different POV on UX.SE: Should I trim spaces in passwords?. – Lekensteyn Mar 23 '13 at 17:43
  • 1
    Any restriction that is explicit like this can be used by an attacker to reduce search space. Like saying it must start with a digit, or be a certain length. – SDsolar Dec 10 '16 at 18:04
  • 4
    Microsoft Office 365 accounts don't allow spaces and angle brackets i.imgur.com/yxt96Jx.png. It's 2017, six years after the XKCD four word passwords were popularized and still Microsoft can't handle spaces. I reckon they just store all passwords in a massive XML blob inside an access database somewhere. – icc97 Apr 11 '17 at 16:42
  • Spaces should not be generally used anywhere in things like passwords, URLs, file names. In each case they may cause various anomalies to happen. – Overmind Jul 3 at 8:53

10 Answers 10

101

I can't explain it as anything beyond legacy madness, or lazily copying username restrictions to password restrictions without forethought.

Any block of data, printable or otherwise, should be acceptable if you're hashing your passwords. The only restrictions should be a minimum complexity and a "sanity" maximum length so somebody doesn't soak up 1MB of bandwidth (and the corresponding CPU time to hash the input because you use a slow algorithm, right?) every time they login.

  • 1
    Isn't hashing time is irrelevant when using key derivation methods, even if the first round takes slightly longer? – Lekensteyn Mar 15 '13 at 16:25
  • 1
    Well, I wouldn't call it irrelevant, but you're right that the time complexity is the same for all rounds after the first round no matter what the input is. – Jeff Ferland Mar 15 '13 at 17:33
  • 2
    I would check relevant client environments for field entry limitations. For example, an online service needs to allow logins from web browsers, so input restrictions should correlate to browser form field limitations (if any). Also, rejecting newlines might prevent client platform inconsistency problems (\r\n vs \n). – Roy Tinker Mar 15 '13 at 21:52
  • 2
    Don't forget to force the browser to actually send UTF-8 all the time, otherwise you'll have nasty bugs. – Reactormonk Mar 16 '13 at 12:15
  • 1
    @Laurent: it's the user's job to make sure they can. But frankly, what are you doing here if you entertain the thought of "sharing passwords"? – Jürgen A. Erhard Apr 24 '13 at 15:07
36

Leading and trailing spaces could be trouble for people who are loose with copy and paste. Otherwise, agreed with the other posts, no good reason.

Although, what other characters are we blocking? tab, cr, lf, backspace, beep ☻☺♪▬♣. ?

  • 2
    ewanm89- If you strip whitespace behind the scenes instead of up front for passwords, you run into a problem with the cases where the whitespace was intentional. Granted this probably occurs very, very infrequently. – AndrewStevens Mar 16 '13 at 0:16
  • 1
    @AndrewStevens But even if it was added intentionally, the user probably wouldn't notice that the whitespace is stripped behind the scenes (as long as it's stripped every time it's entered, and not just when the password is created). – Peter Olson Mar 16 '13 at 16:53
  • 5
    @PeterOlson: I guess I didn't make my point well (legit my fault - sorry =P) What I meant to say was, I don't think it would be good a user counts on trailing whitespace to make his/her password long, but isn't told when the whitespace is stripped. It means that the user's password is potentially far less secure, but the user has no idea. – Kevin Mar 16 '13 at 20:58
  • 5
    @Kevin, I think that this is more of a UX problem, if you notice at creation time that there are trailing spaces in a password then warn the user that this is not recommended. Don't stop them from doing this but tell them that their password will not be as secure. – Ziv Mar 18 '13 at 21:16
  • 5
    Another reason to strip at least trailing space: on phone/tablet soft keyboards, its very easy to get an extra space after the username and/or password. – derobert Mar 19 '13 at 20:24
25

The simple answer is that it is a bad password policy.

I can think of no particularly good reason for forbidding the space character. This is probably just some arbitrary requirement set by a well-meaning but wrong person.

10

I can't think of any solid security reason other than it discourages people from using actual sentences as passwords which would be very insecure if they had actual meaning. Strictly speaking, there is nothing insecure about a space in a password if it maintains good entropy, so people being "creative" is the only real thing that I can see.

There might also be a usability concern that spaces are hard to visually make sure you typed correct if the password is rendered visibly. (Is that one space or 4, granted if it appears a *s then it is easily countable.)

  • 22
    Sentences for passwords aren't all that insecure there are more possible ways of stringing together 5 words from a dictionary of ~250,000 words than 5 characters from a character set of 128 characters (ASCII). Even if we only choose combinations of words that have meaning against random individual characters there happens to be more entropy, the problem is some phrases are likely to be more common than others is also an issue with character strings used as passwords. Finally refusing space doesn't stop the use of a sentence, just don't put the spaces between the words. – ewanm89 Mar 15 '13 at 19:18
  • 3
    yes, but that is no different from people using password as there password... the same issues apply, sentences are easier to remember and can have vast varying meanings with a higher number of possibilities using the most common in either case is always bad as it is going to be the first the attacker is going to try. – ewanm89 Mar 15 '13 at 21:20
  • 2
    @ewanm89 Actually, it is very different from using "password". "This is my password" is in fact much safer than "password". Also, if it is requiring numbers and special characters, you are likely to end up with "1his is my p@ssword" which is at least more secure than "p@ssw0rd". Finally, this is probably rather instructive: xkcd.com/936 – Patrick M Mar 16 '13 at 16:05
  • 1
    @PatrickM that would depend if the attacker knew you were using a phrase or not. If an attacker had a phrase dictionary of the most commonly used phrases it is the same as a dictionary of most commonly used passwords. – ewanm89 Mar 16 '13 at 23:53
  • 1
    @AJHenderson Yes, it can be worse than a "well selected" english word, but if you need a password policy, you are assuming that most users will not be "well selecting" their password. Basically, my claim is that a badly selected sentence is almost always better than an equally badly selected password. As an example, people often pick what is in front of them for their password. So, I might pick "horse" or "On a Pale Horse". (A book that was randomly in front of me) Now, I admit that phrase is a bad password, but that phrase is often BETTER than an equivalently badly selected word. – Patrick M Mar 17 '13 at 1:11
7

It’s a very good policy for convenience, and having seen this from the customer support side – I think this should be implemented everywhere.

You can write the password like this: “ abc def ghi ” and copy it to a piece of paper, or copy and paste.

It’s simply easier to strip all spaces than to keep telling everyone:

  • “Make sure you aren’t copying and pasting any white space characters”
  • “Type in the password manually, don’t copy and paste it”

Which is usually an answer to the question:

  • “My password isn’t working, even though I copied it exactly from the email you sent to me”
  • Or it could simply be written as "abc def ghi"... – Kevin Fairchild Aug 6 '14 at 0:41
  • 9
    There are two big flaws with this. First off, if spaces are such a problem then you can simply strip them behind the scenes before hashing the password and when the user logs in. Second, if you're sending someone their password then you've got bigger problems than spaces. Also, stripping spaces on behalf of the user before hashing and upon sign in also takes care of the copy-paste issue. – Bill Jan 16 '16 at 20:50
  • If you have to provide initial password to customer, generate one without spaces to avoid issues you mentioned. But customer should be able to change this initial password to another one which contains spaces. – Daniel Frużyński Jul 6 '18 at 10:02
3

its only about programmatic semantics. most everything handles the space character ' ' or " " different from other symbols like 'a' or 'dds'.

the blank space character gets lumped into other strange characters such as new lines - '\n' or blank characters - ''

It is also not unique, as some special characters on certain computer environments don't have a representation, and get parsed to a blank character ' '

In some computer environments where we were passing files back and forth from MAc to Windows to Linux, we sometimes ended up with (' ' == ' ') to produce a FALSE result (the double equals sign simply signifies a comparison operator). It was false because there were hidden symbols existing in the space that we couldn't see due to computer cultures being different across our team.

I am unsure whether or not this problem would ever occur when talking stictly passwords, but having no spaces in special areas such as passwords and function names and file names is defiantly the better way to go always. Parsing spaces in filenames is a whole different story, with some programs adding a % to a space to remove the space so you would have the name being the%name

  • 6
    Everything you mentioned is strictly an encoding issue, which shouldn't have an impact on a properly designed password hashing system. – Ayrx Mar 16 '13 at 1:16
  • oh well, just adding some more reading material to the common knowledge base then. – jordan Mar 18 '13 at 21:31
  • 3
    Jordan's answer is at least relevant. Issues with spaces such as the ones he mentioned could have contributed to the construction of the "no spaces in passwords"/"spaces can be problematic" paradigm. Even though spaces should not effect properly designed password hashing systems, their tendency to cause bugs in other code could have scared some people into banning spaces from passwords on their sites. – user22208 Mar 19 '13 at 2:25
3

On most keyboards, the Space key makes a sound that's slightly different from that of any other key.

Consider the scenario in which a person hears someone else type in their password.

If that person is able to figure out that the password consists of, for example, 3 characters + a space + 4 characters, that could be a very useful hint in some cases.

  • 4
    The same argument could in many cases count against many other kinds of non-alphanumeric characters as well, especially accented ones, as well as the use of mixed case (since key presses sound different from releases, press-press-release-release is different from press-release). – supercat Feb 2 '14 at 19:56
1

I can think of several reasons why spaces should be excluded; these reasons have nothing to do with security though but with usability:

  • If you transmit a password that have spaces in it, how does the recipient knows that it's a space or a tab? And is it one or two spaces? Assuming you have to hand-write it (it happens), how to show this information? Depending on the font of their email client, there's also a chance, they won't notice the blank space(s).

  • Again, when sending the password, if the spaces are at the beginning or end, it will be easily missed and will have to be enclosed in quotes. But even then it will look odd and I can easily imagine users not including this last space and being unable to login.

  • Blank characters (newlines, tabs, spaces) are often trimmed from the end and beginning of a field, to avoid people copying and pasting incorrect data. Obviously if the spaces were significant, that would cause a problem.

All in all, I think not having spaces avoid all kind of problems and saved support calls, so it is a good thing.

Edit:

To answer the comments about the bad practice of sharing passwords:

Let's say important business documents are locked on Bob's station, who is currently on vacation. What to do in this case? Wait for Bob to return two weeks later and lose potential business in the meantime? Or just ask him to send the password? It's Bad for sure but still better than the alternative.

As Linus Torvald put it (about something else, but I like the spirit): "you should deal with reality, not what you wish reality was".

  • 3
    Well, sending passwords in plaintext is a bad idea. – jb. Mar 16 '13 at 10:05
  • 1) As mentioned, sending passwords in plaintext is a bad idea. If the user decides to put in a space and then try to tell someone what their password is, that's their problem. If this is for password recovery, stop storing your passwords in plaintext, and let users reset their password instead. 2) If you aren't properly quoting/escaping your users' passwords, you deserve the trouble that's in wait for you. 3) If the password is consistently trimmed, does it matter? After all, if every password input dialogue trims spaces, it's not going to have much effect the user can see. – Patrick M Mar 16 '13 at 16:09
  • 1
    I think you are missing the point, I'm a dev, I hash passwords, I don't send them by email, I know about the good practice, but that's not the point. Sometime passwords are being sent by email, over the phone, written on piece of papers, etc. it's all wrong, ok. But as a developer, we would make it even more wrong by allowing spaces in passwords. That would be potentially hours of wasted support calls/emails for a useless feature. – laurent Mar 17 '13 at 4:46
  • 3
    I don't buy it. If someone chooses to use a space in their password they can easily just tell someone to mind the space. By your logic capital letters should also be disallowed. I use spaces in my passwords whenever I can and I've shared passwords through email or verbally many times. What I always do is say "the password is 'My Password' - mind the capital letters and the space between words". It's never been a problem. – Bill Jan 16 '16 at 20:57
1

I believe most non-programmers feel (consciously or not) that the space character is essentially different from other characters in that it only serves to separate words from each other; being just metadata instead of data.

This feeling is strengthend by the fact that there is no sound corresponding to the space character. Most people remember their passwords in pronounced form (how they sound when spoken out loud) instead of the visual form (how they look like when written).

Therefore they would unconsciously consider "My Password", "My Password" and "MyPassword" to be the same because they are pronounced equally and they can easily see (thanks for the capital "P") where one word ends and the next begins -- even without a space. Of course, if you asked them whether those three are the same, you would lift the issue from the unconscious to the conscious mind and everyone would answer "no". But as long as nobody asks the question...

So the problem in allowing spaces in passwords is practical: it helps users to forget their passwords, i.e. help them forgetting whether there was a space (or two or three or...) in the password or not.

  • Is essentially different The term for that is (unsurprisingly) whitespace. – forest Jul 3 at 8:16
  • 1
    '..."My Password", "My Password" and "MyPassword"...' Interestingly, the double space character in the first of the three was automatically reduced to a single space character when I posted the answer. This is a good example of the point I tried to make. – user11717468 Jul 3 at 8:23
  • @user11717468 No, your double space is still right there. Most browsers just don't show it. You can format the text as code like this: `My Password` to show the double space. – rahuldottech Jul 3 at 8:41
  • @rahuldottech Thanks for the formatting advise. – user11717468 Jul 3 at 9:16
0

I am going to qualify this comment by saying I have been a sysadmin for over thirty years... and a writer for at least as long.

Although using a space in a password may be allowed in some circles, and it may be more secure in the sense that you have a greater character set to harden your password with... you are asking for trouble by doing so. A space is not just a character, is it a representation of null space, just like a zero represents an absence of numerical value. The day will eventually come where you will “forget” the space and will pull your hair out wondering why your root password doesn’t work anymore and have to reload your server from scratch. From a useablility standpoint - I say keep away from the space... it’s one of those “unwritten rules” that you can give a hundred reasons not to obey but your life will be made easier by adhering to. In thirty years I only encountered one person who used a space in a password and it was hell trying to figure out. Others will disagree - and that’s their prerogative. I would never use a space.

  • A space character doesn't represent "null space". Outside of some Unicode representations, it's just a string of eight bits, as letters and numbers are. Also, a zero isn't an absence of numerical value; it's a placeholder that has meaning. If you doubt this, binary-replace all '10000000'x with '00000001'x in one of your executables and see what happens. :) – user46818 May 5 '18 at 19:03
  • It's 2018. We have Unicode 10.0 containing 1,114,112 enumerated graphemes. Of those, 136,690 are assigned and named. That's 17.061 bits of entropy per symbol (that could be used). It's past time the industry kept pace with technology and stopped regurgitating policies of the last 3 decades. There may well have been very practical & technical reasons to prohibit UTF-8 codepoint 32, but they don't exist now. To make a passphrase, users should be free to use any Unicode codepoint; resulting in a salted, hashed, stretched (or rotated) encryption key. – Mac May 30 '18 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.