Why not allow spaces in a password?

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

    There is a related question from a different POV on UX.SE: Should I trim spaces in passwords?.

    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.

    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.

    Spaces should not be generally used anywhere in things like passwords, URLs, file names. In each case they may cause various anomalies to happen.

    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

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

    Isn't hashing time is irrelevant when using key derivation methods, even if the first round takes slightly longer?

    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.

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

    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?

    Don't forget to force the browser to actually send UTF-8 all the time, otherwise you'll have nasty bugs.

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

    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.

    @this.lau_ : I have "hackers keyboard" on my Android devices for that very reason!

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

    `and a "sanity" maximum length so somebody doesn't soak up 1MB of bandwidth`, right: http://www.cvedetails.com/cve/CVE-2013-1443/

    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

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

    How can a user be expected to write down their password on a postit, if it contains whitespaces?! Madness!

    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.

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

    It wouldn't be hard to ignore leading and trailing spaces if this is a concern.

    I bet whatever language processing the page has standard library functions for trimming leading and trailing white space characters.

    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.

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

    @PeterOlson What happens to the user whose password is " _ _ _ _ _ _ _ _ password _ _ _ _ _ _ _ _ _ _ "?

    @Kevin If you strip out spaces, that password is indistinguishable from the password "password".

    @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, 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.

    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.

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

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

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

    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 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 [email protected]" which is at least more secure than "[email protected]". Finally, this is probably rather instructive: http://xkcd.com/936/

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

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

    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.

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

    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)

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

    So, to summarize these comments: "I'm a little teapot" (entropy 4^250k) is better than "teapot" (6^26) but possibly worse than "[email protected]" (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.

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

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

    @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

    ...be tried before 4-word meaningful phrases.

    @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

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

    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.

    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.

  • 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

    Everything you mentioned is strictly an encoding issue, which shouldn't have an impact on a properly designed password hashing system.

    oh well, just adding some more reading material to the common knowledge base then.

    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.

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

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

  • 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**.

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

    Well, sending passwords in plaintext is a bad idea.

    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.

    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.

    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.

    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.

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

    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.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM