1

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.

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).

5
  • I understand and agree with the first reason. The benefit is small. So it is a case of weighing costs versus benefits and most people have decided against it. The costs are too high versus the benefit. – emory Sep 7 '20 at 16:01
  • I am afraid I do not understand the second reason. If the password is set server side, why would I use this scheme at all. My minor pet peeve is I configure my password manager to generate 1,000 digit passwords and from time to time I have to manually override it to generate smaller passwords. If the server generated the password, I would just use my password manager to store the server generated password. – emory Sep 7 '20 at 16:06
  • In my second objection, the password is not generated server side, it is processed and handled server-side. Setting a SQL user's password involves sending a SQL statement ALTER USER foo WITH PASSWORD "blah blah blah" to the server. The server parses it and stores the password however it wants. Eg: stores the md5sum of the password. When the client wants to connect next time, it sends the md5sum of the password in the handshake and the server checks it against the stored value. (this is a simplification of the protocol, but you get the idea). – Marc Sep 7 '20 at 16:10
  • As long as there are password stored with md5sum, and as long as there are clients that can only handle the md5sum authentication method, the server cannot upgrade to the new, more secure version. Sending the plaintext password (over a secure channel) from the beginning would have allowed the server to change certain things. This was a logical decision back then due to the lack of safe channels, but it isn't now: the simplest is to send the plaintext over TLS and let the server change hashing mechanisms in the future. – Marc Sep 7 '20 at 16:11
  • The point was: there are use cases where future compatibility is not an issue (most website login methods). And other cases where there are other considerations than the password length. APIs and more complex protocols are such cases. – Marc Sep 7 '20 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.