This question is inspired by Is there any security risk in not setting a maximum password length?.
Specifically the accepted answer https://security.stackexchange.com/a/238033/9640 says limits are recommended to avoid exhausting the server.
Also it seems to me that if the server is hashing your password to a n digit hash, there is no security advantage to having a password that is longer than n digits. An entity that could reasonable brute force the n digit space, would not have to brute force the (n+1) digit space to brute force your (n+1) digit password. In practical terms, a 1000 digit password is not really more secure than a 500 digit password.
However, what about double hashing the password.
- The user enters a password of arbitrary length.
- The client hashes the password to a fixed length.
- The server can reject the client's hash if it is not the fixed length (protecting the server from resource exhaustion).
- The server otherwise treats the client's hash as the password and proceeds in the usual manner (it re-hashes it).
In this way, if you want a 10,000 character long password go for it. Your browser will invisibly to you, transform your 10,000 character long password to a 128 character long password (still very secure) and the only change in the server is that now the server knows that all passwords must be exactly 128 characters long so it can reject some logins more easily.
The primary benefit of this scheme is that no user will ever be told "your password is too long". I personally find this message to be disheartening. But I concede that this benefit is not monumental. So if there are any security holes that I am not seeing, this scheme is probably not worth it.