I was signing up for a website last night, and once again was greeted with the fact that my username cannot contain certain characters (including spaces), and neither could my password.

Is there a historic reason for this, or is there no particular reason? Passwords that are phrases have higher entropy and are harder to crack than simple letter/number substitution (see image below):

enter image description here

And on the username front, no spaces? Really? It's just a string. I could understand historic concerns against SQL Injection attacks but modern websites are passed that now (I hope!)

  • 2
    You hope in vain... even some relatively modern and common authentication libraries are vulnerable to SQL injection. Having said that, telling people they can't have spaces, specific characters that might be useful in SQL, or specific words just draws attention to the fact. Commented Nov 22, 2013 at 9:12
  • 5
    Wrong site. Please look here: security.stackexchange.com/questions/33470/… Commented Nov 22, 2013 at 9:58
  • 3
    Maybe all our registration pages should have that comic embedded in it and force a min length of 20 characters :)
    – ozz
    Commented Nov 22, 2013 at 10:47
  • 1
    I thought this question was going to recommend something like using Facebook or Google accounts.
    – JeffO
    Commented Nov 22, 2013 at 13:27
  • 1
    This really belongs on a blog. Commented Nov 22, 2013 at 16:21

7 Answers 7


No particular reason at all. It's as arbitrary as "your password may not be longer than 8 characters". It's programmers or product owners that don't know what they are doing.

There can be some legacy reason for this, when the authentication system is linked to some credential system that has had certain limitations for historical reasons (something like a really old crypt() implementation skipping all password input after the 8th character as mentioned here), but given the vast majority of (web) applications is built on top of custom authentication systems and credentials are stored in relational databases, this really shouldn't be an issue nowadays.

  • 4
    You would not believe how old the average data processing systems are that a lot of present-day internet presences have to interface with. Commented Nov 22, 2013 at 9:10
  • 1
    @Kilian I do know that, as it's one of the areas I'm active in as developer: exposing data. This "no spaces in usernames" rule OP is talking about is seen everywhere though, especially on websites where you know they just put their credentials in SQL. I think it's arbitrary and done "because we've always done so", not particularly an actual system limit.
    – CodeCaster
    Commented Nov 22, 2013 at 9:13
  • 3
    @KilianFoth, oh I am sure there are many websites that interface with legacy systems. But I don't believe they are the majority and I agree with CodeCaster's comment that people do it because they always have. The same as incredibly modern websites that still insist you to enter the type of credit card you're using, when that offers no extra security and is already known upfront because of the first 4 digits!! :)
    – Moo-Juice
    Commented Nov 22, 2013 at 9:17
  • 1
    @Moo-Juice: I'd say that both that and this have the same root cause: Developers developing in a domain they are not experts in. Figuring out good password requirements requires at least a trivial understanding of both combinatoric theory and human psychology (though leaving it unrestricted and allowing power users to do well is very easy), and a good card input system requires knowledge of what you can infer from where. On both, libraries exist to do it Right very straightforwardly, but I suppose people don't know they exist/don't want to use them.
    – Phoshi
    Commented Nov 22, 2013 at 9:38
  • I have seen the requirement to have a pwd of EXACTLY eight characters/digits in length. Now that was really confusing. When asked, the guys told me it is "safe enough", because the account goes automatically locked at three wrong tries. I'm not so sure if that is a good idea either ...
    – JensG
    Commented Nov 22, 2013 at 19:20

Basically the same reason why SQL injection is still so common -- people that don't know better designing and building systems.

Just as with SQL injection, there are occassional exceptions, in the case of SQL injection simple bugs or legacy tools, in the case of username/password compatibility with other systems. But 99.99% of the time it's simply "didn't know better".

One reason to push for OpenId (google or facebook login), is to make a simple and easily understood system the default that everyone knows.


Besides the historical reason of disk space (yes, there was a time when disk space mattered!), there is always the encoding/escaping problem. When facing with special characters and spaces you always have to make sure that they are properly escaped (to prevent injection attacks) and encoded (to ensure you password actually works in the end). Nowadays, tool support for this is good; best practices are known and wide spread. Back in the days, excluding all special characters made life tremendously easier. Note that "easier" almost always means "less secure"...

In the end, there are two reasons for such restrictions in a modern application:

  1. The app depends on some legacy system that has this restrictions.
  2. Someone chose the "easy way out".

It sums up to: Someone didn't care enough for security. Why else would bank still work with online-banking systems that have 4 digits(!) fixed-length passwords?

  • Some nice thoughts here. I can understand banks having legacy systems they simply do not want to/cannot easily change. But they are in the minority of sites on the web. So I am pretty much thinking it is (2) from your list because there isn't really any other plausible reason. Something is either open to injection attacks, or it isn't. If it isn't, there's no excuse. "Correct Horse Battery Staple" is a perfectly valid, and secure password :)
    – Moo-Juice
    Commented Nov 22, 2013 at 9:48
  • As was stated before, you would be surprised about how many "modern" systems heavily depend on legacy monoliths. I worked in a software(!) company only two years ago where they still used a telnet-based time-tracking software that was not even able to calculate my working time based on the start and end time I entered... the reason: it worked and it was found to critical to risk down-time during exchange!
    – Sven Amann
    Commented Nov 22, 2013 at 10:00
  • While those two reasons do exist, I think you left out by far the most common reason people put these restrictions in: "(3) Because they see other sites doing it." Seriously, I think in most cases that's all there is to it. They put absolutely no thought into it, and just copy what they've seen other people do. It's cargo cult programming at its worst.
    – Ben Lee
    Commented Nov 25, 2013 at 23:20
  • I see your point and I agree that this could be listed as a separate point. However, I think it is a special case of not caring enough. Copying a solution from someone else without spending a thought about it implies that you don't care about the quality of the solution. You just want to have one. It's the "easy way out" all over again.
    – Sven Amann
    Commented Nov 26, 2013 at 9:36

Like the other answers stated, legacy reason.

Most web framework can escape it now and handle it.

I had a co worker that didn't know anything about prepared statement and so he coded a javascript regex that would just check for certain illegal characters and complains about it.

So it could also be the programmer lack of knowledge...


Characters limits are most probably because it is an easiest way to limit SQL injection and XSS attack surface. Proper escaping should be more comprehensive solution, and most modern frameworks support it, but given that data may be processed by different systems written by different developers in different environments, it is hard to ensure everything is done properly every time and nobody ever made a mistake or took a shortcut. It is much easier to just reduce the character set to a safe and predictable subset when possible.

With passwords though there's not much justification, since passwords are not supposed to be ever stored or displayed as-is. The only reason I can see to restrict character set is to deal with various encodings and bugs that may follow when developers or browsers do not handle them correctly. Within standard ASCII character set, there's absolutely no reason to not accept any string as a password.


I was signing up for a website last night, and once again was greeted with the fact that my username cannot contain certain characters (including spaces)

A lot of websites use usernames as keys to lookup records in a database, and traditionally keys don't have spaces. As for special characters that can be a wide range of reasons why they are excluded. The owners of the site simply might not want people named $%@#$% as a user.

Passwords that are phrases have higher entropy and are harder to crack than simple letter/number substitution:

That is a bias perspective from your point of view, and keep in mind that passwords are not cracked but websites are cracked.

Long form passwords based upon phrases actually make it easier to decrypt a hashing algorithm, then a short password containing upper, lower characters, numbers and special characters. The reason is that human language uses far fewer of the letters in the alphabet for most phrases. This allows a hacker to narrow the scope of their attack on a hash. If they know all passwords are 8 characters, but contain a possible range of 255 different characters than that is a massively huge range of possible hashes.

The most common attack on a website does not come from that website. It comes from weaknesses in another website. If I hack into website ABC and get a list of unhashed emails and passwords, then I can use that list to attack other websites.

Before a hacker uses his list on popular websites like Facebook, Twitter or Google. They will clean that list by attacking smaller websites to see which idiots re-used their passwords. Once they have a cleaned list the odds are that person re-used the password on a major website.

Often those websites are attacked without the attacker ever being noticed, because they walked right in using valid authentication.

So never re-use your password. Always use a randomly generated one and stop using phrases.

Use A Password Vault

  • Interesting points! But I must disagree about the space and the key thing. You say "traditionally", which is exactly the problem. To the computer, the space is just another character. In, say, a dictionary of keys, one might want to avoid spaces for... what reason? Perhaps in the old days it's an unnecessary character - but in terms of usernames, why? It's just another character. It makes no logical sense to disallow it, even if "tradition" is in the room :)
    – Moo-Juice
    Commented Nov 22, 2013 at 19:26
  • @Moo-Juice there can be a lot of technical reasons to exclude characters. URLs, directory names, and operating systems all play differently when you include spaces and special characters. It really depends upon what the website is doing with the usernames.
    – Reactgular
    Commented Nov 22, 2013 at 20:51
  • So what you're alluding to, is stupid programmers? :)
    – Moo-Juice
    Commented Nov 22, 2013 at 21:28
  • Space isn't just another character though. It many cases it's already defined as a delimiter. Commented Nov 23, 2013 at 15:13

I don't think it matters too much - no matter what we allow end user's - they will still end-up using passwords like 123456 and password.

  • 3
    without an explanation, this answer may become useless in case if someone else posts an opposite opinion. For example, if someone posts a claim like "It matters much - what we allow end user's can stop using passwords like 123456 and password.", how would this answer help reader to pick of two opposing opinions? Consider editing it into a better shape, to fit How to Answer guidelines.
    – gnat
    Commented Nov 22, 2013 at 10:12
  • Sad but true. They will.
    – JensG
    Commented Nov 22, 2013 at 19:22

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