Probably because of this. A bunch of coders get into a meeting with a bunch of managers, passwords and security come up, it's a bike shed issue, so everyone throws their two cents in.

Some guy saw something break once because a password with a space was passed on exec(). Some guy knows that crypt() only uses the first 13 characters. Some guy knows that passwords with less than 5 characters are extremely weak. Some guy knows that \ also breaks when passed to exec() or sh, etc. This goes on ad nauseum for about an hour, a bunch of people are bored and just want to get out of the meeting so they propose the following which everyone can agree on.

Spec: Alphanumeric passwords with a minimum of 5 characters and a maximum of 13.

Result: m/^[A-Z,0-9,a-z]{5,13}$/

I love your story on this. Someone should write/compile a book of stories like this for every stupid "Best Practice" in programming and web design.

Yeah, but there isn't enough money in the world to make me want to go back to developing "enterprise" software. Let alone document its development.

It's not so stupid but pragmatic. It sounds like those errors are the types of which are whispy and hard to track down. Thankfully at this point we're all pretty familiar with that type of standard and abide almost automatically.

But I hate you if you force me to have capitals or numbers or symbols!

"It's actually harder to disallow spaces"

Traditionally, when deciding what password characters to allow/disallow, everyone thinks in terms of what to allow, not what to disallow.

For example, a system that only allows alphanumeric characters in passwords (i.e. no special characters) would use less code to specify with regex that only a-z,A-Z,0-9 should be allowed, rather than specifying the many characters to be blocked (and even when more complicated options were allowed, code generally still specifies allowed characters, rather than disallowed characters).

Therefore I would suggest that websites disallowing spaces in passwords is in fact just that they didn't see fit to allow them, not that they went out of their way not to.

Right, but why block any characters at all? Blocking spaces is harder than blocking nothing is what I meant.

I think it's good practice to trim leading/trailing whitespace from all inbound data. Google docs for one usually appends a newline to data kept in cells. Not so good if you're keeping passwords in a spreadsheet.

That doesn't address spaces IN passwords, but I know I've never written a script to block them. If I had to guess I would say it depends on individual frameworks or the behavior of individual languages. E.g. python has a decent strip() function, javascript doesn't. If you need to trim whitespace in javascript you need to write a regex. It would be easier to test/remove all whitespace instead of trailing/leading whitespace. Maybe that's a clue.

I've done it for a similar reason: it cuts down on support requests (ever so slightly).

No matter what you tell them, users will store passwords in text files and email them around in spreadsheets, and spaces interfere with cutting and pasting in a way that other characters don't.

It's not a strong reason, but no-one's ever complained about not being allowed to use spaces either.

The advanced ones just silently hate you. It's not an annoyance worth emailing about, but it is an annoyance.

There is no good reason. Spaces are no special characters in passwords. They should simply be allowed.

Surely there must be some motivation for disallowing special characters, though... it's certainly not for security purposes. Maybe it's a weird form of overzealous SQL injection protection?

I think it might be so that you can type in your password on any keyboard. Some special characters may be missing on some keyboards, or they may need to be typed in differently, depending on your locale.

For a company that really has no idea whatsoever about security: maybe they want to make sure they can read your password back to you over the phone in a way you'll understand?

Hm, yeah, this might actually be part of it. It would make me sad if a customer service rep could read my password to me, personally, but I suppose a lot of people probably like that.

White space in passwords might be confusing if the system offers to email a user his own password. (Whether this should be done or not is another argument and is heavily dependent on the nature of the application.)

How much entropy does white space add to a password? Where are most people putting spaces in passwords? Are they using passphrases (in which case the position of spaces can be guessed and thus have low entropy)?

Given that I can think of a potential downside and possibly no gain in security, I can understand why some may default to not allowing it.

Btw I always thought emailing a password back is just a habit from the past emerged with thousands of quick-n-dirty php apps in late 90s and this meme is copied till today "because others do it", and surely it's not any thoughtful application workflow.

What exactly do you have in mind telling this is dependent on the nature of the application? What type of applications should encourage it? Just curious.

What about in the case of a password reset request?

Ultimately there has to be some mechanism for a password reset, and there must be some level authentication during this reset.

How about a non-security-sensitive website which has a registration function and the only form of contact is via the registered email address? Users are likely to forget their passwords. The only way to verify a user in order to reset his password is with his email address. If you reset the password on request and then email it, then there is effectively a DoS there, and you are requiring the user to take extra effort (going back in and changing it again). If you email the existing plaintext password to him on request, then there is no DoS issue and minimal hassle for the user - provided that the security requirements make it acceptable for 1) a plaintext password to be emailed (but otherwise what else are you going to do?) and 2) the old password to be continued to be used even after it has been emailed in plaintext.

I'm not sure which of the two options I would implement myself. I'm not even aware of what existing webapps do since I use a password safe and so have never had to go through the process.

I'm just saying that for a non-security-sensitive situation, I have no major objection to the second option being used, and in this case it makes sense for white space to be not permitted in passwords. Since I'm not convinced that there is an entropy advantage in allowing spaces, I don't see why banning whitespace is a problem.

It's much better just to email them a password reset link. It's a little more complicated, but passwords should never be emailed plaintext, because a huge percentage of people use the same one across multiple sites.

I live like a tech luddite except when developing, so I don't use a password store for low security sites. One of my low security/throwaway passwords includes a space.

NO reason. After all the only thing going into the database ought to be base64 encoded hash. So why not allow anything? No need for a max length, by the same token.

To me, The most important reason to disallow spaces is being consistent with most of the web. Also, I think password with spaces are more likely to be forgotten. Its also easy to introduce spaces accidentally, and depending on the font parameters it might not be easily distinguishable too.

Leading and trailing spaces because more than one username would look the same on the page eg. "user" and "user " which would confuse others when signing comments etc.

We're talking about passwords, though, not the user name.

Every site that I have developed has allowed a space.

If there is a rationale I'll bet 99.9% of people don't know what it is. So, the answer is easy: because that's how everyone else does it.

Heh I'm trying to find one of those one in a thousanders.