[GordonS]

But couldn't an attacker just skip the client-side hashing?

[Dylan16807]

Then the server will reject it for being the wrong size.

[GordonS]

The GP suggested it would also be hashed by the server - presumably because you can't trust client input.

[Dylan16807]

You would hash it on the server because you don't want to turn the 'hash' into a plain-text password.

But instead of the server accepting an arbitrary string, it only accepts hexadecimal or base64 strings of a specific length. Which solves the problem.

[GordonS]

I'm not quite understanding the protocol here.

If the client sends only a hex/base64 string, how can the server trust that it's the result of a password being fed to a KDF?

[Dylan16807]

It doesn't matter.

The threat model is: Password is too long, lots of CPU is wasted, denial of service.

By only accepting strings of a certain length, the threat is defeated.

The client could send an intentionally bad password even if they weren't lying. If they lie, only the client is harmed, and in a non-new way.

So this scheme has one notable upside, and no notable downside.

There are better solutions, but this one is valid.

[GordonS]

Hmm, I can see some benefits to the scheme, such as using the client's CPU cycles, and the plaintext password never having to be sent to my servers.

Maybe it's just that it's not the norm, but I'm still unsure I'd actually use this scheme.

As the owner/maintainer of a service, I want to be in control and know that my user's credentials are secure - there may even be legal obligations here in some countries.

TBH, my preferred solution here is never to silently truncate passwords, and just to set a "sensible" limit on password length, e.g. 256 characters. Yes, it's still an arbitrary limit, but it should be long enough to cover 99.9999% of users.