11

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

Moo-Juice
  • 1,378
  • 8
  • 13
  • 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. – Julia Hayward Nov 22 '13 at 09:12
  • 5
    Wrong site. Please look here: http://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maximum-password-lengths – Deer Hunter Nov 22 '13 at 09:58
  • @DeerHunter, I believe there is some overlap due to development reasons. Also the question you link to is about password length, whilst my question doesn't mention password length, but is about the composition of both passwords and usernames and the fact that things such as spaces are not allowed but should be perfectly acceptable. – Moo-Juice Nov 22 '13 at 10:25
  • 3
    Maybe all our registration pages should have that comic embedded in it and force a min length of 20 characters :) – ozz Nov 22 '13 at 10:47
  • 1
    I thought this question was going to recommend something like using Facebook or Google accounts. – JeffO Nov 22 '13 at 13:27
  • 1
    This really belongs on a blog. – GrandmasterB Nov 22 '13 at 16:21

7 Answers7

13

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.

Community
  • 1
CodeCaster
  • 2,394
  • 1
  • 15
  • 20
  • 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. – Kilian Foth Nov 22 '13 at 09: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 Nov 22 '13 at 09: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 Nov 22 '13 at 09: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 Nov 22 '13 at 09: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 Nov 22 '13 at 19:20
2

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.

jmoreno
  • 10,640
  • 1
  • 31
  • 48
1

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?

Sven Amann
  • 626
  • 4
  • 7
  • 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 Nov 22 '13 at 09: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 Nov 22 '13 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 Nov 25 '13 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 Nov 26 '13 at 09:36
0

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

mythicalprogrammer
  • 505
  • 2
  • 6
0

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.

StasM
  • 3,377
  • 2
  • 23
  • 28
0

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

Reactgular
  • 13,040
  • 4
  • 48
  • 81
  • 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 Nov 22 '13 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 Nov 22 '13 at 20:51
  • So what you're alluding to, is stupid programmers? :) – Moo-Juice Nov 22 '13 at 21:28
  • Space isn't just another character though. It many cases it's already defined as a delimiter. – Mike Gossmann Nov 23 '13 at 15:13
-3

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.

Dave Gordon
  • 101
  • 1
  • 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 [edit]ing it into a better shape, to fit [answer] guidelines. – gnat Nov 22 '13 at 10:12
  • Sad but true. They will. – JensG Nov 22 '13 at 19:22