[txcwpalpha]

There is actually a reason (though 32 seems pretty short. Something like 256 is probably more reasonable).

Several thousand characters (or worse, unlimited length) opens up your attack to a form of DDoS where you can exploit the fact that password hashing is a computationally heavy operation. See here: https://arstechnica.com/information-technology/2013/09/long-...

> Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large—and guaranteed-to-fail—passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher. This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.

[SAI_Peregrinus]

55 would make sense if they are using bcrypt. But since it's 32, they're probably not actually securely storing (password hashing) them at all.

[Dylan16807]

The real problem there is using an algorithm that gets slower on longer passwords.

There's no need to have a cap bigger than a kilobyte though.

[rcxdude]

Is there a cryptographic hash algorithm that doesn't? It seems like that would make it non-cryptographic (since you will need to read each byte at least once).

[Dylan16807]

Reading each byte once only takes a few microseconds. That's not the issue.

What you need is for the slow core of the algorithm to be fixed-speed.

Either by only reading the input bytes during initialization, or by only feeding a fixed number of input bytes into the core during each round.

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

[Hamuko]

How?