Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

Why? (This question is very similar to Why Not Allow 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?

share|improve this question
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

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.

share|improve this answer
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
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
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
That's looking at it from the point of view of a computer. Sure, computers don't mind what sequence of bytes they get. But what if you need to share this password between humans? – this.lau_ Mar 16 '13 at 5:39
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

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 ☻☺♪▬♣. ?

share|improve this answer
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
@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
@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
@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
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

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.

share|improve this answer

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

share|improve this answer
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
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
@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: – Patrick M Mar 16 '13 at 16:05
@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
@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

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”
share|improve this answer
Or it could simply be written as "abc def ghi"... – Kevin Fairchild Aug 6 '14 at 0:41
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 at 20:50

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

share|improve this answer
Everything you mentioned is strictly an encoding issue, which shouldn't have an impact on a properly designed password hashing system. – Terry Chia 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
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. – Evan Teitelman Mar 19 '13 at 2:25

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.

share|improve this answer
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

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.


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".

share|improve this answer
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
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. – this.lau_ Mar 17 '13 at 4:46
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 at 20:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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