Okay, but I think you're missing my point. There's no reason it has to have a maximum length, but the database has the capability, so as a developer you feel an irrational pressure to put some number in there. Of course any maximum is going to be a problem for someone, whether it's 8 or 128, but you don't think about that-- you just put something reasonable like 20 and move on.

If you're hashing the password (like you're supposed to do), then all password hashes will get stored with a fixed length, so the actual passwords that people use could be an entire novel of 600 pages, as long as bandwidth for uploading it or the server's processing power doesn't become a problem.

The result of a hash function you would use will be something like 64 chars for SHA256, 128 chars for SHA512 and 60 chars for bcrypt - and that's the only permanent storage you need for storing a password. 20 chars is not reasonable. A reasonable size would be at least something like 128 chars, to allow people to give hashed passwords managed by external software, instead of real passwords. And you can trim hashes to 20 chars, but 20 chars can be brute-forced much more easily.

For instance, if you find the password for one of my websites (I use 32 chars, which seems reasonable even when copy/pasting doesn't work), it would take you years and years of processing to find my master key for generating the passwords to my other websites - so basically I have the same password all over the place, HMAC-ed with a salt specific to each service/website. The password itself is long but easy to remember. The algorithm for hashing is very sound, for now at least. Brute forcing it to find my key for all websites is for all practical purposes unfeasible.

Sorry, s/database/text field/. The box is only 20 characters long, why would someone need more?

Look, I understand what you're saying. I'm not saying this is right, I'm saying they just don't think. Security gets confused with validation, so they just put in a number and move on.