137

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

Community
  • 1
David Cary
  • 2,720
  • 4
  • 19
  • 20
  • 4
    There is a related question from a different POV on UX.SE: [Should I trim spaces in passwords?](http://ux.stackexchange.com/questions/8010/should-i-trim-spaces-in-passwords). – Lekensteyn Mar 23 '13 at 17:43
  • 3
    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
  • 5
    Microsoft Office 365 accounts don't allow spaces and angle brackets http://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 03 '19 at 08:53
  • 2
    One interesting read is that, in `NIST 800-63B`, it is note that *space should be accepted in password*, see https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers Guess not everybody listen to them lol – Ng Sek Long Oct 05 '19 at 09:02

11 Answers11

120

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.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • 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
  • 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? – laurent Mar 16 '13 at 05:39
  • 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
  • @jürgenA.Erhard, I don't entertain any thought, just stating facts. Users sometime do "the wrong thing" and we shouldn't pretend it never happens. There's a cost/benefit for any feature we implement. In this case, allowing spaces has only a very minor benefit, but a potentially high cost (in support calls or in wasted development time to find "bugs" when in fact it's just users typing their password wrong). – laurent Apr 25 '13 at 02:38
  • And what about allowing "any block of data" as suggested in this question? That might be ok from your laptop, but then some day you try to login from a mobile device that won't have a tab key or the special non-printable characters you entered, and you're stuck. That's why I suggest to keep it simple - allowing more just leads to more troubles, with little added security. – laurent Apr 25 '13 at 02:39
  • @this.lau_ : I have "hackers keyboard" on my Android devices for that very reason! – Mark K Cowan Dec 09 '14 at 11:47
  • Then how about someone saving their password that includes a tab character in a text file? Then they cat the file in a terminal and the tab becomes spaces. They cannot login and contact support, waste their time, telling them they've copied and pasted the password so they are sure it's right. Again wasted money and time, and next to no added security. Of course, we don't like that users save their password in text files but it happens (especially when the super-secure system forces a password change every two days). – laurent Dec 09 '14 at 13:34
  • `and a "sanity" maximum length so somebody doesn't soak up 1MB of bandwidth`, right: http://www.cvedetails.com/cve/CVE-2013-1443/ – Jorge Leitao Feb 23 '15 at 18:22
  • You probably shouldn't allow the null control character, as a) you can't input it in Chrome and b) Postgres will raise an exception – Neil McGuigan Apr 09 '15 at 22:31
  • _and the corresponding CPU time to hash the input because you use a slow algorithm, right?_ Slow KDFs don't get slower if the input is large. PBKDF2, for example, will pre-hash a large password with a fast hash before performing the slow iterated HMAC on it. The bcrypt algorithm only takes a password up to 72 bytes, so larger passwords are usually hashed with a fast algorithm first. Argon2 uses BLAKE2 for this. – forest Jul 03 '19 at 08:18
  • How can a user be expected to write down their password on a postit, if it contains whitespaces?! Madness! – Aron Jul 03 '19 at 09:57
  • IBM's CALL/360 timesharing services even allowed **backspaces** in passwords. It was intended to add security when signing in on terminals that printed what you typed. – Martin Kochanski Jul 03 '19 at 10:49
40

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

mgjk
  • 7,535
  • 2
  • 20
  • 34
  • It wouldn't be hard to ignore leading and trailing spaces if this is a concern. – Nathan Long Mar 15 '13 at 19:12
  • I bet whatever language processing the page has standard library functions for trimming leading and trailing white space characters. – ewanm89 Mar 15 '13 at 19:20
  • Yeah, that's my guess. I can't tell you how many problems I've had with leading and trailing spaces with user-inputed URLs on the site I manage. – AndrewStevens Mar 16 '13 at 00:14
  • 3
    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 00: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
  • @PeterOlson What happens to the user whose password is " _ _ _ _ _ _ _ _ password _ _ _ _ _ _ _ _ _ _ "? – Kevin Mar 16 '13 at 20:54
  • @Kevin If you strip out spaces, that password is indistinguishable from the password "password". – Peter Olson Mar 16 '13 at 20:56
  • 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
26

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.

11

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

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • 23
    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
  • @ewanm89 - You are correct that random words are not insecure, but people would tend to make meaningful sentences like "this is my password" which are not secure by any means. I'm also not saying it's a GOOD reason. I'm just saying it may be a reason. Personally, I wouldn't block spaces. – AJ Henderson Mar 15 '13 at 19:51
  • 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: http://xkcd.com/936/ – Patrick M Mar 16 '13 at 16:05
  • @PatrickM - horse battery staple works because they are random words. Sentences don't add much because there are fairly few options for how they connect. Not saying they don't add anything, but they can actually be destructive compared to a well selected non-English password that is much shorter. – AJ Henderson Mar 16 '13 at 20:14
  • 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
  • Of course in all cases random nonsensical strings of words or characters of sufficient length is more secure than non random. but with characters people also make them make sense, and there are less combinations that make sense. after all all are consonant sound, vowel sound consonant sound, vowel sound phonetically. There are less ways to connect a string to make a memorable word especially as we tend to be taught to read/write phonetically. – ewanm89 Mar 16 '13 at 23:58
  • 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 01:11
  • 1
    Basically, in a perfect world people would pick good passwords, but nudging someone from a badly selected phrase to a badly selected word is a mistake. (I'm ignoring number and symbol requirements, because adding numbers and symbols to a word usually doesn't improve it more than adding numbers and symbols to a phrase) – Patrick M Mar 17 '13 at 01:16
  • I'm not sure I agree with words-with-spaces being less secure than words-without-spaces. If the 'no spaces' rule is known, any attempts that would have occurred using phrases with spaces would then just be done without spaces. Unless you are counting on an attacker who doesn't check the password rules prior to launching an attack, I guess... – Kevin Fairchild Aug 06 '14 at 00:40
  • So, to summarize these comments: "I'm a little teapot" (entropy 4^250k) is better than "teapot" (6^26) but possibly worse than "T3@p0t45" (8^128) due to being a *very* well-known phrase. It's definitely no worse (and perhaps marginally better) than "I'malittleteapot" (also 4^250k), but "I really enjoy drinking tea, especially if it's from a high-quality teapot." is better than all of the others, with 13 words plus 3 punctuation marks (comma, hyphen, and period - the apostrophe in "it's" doesn't add to entropy) - so 16^250k, and while it has meaning, it's not a particularly common sentence. – Dan Henderson Jan 13 '16 at 21:13
  • @DanHenderson - No, your entropy calculations are incorrect because they are not randomly selected words. Meaningful sentences have a lot of structure which drastically reduces the actual entropy. Simply entropy calculations are only valid for truly random choices. For example, if you have "I'm a little ........" then there are much fewer than 250k words likely to fill that spot. Unless it's purely random, it isn't simple entropy. Also, like your last name... :) – AJ Henderson Jan 13 '16 at 21:19
  • @PatrickM - I don't disagree it's probably a bad policy. However, if someone chooses a simple word, they know it is insecure. If they make a sentence they may think it is more secure without actually being significantly more secure. I suppose the hope would be that by not letting them be "clever" they might actually make a secure password, but that's really not a particularly good idea either since they could simply drop the spaces. – AJ Henderson Jan 13 '16 at 21:23
  • @AJHenderson well, by the same token, "teapot" isn't really 6^26 for the same reason - there are only about 10 letters that would logically follow the initial **t** (including **v**), and possibly just one letter to follow "teapo". However, just as an attacker doesn't *know* you used "teapot" without capitals and must therefore include "Alpha" and "aLPhA" and "a!3h^" in his attack, and deciding which of those come before "teapot" affects the effective strength of "teapot", he also doesn't *know* that you didn't use "horse battery staple" and must decide whether 3-word nonsense phrases should – Dan Henderson Jan 13 '16 at 21:44
  • ...be tried before 4-word meaningful phrases. – Dan Henderson Jan 13 '16 at 21:45
  • @DanHenderson - indeed, the 4 word phrase is certainly more secure than just one word in terms of guessing. The risk is that most people will realize "teapot" isn't secure, but they might not realize that "I'm a little teapot short and stout" really isn't that much more secure. Giving someone the illusion of security can be very dangerous from a user's perspective. That said, I don't thing a "no space" policy does much to actually accomplish that, but it's literally the only reason I can think of that someone might try to limit it. Unfortunately ineffective but well meaning policy is common – AJ Henderson Jan 13 '16 at 21:57
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”
Community
  • 1
sharp12345
  • 1,969
  • 3
  • 13
  • 23
  • 1
    Or it could simply be written as "abc def ghi"... – Kevin Fairchild Aug 06 '14 at 00:41
  • 13
    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. – wgp Jan 16 '16 at 20:50
  • 2
    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 06 '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

jordan
  • 131
  • 1
  • 8
    Everything you mentioned is strictly an encoding issue, which shouldn't have an impact on a properly designed password hashing system. –  Mar 16 '13 at 01: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. –  Mar 19 '13 at 02:25
2

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.

Cristian Lupascu
  • 129
  • 3
  • 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 02 '14 at 19:56
0

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.

user11717468
  • 9
  • 1
-2

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.

Steve Warnek
  • 1
  • 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. :) –  May 05 '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
-2

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

laurent
  • 751
  • 1
  • 8
  • 22
  • 4
    Well, sending passwords in plaintext is a bad idea. – jb. Mar 16 '13 at 10:05
  • 1
    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 04:46
  • 4
    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. – wgp Jan 16 '16 at 20:57
  • 1
    Typing and handwriting all have conventions for communicating spaces (and even other whitespace characters). And according to this logic, capital I and lowercase l should be avoided, too. For this very narrow use case, one could choose not to use spaces. You have not made your case for systematically preventing their use. – schroeder Jan 28 '20 at 12:02
-3
How do we create passwords?
  1. Someone can send password/access_code to the user
  2. Password is generated
  3. User creates a password
Sent password

In the first situation, it could lead to reading problems.
example: (someone sends)

user: username
password: secure!pass   
actual_password: secure!pass[invisible space]

The space character can be added by mistake, or on purpose but it will be uncommunicated and also makes copy and pasting more hard, because they need to include the whitespaces.

Generated password

When password is generated problem will occur that you might specify allowed characters for generation that will contain a space character. When user gets an e-mail with a password with a whitespace at the end or beginning, which would be problematic.

User created password

User might unknowingly hit space, and think that it doesn't matter that he did that as most programs don't allow spaces, he will be surprised on login. Other than this very questionable example there's nothing wrong with a space.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Robert Mielewczyk
  • 1
  • The problem in #1 is not solved by having a password policy that forbids spaces. Your #2 seems the same as #1. #3 is meaningless and contradicts itself. It is also irrelevant. – schroeder Aug 23 '22 at 14:12
  • In addition, you appear to simply repeat the various other answers. – schroeder Aug 23 '22 at 14:16