Why limit password length?

Question

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.

1. The user enters a password of arbitrary length.
2. The client hashes the password to a fixed length.
3. The server can reject the client's hash if it is not the fixed length (protecting the server from resource exhaustion).
4. 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.

Answer 1

As long as you are very careful about the client-side hashing function, it would seem like there is no reason you couldn't. But wait!

You do need to remember that not all passwords are for web-based applications with a single client written and distributed by the author.

Instead, it could be an arbitrary API. Adding the requirement that the password must be hashed using a specific function adds complexity to the implementation.

In yet other cases, the password could be set server-side (think SQL servers where the "set password" command is literally a SQL statement). Should the initial hashing function be poorly chosen (think md5 for postgres), you're now stuck with it until all clients support the new hashing function and all users have changed their passwords.

It might at first seem like a practical reason and not a security reason. But this becomes a security issue 10 years later when your protocol is still being used and most clients still only support a terribly insecure hashing function (and yes, this is the case for postgres).