That's a minimum maximum requirement. It says that the password must be allowed to be at least 64 characters long, not that they be at most 64 characters long. Combined with the forbidding of composition rules and the demand that all ASCII and Unicode be allowed, 64 characters is more than enough.
For which they set a 4K limit on password length. I think even the commenter you replied to would find that satisfactory, being much more than 64 characters.
It's pretty arbitrary when you get to 64, IMO. If a site enforces a maximum below that, I'll feel suspicious and treat the site as if it's storing my password in plain text; that maximum or higher reassures me that they probably know what they're doing.
Of course, one day, a 64-character password will be brute-forceable in milliseconds, but we hopefully won't still be having this discussion by then!
I agree, though I also think: why have some arbitrary limit at all? Mind you the 4K Django limit isn't arbitrary, they know that at some point beyond that they'll spend too much time in hashing-land and will have opened up a DoS attack vector.
I would argue 4K is effectively unlimited... maybe in the sense of an ISP/phone company "unlimited data plan" unlimited, but still... the likelihood of user knowing of the limit is very small. I use a password manager that maxes out at 100 characters in its password generator (a default I use because... why not?) However, in those small cases where I do use contrived passwords, I make use of passwords that are really pass-sentences (with a few extras thrown in). It's pretty easy for me to blow by 64 characters (and sometimes 100) in those cases; not because I think I'm gaining extra security due to length, but because I'm just throwing out the first, easiest to remember sentence that crosses my mind and that I know will be reasonably secure. A service that flummoxes that effort just makes it less likely I'll use the service (assuming that it's use is discretionary).
When that happens, turn up the work factor on the hash.
And 64 is a pretty low limit if you want to use a passphrase.
"He who fights monsters will have to look into fighting scammers too" is both a decently difficult password to guess, pretty easy to remember and too long.
64 lowercase English letters is 10^92 bits of entropy, which is around the same number of atoms in the universe. Eventually the laws of physics put an upper bound on how much entropy you need to avoid brute force attacks.
I'm sure there's a good reason why this won't work, but wouldn't it be possible - over SSL - to have the client generate a salt and hashed password, and send them (separately?) to the server? What's the hole I'm missing?
