In discussions of whether there should be a maximum password length at all, it's funny to introduce the scenario of a user wanting to use a password that is 1GB worth of text.
I always thought the password should be hashed client-side. Supposedly that has some problems and it would still need to be hashed server-side as well.
So I have a proposal: client-side, hash the password. Can use any hash, although hash selection does limit the password security to its output. That hash is the new password sent over the wires to the server, that does proper password handling, but it is guaranteed a password of (say for SHA-256) 256 bits; if it receives a password that doesn't look like SHA-256 output it can automatically throw it out without even checking.
The client can then store the hash-input in his password manager, and it can be literally anything that can be thrown at the SHA hash. Is this feasible?
https://tools.ietf.org/html/rfc2617#section-3
The main issue with a "new" approach vis-a-vis basic etc, is that you need client support (will it work without js).
Then there's the question of what you're protecting against: if an attacker knows you accept a single round sha1-hashed pw, it's still easy to brute force through login, but it might require custom rainbow tables to account for the extra hash round.
But you'd be better off with a standard pw stretching / storage scheme for defeating off-line attacks.
So it is at most a RAM problem. Still, interesting talk point. Not very practical, but interesting.
[1]: https://www.helpnetsecurity.com/2013/09/17/too-long-password...
This is part of why it's funny to bring up. People are so used to focusing on bozos (who store plaintext) vs the initiated (who store salted hashes) that they are taken by surprise by other dimensions.