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

[Dylan16807]

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

The code doing the client-side hashing is just as secure as the rest of the client interface. You don't compromise anything by doing it.

Still, it's easier to do the extra hash locally on the server if you need it.