Why do so many sites disallow the use of non-alphanumeric characters in passwords?

Question

When going through registration, a lot of sites will disallow the use of symbols in passwords. This drives me up the wall from a usability perspective since I include multiple symbols in all my passwords, and as a programmer that deals with web authentication from time to time, I can't figure out why it wouldn't be allowed. Am I missing something? Are they worried about SQL injection? Don't want to deal with escaping characters? Or is there something with non-Latin-alphabet characters that can mess things up?

Similar question, about sites that restrict length here.

Answer 1

1. Laziness, 2. Using legacy systems that don't support those characters for auth

Answer 2

1. They are morons
2. They are almost certainly storing the plain text password somehwere (see 1)

Answer 3

It probably means they're lazy or not very smart. If you only store a hash, you won't have to worry about character sets, injections, or space. Pretty much what was explained in that other question you gave.

Answer 4

it's a toe crunching, teeth grinding issue especially when banks do it; however, I think some of the issues are with the ';' and ' ' " ' characters.

Back in the day some programmers, i suspect, thought by forcing alphanumeric characters, that people might forget their passwords easily.

Answer 5

Bad programming, and the fact they're storing it in clear text, I'm sure.

Answer 6

Our system once had to work together with 3rd party hardware which was operated through touchscreen. Their on-screen errr.... 'keyboard', surely didn't had a non-alphanumeric characters, therefore - we ran into quite serious trouble with passwords - clients had to change them.

Answer 7

One possible reason: the site's UI is designed by a marketing type or a non-technical product manager. Someone who doesn't understand combinatorics and thinks they actually provide their developers with precise requirements by dictating that the password field must contain exactly 8 alphanumeric characters.

Answer 8

They aren't in the US: In Europe, you have a different keyboard every few miles. Good luck finding your special character on an Italian keyboard. Or a Greek one. Or Turkish.

The only keys which are probably there are the alphanumeric keys and most people will be able to find their way around them, even if a couple of the keys will be swapped (Y and Z, for example).

Lastly, people are notoriously bad at remembering passwords. Forcing them to use "honey" instead of "jh(/&DFA93475" greatly reduces the rate of calls for support ("I can't remember my password...")

If it's a web app, the developers were not really able to make sure that umlauts survive the transfer from the form to their backend. It would be great if all browser would simply send UTF-8 but most backends can't handle UTF-8 without some careful tuning, either.

Answer 9

It's possible that the same password will need to be entered via the phone keypad, (1 = 1, A, B, or C).

Realizing that this is terribly insecure, one way of increasing the security would be to lock the account after X bad password attempts. Often bank websites are just a front end for a horribly old mainframe application and can't change password policies.

Answer 10

The reason they require alphanumeric is usually an attempt to prevent SQL injection when passwords are entered. For example:

On some sites you can actually type in: U: admin P: ' or 't' = 't

Normally programmers get through this by using programming practices such as parameterized SQL, but I am willing to bet this is why they are doing it.

Answer 11

Legacy Systems Support

I can't say if it is true for many websites, but in many antiquated network environments that use radius or another form of centralized authentication, often you have to restrict your passwords to the lowest common denominator for all of the disparate systems that you are supporting. So if you are supporting password authentication for a poorly written legacy application that has problems with non-ascii characters and that server piggy backs onto the central authentication server, you are forced to limit all of the other servers to the same password restrictions.

Poor Input Validation and Lack of Password Hashing / Encryption

The applications could have had SQL injection issues in the past and over-zealous programmers just disabled all not ascii rather than address the fundamental flaws in their design.

Unneeded Simplification

The developers may want to minimize issues with binary data petering into the password store and are over-zealous in their data validation. Honestly, I think this is the most likely scenario. The programmers may have already taken an ascii-only approach to usernames and just extended the same line of thinking to passwords.