Is there a reason why certain sites don't allo

问题:

I was just wondering why certain website don't allow anything other than letter and numbers in the password field.

Is there a security reason or perhaps it's just a limitation of the DB they are using? Thanks for the info.

Edit: It appears that Oracle's database doesn't acknowledge uppercase and lowercase? Is this true? I was told that via PM. Thanks for the information guys, this is really useful stuff.

I wonder why this question has 3 votes to close though. Not enough jQuery and freehand circles?

回答1:

No reason at all, except for sloppy DB coding where they would allow plain text in the DB or use the (non-portable) DB functions to hash the password and use direct SQL statement. This seems just like plain string validation.

Other than that, on the practical side, special character placement in foreign or cramped keyboard is tricky and might be more frustrating for users that are traveling (or in the more modern case alternative input like onscreen keyboard on smartphone). Some websites might even push the system further by providing their own on-screen keyboard to log in (with various scrambling).

Disallowing special characters helps QA, and reduces multi-platform user frustration.

And finally, allowing a limited (deemed safe) character set (that is not only punctuation but also more language specific characters in Unicode), developer can also avoid encoding confusion between the browser and the server application (form data encoding is not very clear in the standard, and can be tricky on some browsers).

回答2:

They're brain-dead and scared of punctuation in general - and dot counts as punctuation. It is more a case of 'friendly-fire' than dot being dangerous. Dash is pretty harmless too.

One of the concerns is SQL Injection, of course. The other is competency of programming workforce.

回答3:

I worked at one place that wanted to be able to read passwords over the phone (that's how support was done). Support people didn't know all the names for symbols (hash, bang, pipe, ampersand/and, asterisk/star) and other issues (which left bracket do you mean, which quote, etc). So they didn't allow any punctuation.

Not a good reason (support shouldn't know my password), but you didn't ask for only good reasons :)

回答4:

There is no possible reason. They are just incompetent. Any concerns about SQL injection or anything else is just wrong. That just tells you that they are worried about a possible security injection because they aren't hashing or encrypting your password.

回答5:

About upper/lower case: if you store the password in plain text, then that might be an issue. I'm not sure about Oracle, but SqlServer considers 'Password' and 'passWORD' to be identical.

If you store the password as hash, then the casing of the original is not a problem: the password acts case-sensitive.

回答6:

OWASP is pretty clear on the subject. Its first piece of guidance in the OWASP Passwood Storage Cheat Sheet is:

Do not limit the character set and set long max lengths for credentials Some organizations restrict the 1) types of special characters and 2) length of credentials accepted by systems because of their inability to prevent SQL Injection, Cross-site scripting, command-injection and other forms of injection attacks. These restrictions, while well-intentioned, facilitate certain simple attacks such as brute force.

Do not allow short or no-length passwords and do not apply character set, or encoding restrictions on the entry or storage of credentials. Continue applying encoding, escaping, masking, outright omission, and other best practices to eliminate injection risks.

A reasonable long password length is 160. Very long password policies can lead to DOS in certain circumstances1.

回答7:

Isn't it to avoid all possible SQL injection?

回答8:

In general, it's a bad practice to just restrict passwords to numbers and letters. However, it does help to protect the code from "code injection" where a hacker passes some instructions as part of the password to gain access to the system. A password like `Apple;"Delete * from users;"' could end up doing damage if the developer didn't take proper care of escaping user input.

Another problem is the use of special characters that might cause conflicts in the code behind the site. Or special characters that depend on the specific character set/encoding that's used in the database. Letters like ë, è, ï, î and ì are all special characters that could be used, if allowed. But they sometimes end up being translated the wrong way.

Another problem is that some people tend to easily forget their password, which becomes a bit more complex to remember if you're allowed to use special characters. By restricting the password to fewer combinations, you also make passwords easier to remember.
Unfortunately, it also makes them easier to hack...

And often it's just a policy set by management of certain companies who just don't know better. The restriction could be just a management decision, with no logical explanation than management wanting passwords to be stored that way...