There are some websites and even programs that I use that have ridiculous password restrictions. Lots of forums for instance restrict passwords to ~32 characters. Others enforce a restricted charset.
What would cause a developer to put in such restrictions? As long as you do the initial hashing of a password on the client, there is no load on the server for having to calculate the hash of enormous auto-generated passwords. There seems to be no benefit of using such restrictions
I think the reason is the same as for any other input validation; to make sure it doesn't cause any problems during processing and storage. Now, for passwords this is of course completely misguided since they should be hashed and therefore neither stored nor really processed in cleartext.
I'd take any such limitations as an indication that the developers don't know what they're doing securitywise, and are probably going to store the password in cleartext. Stay away.
I'm going to go with: the same old reasons people do strange things.
Because it seemed like a good idea at the time. Developers might be well-intentioned but poorly informed. There's no need to limit password length, but maybe developers aren't aware of that. Maybe developers didn't even think about it.
Because it was easier than the alternatives. Maybe they are using an API that can't handle arbitrary-length passwords; that might make it easier to just limit password length than to use a better API. Maybe they have SQL injection flaws in their database, and rather than coding things properly to avoid the SQL injection flaw, it's easier to just blacklist some characters (e.g., forbid users from including single quotes in their passwords). Maybe for some reason it was easier to use a fixed-length array than a variable-length string. Who knows.
Bottom line: there's no really good justification for such limits. I'm sure we're used to the fact that commercially available software often contains all sorts of strange design misfeatures. It happens. It's a fact of life. It's a consequence of the fact that "good-enough" is a lot cheaper than "perfect".
A rational reason for limiting password length and possible charset is to prompt the user into applying proper password management techniques. In plain words, if a password is huge or full of weird characters, then this increases the likelihood that the user will write the password down on some piece of paper (traditionally glued under the keyboard) and/or reuse the same password into several systems.
Conceptually, how the user manages his own passwords are his responsibility, and none of the website business. But, in practice, users are security-wise clueless and cannot be bored with anything which does not have an immediate retribution (especially when users are potential customers). So it is up to the website to try to do what it can in order to protect the user.
Note that I do not claim that trying to enforce good password management is the reason why any given site limits password length; it is just a reason why I would envision a password length limitation on my own site (if I were to manage a website with user passwords).
Another rationale for limited allowed charset is to promote interoperability: preferably, the user should be able to type his password on a wide range of input devices. Non-ASCII characters are not good for anything which looks like a US keyboard (it is possible to type non-ASCII letters on a US keyboard, I do it all the time, but methods vary depending on the operating system and configuration, and do not work well with blind typing as is customary with password entry). Smartphones have even greater restrictions. There again, interoperability is (in my view) a good reason to enforce a limited charset, but many websites will have such a restriction for bad reasons (e.g. so that the password can be carelessly dumped into a SQL request without proper string escaping, something which can only be described as sloppy engineering).
I thought we had a question like this but either my search-fu is weak tonight or it was on another site.
Basically, in most applications or databases it makes sense to define useful limits on input strings. This lets you stop input once the limit is reached (which can avoid overflows etc) and also ensures you can predict code performance.
Also you may need temporary storage while validating passwords before they are hashed - again, allowing arbitrarily long input can cause problems.
As to why 32? A reasonable figure for the majority of purposes - the entropy in 32 chars is huge. Of course in some environments this will not be enough, but for many of them a cert or 2nd factor (such as a token) may be more appropriate anyway.
Since my first question missed the mark, I provide a separate answer. The primary reason is that limits are required. Although the concern regarding the storage space and achunk of data is accurate, there are some issues.
First, if you read my original answer below you will see that one of the recommendations is iterative hashing (i.e. pbkdf). This requires a large number of iterations in order to be truly effective. If a user is able to submit a large string, then the cost of computing this iterative hash value quickly becomes more expensive than expected for a simple authentication function.
Any single computationally expensive task on a server, especially one that is explicitly available for an unauthenticated user, is subject to abuse by a malicious user to perform a denial of service attack.
Second, by implementing a fixed length password it provides an opportunity to terminate early if an extremely long request is submitted. If the parameters in the request are outside of the expected length it is simple to issue an error message and close the connection.
The reason that password complexity requirements are enforced on many sites is to prevent users from choosing a weak password. There are numerous examples in recent history which show that most users will select weak, easy to enter, easy to remember passwords over complex passwords. When this occurs, the owner of the site is placing themselves at risk as users will invariably blame the site if a password is stolen or cracked, and whatever outcome that may have to both the site and the affected user.
By implementing strong password requirements, it reduces the likelihood that an attacker can easily guess the password. Passwords also need to be protected against two different attack paths. The first, online attacks, requires that a site developer have a policy that will prevent brute force attacks from succeeding. This is accomplished by requiring that a user select a suitably long, complex password, and restricting the number of failed logon attempts before slowing (i.e. temporary lockouts, captchas, etc) or stopping attempts to login (permanent lockouts, mandatory password reset, account confirmations, etc).
The second attack is an offline attack, where an attacker will acquire a copy of a password database, and attempt to use a rainbow table or offline password cracker to crack multiple accounts. This type of attack is prevented by using a strong hashing algorithm in conjunction with a per-user salt, and preferably pbkdf2 or bcrypt/scrypt style rehashing to increase the computational cost of offline cracking.
Ultimately, both of these techniques fail if sites don't encourage users to select a unique password for their various accounts. Many users will select the same passwords for multiple account, and when that password is exposed, especially with their email account, it is possible for an attacker to use that credential on another service. For this reason it is best to generate unique, strong passwords for each site, or at least different groups of sites and use a secure password manager to store all of the different passwords.
War and Peace might cause a performance hit, but anything reasonable - even hundred characters - would be negligible. Furthermore, as far as repeated hashing (pbkdf) goes - after the first hash, you will always have the same length output....