Does it indicate a bad password system to disallow certain characters in passwords?

Question

When creating an account to the game League of Legends, the user's password must comply to a few rules.

The one I'm concerned about is the "Must not contain slashes or spaces" one. The others are sane password requirements (well, except the maximum length), but disallowing slashes or spaces seems weird.

I can't come up with any other explanation than the passwords being sent or saved in plaintext with said characters messing up the format, as in a hash such characters would disappear. It also seems weird to only disallow these to prevent e.g. SQL injection or other such things, especially as they should be handled normally with all data.

So, in addition to reducing the entropy by reducing the character set available, this might indicate a deeper problem. What do you think?

Answer 1

Forbidding certain characters doesn't in itself indicate that the password system is broken, but it's a bad sign, and it suggests that the developer has low confidence or a bad understanding of their data processing system. The most likely explanation is that the developer fears some kind of injection attack — SQL injection, or cross-site scripting, or something of that kind. Slashes and spaces are the most likely characters here though, but maybe ', < and > are also forbidden, or maybe they're reencoded (but then why not reencode / and space?).

The password has to be sent in cleartext to the server and hashed there, or at least some encoding of the password has to be hashed on the server (if the password was hashed on the client, the password hash would effectively be the password, which would be no good if an eavesdropper obtained it).

It could be the case that the web infrastructure is bad (full of SQL injection, XSS, etc.) but the password hashing code happens to invoke the right library function and stores a salted, slow hash of the password. Or it could be the case that the password is stored in some weird format pseudo-database and that's why certain characters are forbidden.

It could also be the case that this is some user experience requirement, which may or may not have been interpreted as intended by the developer. Some sites restrict special characters in passwords so as to prevent users from choosing passwords that they won't be able to type easily on some devices. Since this is for a game, maybe there's an in-game interface that requires the user to enter their password, but doesn't allow spaces or slashes (or backslashes, which are also forbidden). If that's the case, they should probably forbid non-ASCII characters as well.

Looking at League of Legends's password recovery instructions, it appears that they do not store the password in cleartext, but to provide an industry-standard password reset link sent to the email address associated with the account. A security announcement mentions that they password database contains “salted password hashes”, so they appear to know how to do things correctly. At least they have some of the basics right — the page they link to explains salt but doesn't mention that a password hash must be slow. Still, given these clues, I'm not overly worried: they're probably not doing something extremely bad (at worst, they're using a fast but salted hash). I suspect that the explanation for the restrictions is a restricted interface to type a password in some version of the game.

Answer 2

You might contact the site owners and ask them specifically what's up with the arbitrary requirement. Actually, ask them specifically what password hashing algorithm they are using to create a digest of your password and how they are computing and storing the salt.

Maybe I'm overreaching a little, but my point is that if their system is secure because it is obscure, then it isn't secure.

I would't use the same password for that system that you use for your online banking, but then that's good advice across the board (different passwords for different sites).

Regarding the maximum length, accepted primitive hashing algorithms like the SHA algorithms don't care about the input length, and the output length from those functions is constant regardless of the size of the input, whether the input is three characters or the entire Encyclopedia Britannica.

If you want a 100 character password, you should be able to have one.

Them limiting your password to 16 characters tells me (right or wrong) that they're probably storing your plaintext password and the field they store it in is 16 characters long.

EDIT: Or it could be a sign that they're doing something along the lines of the old LanManager password hash algorithm, using your password, or diced-up parts of your password, as keys for a symmetrical cipher like DES or AES to generate fixed-size password hashes. That could be done right, or done wrong. Are they using salt at all? Are they preferring a speedy hash algorithm (NOT a good sign if they are) over algorithms designed for password hashing, such as scrypt/bcrypt/pbkdf2? Etc.

Further, spaces and slashes aren't any different from any other characters, unless they're doing something like using the password value for a file name (maybe a temp file name) or passing it around embedded in something like SQL or JSON, in which case they'd be concerned with having to properly escape those values in the string or break their software.

What they should be doing is handling the password as binary data, encoding it as necessary if they have to pass it from one component to another (e.g. Base64), and never keeping the actual unhashed password around even in RAM any longer than necessary, then storing the hash. In the case of SHA-1 (theoretically broken now), the hash is 160 bits long, although there are proponents of truncating the hash before storage (I'm not entirely sure I'm in that camp, but it's probably okay and that's a different issue).

Security is hard to do right, often done wrong, often neglected or treated lightly and this system sounds fragile, to me, on top of all that. I think you're right to be suspicious of it.

Answer 3

There could be legitimate reasons to restrict the set of permitted characters in passwords. For example if the password contained any character that wasn't a printable ASCII character, then encoding problems could potentially cause a correct password to be rejected under some circumstances.

Additionally if a user might at different times need to type the same password on different keyboard layouts, then it can be problematic to use characters that are located differently on those keyboard layouts.

An adversary might be able to figure out which users are affected by the above problems and that way gain some knowledge about which characters those users have used in their password.

Restricting the set of permitted characters for the above reasons doesn't have to weaken the strength of the passwords. All you have to do is make the password slightly longer. (In the extreme case, if you went from permitting all printable ASCII to only permit lower case letters, you would have to increase the password length by 40% to have the same entropy.)

There are also bad reasons for restricting the set of permitted characters. For example if a system restrict the set of permitted characters in order to prevent SQL injection attacks, it would tell you about two security flaws in the system. First of all, it doesn't use the proper escaping for SQL queries. Secondly, it clearly doesn't use any hashing of passwords.

For the password length a limitation may be a good idea just to avoid problems in case some client is enforcing arbitrary limitations on input fields. For example if somebody thought it was a good idea to use a signed char to indicate the length of a field, then that would not hold more than 127 characters at most. I have made systems where I enforced a maximum length of 125 characters on passwords as a precaution against such possibilities (and possibly a couple of off-by-one errors).

Enforcing a maximum length on passwords does reduce security if that maximum length is too short. You should compare with the symmetric cryptographic primitives you might be using. That means we should compare with block and key sizes of block ciphers as well as output of hash functions. That means we would usually expect from 128 to 512 bits of security from our cryptographic primitives. Disallowing passwords that could match those security levels would be counter-productive. Depending on the permitted set of characters, there could be from 4.7 (lower case letters only) to 6.57 (all printable ASCII) bits of entropy per character in a strong password. With a bit of math we see that if we do not permit at least 20 characters, we definitely set the limit too low, and if we permit 109 characters we should be very much on the safe side.

Whether one set the upper limit to 100 or 125 is unlikely to have any real impact on security, because most likely no user is going to go that high.

When you mention a maximum length of 16 characters being enforced, it is indicating that likely the designers introduced that limit for a bad reason. One bad reason would be that the password is being stored as plain text and only 16 characters was allocated for storage. Another not quite as bad reason would be that the password is used directly as key for a cryptographic primitive (such as AES).

The combination of the two restrictions (disallowing two specific characters and a small maximum limit) is a warning signal, because each of them on their own could be a choice made due to passwords being stored as plain text.

That the specific pair of characters they decided to disallow is spaces and slashes sounds scary, because the reasons I could imagine for those two specific characters not being allowed is, that they might want to put the plain text password in a file name or a command line. Hopefully that is just a matter of me lacking a little bit of imagination.

Answer 4

I usually tell people for a site that is important, "If there are forbidden characters, they are storing your password plaintext." Not necessarily true; however the following gets told when the other end tries to claim not so: "Seeing restricted characters screams at the engineer 'I store passwords plaintext' a lot louder than any documentation, and if not true, the restriction can be easily removed."

Due to this general pressure being applied for quite some time, we may reasonably assume the most of the remaining are ones who really do store passwords plaintext, and fixing it is a cheap way of saying "not us".

Upshot: If you can't be bothered to unrestrict the password field you're not worthy of my trust, and I'll take my business elsewhere.