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

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.

CodeCaster
  • 2,424
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
  • 11,238
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?

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

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,367
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,120
  • 4
  • 50
  • 81
-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.