[tomtomtom777]

Isn't this mitigated by hashing the password on the client (in addition to hashing it on the server).

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

[Hamuko]

How?